[A11y]: Sidebar is not accessible

[leagrdv]

Note

This issue was rewritten by @Sidnioulz to track related issues in-place.

Links and buttons in the sidebar cannot be focused (original issue)

Describe the bug

The buttons in the sidebar have a tabindex="-1", which makes them unfocusable and therefore unclickable. The same issue applies to all the links—each one also has a tabindex="-1", so I can't focus on them either. While I can navigate through the items using the up and down arrow keys, the parent categories (e.g., "Foundations" in the screenshot) require using the tab key instead. This creates a disjointed navigation experience, as the arrow keys don't work in conjunction with the tab navigation, which is not ideal for accessibility.

Reproduction link

https://design-system.post.ch/

Reproduction steps

No response

System

Version 8.2.7

---

Screen readers does not announce state and position count on controls present at the left navigation in windows

Describe the bug

User Impact:
Visually Impaired users who uses screen readers will be impacted as Screen readers (Narrator) does not announce state and position count on controls present at the left navigation in windows.

Pre-Requisites:
Enable Narrator

Actual Result:
Screen readers (Narrator) does not announce state and position count on controls present at the left navigation in windows.
Narrator announces: Link Docs

Refer Attachment:
1.Screen readers (Narrator) does not announce state and position count on controls present at the left navigation in windows.png
2.Screen readers (Narrator) does not announce state and position count on controls present at the left navigation in windows.mp4

https://github.com/user-attachments/assets/29b4bb54-d88e-414d-8036-54dd44def19f

Expected Result:
Screen readers (Narrator) should announce state as selected/ not selected and position count as 1 of 18 on controls present at the left navigation in windows.

Reproduction link

https://vivacommonstorybooktest.z13.web.core.windows.net/?path=/docs/app-bar--docs

Reproduction steps

1. Open URL: https://vivacommonstorybooktest.z13.web.core.windows.net/?path=/docs/app-bar--docs in edge browser in windows.
2. 'App Bar - Docs' page will be open.
3. Press tab key to navigate to the 'Docs' control present at the left navigation.
4. Verify whether screen reader announces the state and position count on controls present at the left navigation in windows or not.

System

not relevant

Work to do

Sidebar UI - Tree 2.0 project

• Implement the sidebar using a Primer TreeView
• Make relevant UI changes to match the Tree 2.0 2025 design file
  • New icons for roots and composed roots?
  • Code new sidear UI
  • Scope out UI rework of testing module and search/header
• Make it possible for tree items to advertise a secondary actions menu
  • Register a keyboard shortcut
  • Add a focus tooltip and appendix to the aria-label to advertise the shortcut(like GitHub sub-issues)
  • When the shortcut is pressed, open a modified version of ContextMenu
    • Always add navigation to the page/story/test as the first menu item
    • Make test statuses links? (@MichaelArestad I think we did not solve that yet); OR verify if we can find a path to WCAG compliance with status items in a menu role
  • Port the composed root context menu to be keyboard-navigable too (see "View external storybook" & "Read composition docs" controls are not accessible using keyboard in Windows and Mac. #29681)
• Implement keyboard actions: keyboard actions should always have a single effect, e.g. opening/close a tree node, and navigating on a leaf node
• Implement mouse actions:
  • Decide: either do both expand+navigate as we used to, or stick to the same model as keyboard actions and require more clicks (@MichaelArestad wants to test that)
  • Perform user research for validation if needed
• RefBlocks: header can be aria-expanded but needs a supporting role
• RefBlocks: error state, Show Error has aria-expanded without supporting role
• RefBlocks: has an aside element which is wrong (multiple aside violation)
• Tree: if we still have disabled items, they need an aria-disabled attr

Sidebar-adjacent APIs

• Change renderLabel
  • Pass isMobile to users to help with content length and layout calculations
  • Pass status information without relying on experimental APIs?
    • As this is not possible yet (API still experimental), at least ensure the sidebar layout always reserves space for StatusIcon to avoid issues like UI: Need for an API endpoint for renderLabel users / addon authors to know if a sidebar item has a status preview #31220
• Add renderAriaLabel endpoint to the sidebar API (mandatory)
• Consider adding renderIcon to let users more easily customise sidebar icons (RFC process): RFC

Sidebar accessibility followups

cc @MichaelArestad feel free to grow this list and I'll move it into a proper tracking issue later

• Search bar rework? sticky, top-level icon + replace header with input
• Consider top-level tree node for Recently Opened items instead of the current UI
• Consider adding a pinned stories tree node (then how do we pin stories?)

[greptile-apps]

** Disclaimer** This information might be inaccurate, due to it being generated automatically
This appears to be an issue with the sidebar navigation components. The fix would involve:

1. Locate the sidebar navigation components in code/ui/src/components/sidebar/
2. Remove tabindex="-1" attributes from button and link elements
3. Ensure proper keyboard navigation by implementing consistent focus management:

<Button
  onClick={onClick}
  // Remove tabindex={-1}
  role="menuitem"
  aria-expanded={expanded}
>
  {children}
</Button>

4. Update any related focus management logic to allow both arrow key and tab navigation to work together seamlessly

The core navigation behavior should be modified to support both arrow keys and tab key navigation uniformly across all interactive elements.

About Greptile

This response provides a starting point for your research, not a precise solution.

Help us improve! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

Edit Issue Bot Settings · Greptile

[Sidnioulz]

There is a need to review the keyboard navigation pattern in the sidebar. It's not clear to me what pattern is most suitable, so I've asked the experts here.

I'm gearing towards a disclosure navigation pattern (which should result in this outcome). This pattern has decent AT coverage.

A treeview navigation pattern could be explored as an alternative. This pattern is unusual and has unknown AT coverage.

EDIT: a11y experts recommended that we do not use the treeview pattern. We should start from a nested nav list and use progressive disclosure patterns within groups/components to show or hide all the child nodes.

[Sidnioulz]

GitHub has allegedly successfully implemented an accessible tree view navigation for their file tree widget. I've reached out to GitHub folks to double-check if those are well supported with VoiceOver, which is what I was warned about. Should I not manage to reach them, we should be able to test VO support with AssistivLabs ourselves.

See https://github.blog/engineering/user-experience/accessibility-considerations-behind-code-search-and-code-view/ and https://github.com/primer/design/blob/main/content/components/tree-view.mdx