The accessibility specification on W3.org recommends using attributes like aria-expanded on an accordion’s header element to signify when an accordion is open or closed.
However, when an accordion is collapsed, the panel content is hidden, and it is usually good practice to mark hidden content with aria-hidden=‘true’. Mozilla’s docs for aria-hidden outline exceptions for the aria-hidden rule, but they don’t currently mention this use case.
My question: Is it better, worse or redundant to also add aria-hidden=‘true’ to the panel element when the accordion is collapsed?
The first ARIA rule says, don’t use it unless you really need it.
In fact, you should hide your panel with display:none or visibility:hidden, but not aria-hidden=true.
Attribute aria-hidden should normally be used when the content must be hidden to screen reader and other assistive tools, while visible on screen.
If the content must be hidden for everybody, screen reader or not, you should rather use display:none or visibility:hidden instead.
Then as the doc copied in the other answer says, display:none or visibility:hidden are enough on their own, aria-hidden=true is superfluous. The big risk in adding it isn’t creating bugs, but forgetting to remove it afterwards when the panel becomes visible, at which point your content become visible but totally inaccessible.
This aria-hidden=true look very practical, but it is in fact used incorrectly 99% of the times when display:none is enough, much simpler, and almost without any risk to forget about it. Attribute aria-hidden=true should only be used in very specific cases, and these cases are quite rare.
Its use getting widespread causes often more harm than it actually helps improving the experience for screen reader users, and believe me, I’m myself a blind user.
The MDN doc copied in the other answer miss a very important point.
If the content has any interactive / focusable element, you really must not use aria-hidden=true.
Otherwise, a screen reader will behave weirdly when that element is focused: it has to read something, but it isn’t supposed to read something hidden; and the focusable element can be reached with tab but not with arrow keys, what is very confusing for the user.
It depends on what is hidden. If the content is relevant to the user and the user needs to know about the hidden content, don’t add the attribute, so assistive technologies present that content to the user.
If the content is unimportant/redundant and non-interactive, add the attribute, so assistive technologies can ignore it. Thereby, you are streamlining the experience for the user relying on that technology.
As per MDN docs:
The aria-hidden attribute can be used to hide non-interactive content
from the accessibility API.Adding aria-hidden=”true” to an element removes that element and all
of its children from the accessibility tree. This can improve the
experience for assistive technology users by hiding:
- Purely decorative content, such as icons or images
- Duplicated content, such as repeated text
- Offscreen or collapsed content, such as menus
The presence of the aria-hidden attribute hides content from assistive
technology but doesn’t visually hide anything.
MDN also lists some technological criteria for when to omit aria-hidden:
aria-hidden=”true” should not be used on elements that can receive focus. Additionally, since this attribute is inherited by an element’s children, it should not be added onto the parent or ancestor of a focusable element.
…
aria-hidden=”true” should not be added when:
- The HTML
hiddenattribute is present- The element or the element’s ancestor is hidden with
display: none- The element or the element’s ancestor is hidden with
visibility: hidden
4