When building a control that toggles content in a web app, we can use
aria-expanded to let the control know whether the content is shown or hidden. Expanded or not expanded. In assistive technologies (AT) that support this attribute, AT users can figure out whether the element was expanded.
The other day, a website I worked on was audited for accessibility compliance. The auditor suggested we would add a fallback for
aria-expanded, so that it would work for more users. After some discussion back and forth, we decided against this and went with no fallback.
For those who don’t know the attribute,
aria-expanded is an attribute you can put on a button that toggles content. When toggling the content, you update the attribute to be
false. This lets browsers, accessibility APIs, platform APIs and ultimately your end users know that the thing is now open or closed. It is the mechanism that powers the
details element in HTML, but you can also use it on your own controls, for example a hamburger menu or in a questions and answers sections.
Providing a fallback
For users of AT that does not support the
aria-expanded, a fallback can be implemented. One way to do this is to simply add visually hidden text that conveys the control’s state:
<span class="visually-hidden"> (expanded)</span>
I would not recommend this. Yes, if we add this text like this to the control, it will get conveyed to users of AT. With it, potentially more users can use and understand the control. However, it might cause more problems than it solves.
These are some reasons not to provide a fallback for
A string that needs maintenance
There is now a string of text that needs to be maintained. It sits in your markup, it requires time to explain to new team members and you’ll have to decide whether you want it managed by a CMS.
If you add this text yourself, you or your colleagues may end up picking different text across the site. Or text that is different from what users hear on other sites that have expandable elements in them. And if someone new starts on the team, they may not understand what this is and can’t look it up in a spec, as it is not standard.
No automagic localisation
Screenreaders that support
aria-expanded, will read out the status of the control: when it is collapsed, it says ‘collapsed’, when it is expanded, it says ‘expanded’. This is if your screenreader speaks English. If it speaks Dutch, it adapts and will say ‘ingeklapt’ or ‘uitgeklapt’, respectively. It’s up to the screenreader and its settings what it says, but we can be sure it will be consistent and free of maintenance.
Redundant for most users
Users that use AT with
aria-expanded support, will hear the status twice. Ok, this can be mitigated by using hidden text instead of the attribute, but then the other points still stand.
So what is AT support like?
The question this might leave you with: what is AT support for
aria-expanded like? It is well supported across platforms, and works in screenreaders like JAWS, NVDA, VoiceOver and Narrator. This means a fallback would leave most AT users to hear the status twice, to solve a problem for very few.
So, in conclusion: it is now best to use
aria-expanded without fallbacks.
Comments, likes & shares (31)
Job, Eric Eggert, Heather, Adam Silver, Dine | Ariadne Gomes, Hugo Giraudel and nienke liked this
Job, Eric Eggert, Mikkel Ax, ✍(*@')✌︎, Marco Zehe, Bram Duvigneau and Mark Hamstra reposted this
— Léonie Watson tinktoot.cafe (LeonieWatson) January 22, 2018
To be sure, if an expand/collapse <button> makes use of visible text, it’s still fine to update its visible text (such as perhaps between “expand recipe details” and “hide recipe details”).
(As in, don't use screen-reader-only text to announce the new state. An alternative is to change the text of the button itself.)