How I came to grudgingly accept aria-hidden

Yes, that’s right, I grudgingly accept the fact that aria-hidden is here, and most probably here to stay. Those of you who know me and have been involved in discussions with me, like poor Victor Tsaran, whom I pestered more than once to give me tangible evidence that aria-hidden solves problems normal visibility techniques don’t, know that I’ve been always a strong opponent to give web developers that much power over the accessibility tree. Unlike role “presentation”, which marks only one particular element as uninteresting for accessibility, aria-hidden does the same for an element and all its child elements.

Especially considering that Chrome and Safari mercilessly prune the whole tree underneath and including the element marked with aria-hidden=”true”, dangerous things can happen if aria-hidden is used irresponsibly or carelessly. What can happen in such a circumstance is that a child element of that tree is, or becomes, focusable, but there is suddenly no accessible for it.

Firefox, therefore, takes a less offensive approach. We give aria-hidden marked elements an object attribute, but leave the element and its children in tact in the accessibility representation otherwise, so that screen readers can opt-in to ignore the sub tree.

And this is where Firefox OS suddenly comes into play. When Eitan and I started working on this a year ago, we immediately noticed that there were several problems with Gaia, the UI and apps library shipping on Firefox OS devices. It is built completely in HTML, CSS and JavaScript. When i started playing with a device, I noticed that apps were showing me content that was not on the screen, didn’t go away when I closed them, etc.

The reason for this behaviour was the fact that much of the styling in Gaia uses the z axis to “hide” elements. They just get pushed into the background. But putting stuff on a negative z axis does not prune them from the accessibility tree traditionally.

Eitan then started experimenting with changing the visibility to use display: none; or visibility: hidden; instead, depending on the reflow demands. While this solved some problems, it definitely didn’t solve all of them. Most importantly, there were often visual artefacts interfering with animations and other things. And the last thing we want is that accessibility is the cause for visual unpleasantness!

So in the course of the last two months, it became apparent that the least intrusive method of solving this problem is to introduce aria-hidden in strategic places into Gaia to manage what is visible to our screen reader, and what is not. Consequently, our screen reader for Firefox OS was enhanced to support ignoring trees that are marked with aria-hidden.

And here it is, the reason why I grudgingly accept aria-hidden as a useful reality. It not only solves a big chunk of problems with only a few attributes in strategic places. It also makes sure we do not interfere with the visual experience, and it saved us from having to touch each and every CSS in Gaia to manipulate it to fit our needs, and by doing so, cause that visual degrading we want so desperately to avoid. Also, it helps prevent breakage, because Gaia developers can change the relevant CSS without having to be afraid to break accessibility

So while I was searching for external sources to tell me why aria-hidden is actually useful and needed, the reason that convinced me built up inside Mozilla! :-)

I still think that aria-hidden is a rather dangerous attribute, I count on the educational skills of the accessibility community at large to make sure the situation doesn’t get really bad! And I will do my part to help with that effort!

7 comments:

  1. There’s another few areas where it is useful:

    I remember a few years ago Bram Duvigneau asking on ze twitters if anyone had a cross-device working solution for (temporarily) hiding form elements. It’s one of those special cases where display:none doesn’t do what it normally does. Form elements were still often accessible. While my solution at the time was to have text (hooked up to the fieldset or legend with aria-describedby or something) that stated whether or not the user had to fill that fieldset in (a group of questions only showed if someone said “yes” to an earlier question), aria-hidden would have helped even more.

    There’s also a technique some are using with aria-hidden for dialogs where you have non-focusable non-application text inside which get ignored/hidden if you try to use the role you’re told to use: “dialog”. Instruction text, helper text, and hints are all gone. But you want the dialog to clearly be a dialog… so some people are avoiding the use of the dialog role, storing the dialog outside the main page container, and setting aria-hidden on everything inside the page container until the dialog is closed somehow.

    There are probably some other use cases as well, but I still think there will probably be more abuse than good use with it. I guess the good news is that ARIA stuff is still primarily used by devs who actually care about accessibility, and therefore are most likely to try to use it properly… devs who don’t care, don’t use ARIA. (some javascript libraries excepted maybe)

  2. Interesting timing.. Yesterday I help debugging a registration form where custom select boxes where used. To make them look nice the trick is to make them transparent and overlay them on top of a string of text that represents the selected option. When pointing device users want to interact with such boxes, they click on the box that contains the string, but in fact what they end up interacting with is the transparent select box – which once opened show the option fully opaque (it works nicely). Once the selection is made we change the visible string. The problem is that we have redundant data because the option + the visible string are identical (one transparent, one is not). And the best thing we found to solve this issue is aria-hidden.

  3. Does this mean that you might also be considering changing Firefox’s behaviour so that it removes an aria-hidden element and its descendants from the accessibility tree instead of just marking it with an object attribute?

  4. No plans right now. After a long discussion, among others here, we settled on the current implementation. and since this is already being supported by some assistive technologies besides our own mobile screen reader, it is not easy to change.

  5. Let me give an example of an IMHO meaningful use of aria-hidden:
    Avoid doubled anouncement of „Navigation“

    <div id=”navi” role=”navigation”>
    <h2 aria-hidden=”true” >Navigation</h2>
    <ul class=”klappen”>

    aria-enables browsers/screen readers read the role, but omit the <h2>
    older systems read the <h2>, but not the role.

    Did I miss out on anything?

What are your thoughts?