[Beta] Inaccessible UI Components

[colmtuite]

Accordion a11y issues

• When an Accordion trigger is focused, pressing down/up should focus the next/previous trigger.
• When an Accordion trigger is focused, pressing space should expand/contract its panel.
• The Accordion trigger should be a <button> rather than a <a>.
• The Accordion trigger should be wrapped in a h tag.
• The Accordion trigger should have an aria-expanded attr set to true when open.
• The Accordion trigger should have an aria-controls attr.

The same goes for the Tabs component (found in the sidebar and on code blocks), it fails a11y in many ways. I'd suggest you look at UI libs like Radix or ReachUI which provide high-quality, accessible UI components.

[gaearon]

Hmm. I'm not an expert on this (so sorry if I’m saying something silly) but the thing that makes this a bit nuanced is that the nav doesn’t really behave like an accordion. For example:

When an Accordion trigger is focused, pressing space should expand/contract its panel.

Pressing on it with a mouse doesn't expand/contract it either. (Try collapsing it! It won’t do that.) It’s not expandable/contractable in general. Instead, you can think of it as a regular website nav that shows the current site section’s subitems. Accordion is more of a styling choice.

The Accordion trigger should be a <button> rather than a <a>.

Same — it's not a button, it actually is a link. Its purpose isn't to expand the accordion but to navigate you to the section. I realize this might be a controversial choice. But from the perspective of how it works now, I don't believe a button would be the right choice.

Does this make sense or am I very much off base? I appreciate the report.

[gaearon]

In other words, my mental model is that the behavior of this panel is like in an old school website that does

- Home
  - Appointments
  - Procedures
- Blog
- About

Clicking on "Home" here doesn't do anything (except navigating to top-level Home page).

You navigate to Blog and the side nav instead becomes

- Home
- Blog
  - March 2022
  - February
- About

If you click on March 2022, then click on Blog again, the nav will stay the same. "Blog" stays expanded while you're in the Blog section. You can't "collapse" Blog.

And so on.

Imagine each of these is a link triggering a full page navigation and they're styled like a nested list rather than an accordion. Would you expose it as an accordion in the accessibility tree?

[colmtuite]

Gotcha. styled-components nav works similarly. I think the difference here is that the visual affordances (chevron, animation etc.) seem to be very much convincing me that it's an accordion. Then I get bummed out when it doesn't work like one. Right now it feels like a broken accordion imo, rather than a list of links.

So I'd say either it should work like an accordion, or look like a list of links.

[ashleemboyer]

Hey, y'all! 👋🏻 Came across this issue via Twitter. Adding some perspective as an engineer who focuses on accessibility, I hope that’s okay! 💖

First, would like to align on some terms. 😊 For Accordion and Tabs components, I think the ARIA Authoring Practices Guide (APG) defines them both fairly well.

• Accordion: "An accordion is a vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail representing a section of content. The headings function as controls that enable users to reveal or hide their associated sections of content."
  • Small note here: this APG pattern uses button HTML elements wrapped by heading HTML for the interactive parts, but the headings aren't required or necessary. Just button suffices.
  • To simplify the definition even further: an Accordion is a collection of Disclosures (components that show and hide content)
• Tabs: "Tabs are a set of layered sections of content, known as tab panels, that display one panel of content at a time. Each tab panel has an associated tab element, that when activated, displays the panel."

With these definitions, I don't think either an Accordion or Tabs is what we're seeing in the left sidebar of the beta.reactjs.org page.

• The "Home", "Learn", and "API" elements visually look like Tabs tend to look, but the markup is accessible based on how those elements behave. When activated, they navigate the user to a different page. If they were Tabs, they would change page content without a page reload.
• The section that shows after the Search button does visually look like an Accordion (a collection of Disclosures), especially with the chevrons that change direction based on the page you're on, but it's marked up correctly as if it was an "old school" (in @gaearon's words 😆), horizontal site navigation menu with drop downs.
  • I agree that the visual affordances are confusing. The chevron icons say to me "this is expandable", especially with the background color of the whole link changing on hover and the expand/collapse animations that happens on click. Not sure if this is the space for feedback (happy to place this somewhere else if it's helpful!), but I'd recommend a pattern like Adrian Roselli's site nav. For the links that have sub-links beneath them, there is a link to the main page and a button next to it to expand the menu. His article I linked is also a writeup of the pattern.

[gaearon]

Thank you so much for chiming in! Definitely appreciated. I agree the chevrons make this confusing.

[devongovett]

I agree that this is not an accordion. If anything, it's more like a tree. But I think putting a bunch of fancy aria/keyboard stuff for a simple website nav is probably overkill.

Only thing I'd suggest is probably the aria-expanded attribute on collapsible items, that way a screen reader will announce the collapsed/expanded state. You could also put aria-labelledby on the child <ul> element, pointing back to the parent item, so that a screen reader announces it when entering the sub-list in addition to the text of the item itself.