Starting in Firefox 63, sections of a web document marked with aria-hidden="true" will have their sub trees completely removed from the accessibility tree.

Background

The aria-hidden attribute can be set on an element to mark it and all of its descendants as hidden from accessibility, and therefore any assistive technology, while at the same time retaining visible status on the screen itself. In this form, it is different from CSS properties such as display:none; and visibility:hidden;, which truly hide content from both the seeing eye as well as the accessibility programming interfaces.

As noted in the ARIA 1.1 specification, extreme caution should be used when using this attribute. It may hide content from users of assistive technologies such as speech recognition, switch control, or magnifier users that they actually need to access. For more information on the different way of hiding things, I recommend this read by the Paciello Group.

The change

Both Chrome and Safari have traditionally always unconditionally cut the element marked with aria-hidden=”true” from the accessibility tree on all platforms. But as soon as a focusable element was within that tree, this means that there is no accessible object associated with that focusable element, so the screen reader in use would not speak anything. And despite many criticisms and discussions over the years, this has never been addressed other than the above mentioned warnings in the specification.

Up to and including Firefox 62, the Gecko engine, however, advertised for a different model where aria-hidden content was merely marked as hidden, but still included in the accessibility tree. Assistive technologies could then decide whether to expose, and interact with, such elements or not. For us, this solved the problems that focusable aria-hidden elements were still speaking when focus was set to them. They also remained accessible to magnifiers and other assistive technologies.

However, this approach did not gain any traction since it was implemented, and it caused more confusion with web developers than it solved problems. So, in the spirit of better interoperability among browsers, we heavy-heartedly decided that it was time to fully go with the specification as it stands today and finally cut the aria-hidden tree in Firefox 63 and later. This means that stuff marked with aria-hidden=”true” will now fully disappear from the accessibility tree, also reflected in our Accessibility Inspector, as it does in other browsers.

Unanswered questions

Despite of this, some questions remain, like the disconnect between user expectation, gained from what’s visible on the screen, and what is exposed via the accessibility tree. Especially users of magnifiers, speech recognition products, and switch control users could be adversely affected by the wrong use of aria-hidden if such elements that are hidden acutually comprise operable controls. The same is true for keyboard focus.

But for certain situations, such as marking a whole section as “not available” or “inert” as a modal popup is opened, for example, there is currently no solution available other than aria-hidden, to properly hide content that is, for a given situation, considered to be non-operable. As long as elements such as the dialog element aren’t fully supported on all browsers (Firefox included), or the specification for the inert attribute is not solid enough to be considered implementable, the beast that is aria-hidden is the only one we have to wrestle such situations.

We’re not happy, but at least now, we’re consistent.

Related Articles

Also on:

48 thoughts on “Firefox 63 will cut subtrees marked with aria-hidden

  1. Encountered situations where what it says when focus lands in a hidden subtree vs why it doesn’t appear on the page itself allowed me to figure out what was going on. What would it speak when this is pruned, just nothing?

    via twitter.com

  2. Nope, and the reasons are given in that blog post. We’ve finally decided that it’s currently better to be interoperable than inconsistent. I don’t like it, either, but that’s the way it currently stands, and we’re not reverting it again for now.

    via twitter.com

  3. No, they should not, but this change doesn’t usually make them notice it, since they often enough don’t run with screen readers. Now, if they do, they at least hear that they are sending focus into nothingness.

    via twitter.com

  4. I don’t like this either. From the outsider’s perspective it feels like throwing away something halfway necessary in order to be convenient to devs by some sort of weird metric of convenience I don’t understand.

    via twitter.com

  5. I get that the decision is made. I even sort of see why. But given how terrible people are at Aria and the fact that no one tests, I think we should be going the other way and making Aria overriding more and more optional.

    via twitter.com

    • Yes, I think this is the best solution we currently have available. This area is tricky to get right, and it is our hope that with this change, we can at least be consistent enough.

Reposts

  • Halena
  • Alvaro
  • Jonathan Chacón
  • Accesibilidad web
  • Tea Turkovic
  • mallory, alice & bob
  • Nikolay Cholakov🙏4❤
  • SteveALee
  • Matt McCubbin
  • Web Axe
  • Nikos Demetriou
  • Diego Ramírez
  • Marco Zehe
  • Drew Mochak

Mentions

  • Deque Systems
  • Web Axe
  • The Paciello Group
  • xirclebox 💻
  • Hidde
  • Steve Faulkner
  • Alvaro
  • caztcha
  • Marco
  • L. Lamar Jordan
  • Johan Ramon
  • 富永冴樹

Leave a Reply

Your email address will not be published. Required fields are marked *