aria-expanded does not require a fallback

Published 22 January 2018 category: code

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 true of 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.

No fallback

These are some reasons not to provide a fallback for aria-expanded.

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.

Non-standard text

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.

Thanks Léonie, Roel, Job and Jules for feedback and advice.

Update 22/01/2018 4.56pm: The Paciello Group notes: “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”).” They added to that, to not use this at the same time as aria-expanded, as “that would be redundant”.

Comments & mentions (32)

Roel Van Gils 22 Jan 2018 12:44:00

I agree with the conclusion (don’t add fallback sr-only text when using aria-expanded).

As a sidenote, I’d like to add that in many cases I think it’s not even necessary to overcomplicate an interface for SR users, using collapsed / expanded content. For example. Especially in siuatons where a part of the page or interface is only being ‘collapsed’ to minimze clutter, as an effort streamline the visual (!) appearence.

You can write your HTML and CSS in such a way that content seems to be ‘already there’ (as in ‘expanded by default’) for SR users.

If you think about it, SR users already consume your content in a linear manner, by using headings and landmarks to quickly skim a page. If they then decide to read the contents underneath a heading, they already need to use a shorcut or gesture to read what’s next. So, in a way, a lot of content or functionality already appears ‘collapsed’ (as in: invisble) to these users. Having them manually collapse / expand that content (using a link Open / Close, for example), often (not always) feels like an unnecessary step.

Job likes this
Eric Eggert likes this
Heather likes this
Adam Silver likes this
Dine | Ariadne Gomes likes this
Hugo Giraudel likes this
nienke likes this
Eric Eggert reposted this
Job reposted this
Mikkel Ax reposted this
✍(*@')✌︎ reposted this
Marco Zehe reposted this
Bram Duvigneau reposted this
Mark Hamstra reposted this
Léonie Watson replied: Useful notes on using aria-expanded, by @hdv…
Léonie Watson replied: Useful notes on using aria-expanded, by @hdv…
Кафедра КНІТ УАД replied: Useful notes on using aria-expanded, by hdv…

— Léonie Watson (LeonieWatson) January 22, 2018…
Krijn Hoetmer replied: Wat @roelvangils zegt!
Frozen Rockets replied: “aria-expanded does not require a fallback”, by…
Frozen Rockets replied: “aria-expanded does not require a fallback”, by…
The Paciello Group replied: This post recommends not using hidden text to convey the state of aria-expanded controls.

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”). replied: “aria-expanded does not require a fallback”…
Bram Duvigneau replied: Thanks for writing this, I totally agree with your conclusion and have explained this to clients for years. Now I can just point them here :)
Hidde replied: Aw that means a lot coming from you, thanks Bram!
まとり replied: 見てる / aria-expanded does not require a fallback…
若気の至り(60) replied: aria-expanded does not require a fallback…
CSS-Tricks replied: `aria-expanded` does not require a fallback ::…

(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.)
Trevor Pierce replied:… #a11y
Access42 replied: 4 bonnes raisons de ne pas implémenter de fallback pour l'attribut aria-expanded #a11y #accessibilité #webdev #ARIA…
.Hiroya replied: 共有してもらった記事が素敵だなとおもったのでTLに流しておきます。

.Hiroya🍣🍵 replied:
WAI-ARIAのaria-expanded属性を使いつつ、文言(アクセシビリティネーム)の切り替えをしている例をたびたび見かけますが、実はテキストの切り替えは要らなかったりします🤧 aria-expanded does not require a fallback… #駆け出しエンジニアさんと繋がりたい #a11y
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.