[Bug]: Accessibility Issue - aria-controls in sidebar not connected to any HTML element

[leagrdv]

Describe the bug

In the sidebar navigation of storybook, I have parent categories that contain either direct children pages or subfolders. The subfolders buttons all have a aria-controls attribute which should technically refer to the ID of the element that the button controls but no such ID exists in the sidebar.

Reproduction link

https://next.design-system.post.ch/?path=/docs/introduction--docs

Reproduction steps

1. Go to the dev tools and locate the button of the subfolder Typography
2. Notice the aria-controls="foundations-typography-overview" on the button
   
3. Look for foundations-typography-overview in the page, we can see that there is only one occurence which refers to the aria-controls, meaning no element has this ID, even though the folder has been opened and the element it is therefore controlling is visible.
   

System

v8.4.2

Additional context

No response

[candrepa1]

Hi @leagrdv

I believe the default id for Overview is being overwritten here: https://github.com/swisspost/design-system/blob/main/packages/documentation/src/stories/foundations/typography/typography.stories.ts#L5

However, I do agree with you that aria-controls is not behaving correctly: it should be an spaced list of all children, and right now we are only passing the first child. I've opened a PR for it: #31491

[Sidnioulz]

This should be addressed as part of #31267. That other issue puts into question whether we should use a treeview role, whether we should rely on aria-expanded nested lists in a nav, etc.

Potentially, aria-controls is too verbose and less relevant than an aria-expanded attribute letting users choose in which subsections they want to browse. I'd thus prefer #31267 to be addressed before we make changes to aria-controls which might not be relevant in the end.

[Sidnioulz]

I was reminded today that many assistive techs no longer expose aria-controls due to it being regularly misused by developers. I suggest we close this issue and its associated PR in favour of simplifying the DOM in #31267.