HTML5 Accessibility Chops: hidden and aria-hidden support on the UP!

Posted on Friday, 29 November 2013 by Steve Faulkner

ARIA and HTML5At the start of 2012 I published results on the state of HTML5 hidden attribute support and aria-hidden attribute support. Based on the results, advice was provided on the best methods to hide content from some or all users.

A recent tweet has prompted a re-examination of support for these attributes in some popular browsers, screen readers and operating systems.

support landscape is no longer depressing

  • aria-hidden=true on visible content is now uniformly supported across a range of popular browsers, screen readers and OS’s
  • The HTML5 hidden attribute is now supported in all major browsers.
  • aria-hidden=false on hidden (via hidden attribute or CSS display:none) content is supported in some browser/AT/OS combinations.

detailed results and test cases:

Screen reader support for hidden content – November 2013

Further reading:

Note: in the latest tests, the Window Window Eyes screen reader was not tested, if anybody has access to it or other AT and would like to provide data from the tests cases, drop me a line.

Thanks to @patrick_h_lauke, @graemecoleman and @stommepoes for help with testing!


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

  1. Great news that the hidden attribute is better supported now.
    I think we just need a better method for “screen reader text” now, i.e. for text that is not visible but announced by screen reader.
    The only reliable way to do it at the moment is to use the CSS off-screen method, which can cause problems for right-to-left systems and is essentially a hack. I’d like to see either a new attribute or a new CSS style specifically to hide content visually but have it read by screen readers. I know it will require some work from all parties, but I can see a real need for this.

  2. Hi Stefan,

    I think we just need a better method for “screen reader text” now, i.e. for text that is not visible but announced by screen reader.

    We already have the beginnings of support for it with hidden/display:none + area-hidden=false. This combination is currently supported by By JAWS/IE, TalkBack/Chrome and Chromevox/Chrome OS

  3. We already have the beginnings of support for it with hidden/display:none + area-hidden=false.

    So, I’m kind of confused on how hidden/aria-hidden interact/don’t interact. Am I right in the following?

    aria-hidden=true => nothing in styles/etc, relevant to screen readers but not sighted users
    hidden => is hidden (with or without styles, depending on browsers) from both sighted users and screen readers
    hidden + aria-hidden=false => As above

    So, if I have an element that is only relevant to sighted users, I may add aria-hidden=true to it. If it should be hidden from both I use hidden, and if it’s relevant only to screen readers (say a label to something that’s obvious to a sighted user), I should set it to hidden + aria-hidden=false?

    Also, thanks for good articles.

  4. hi Marie,

    aria-hidden=true => nothing in styles/etc, relevant to screen readers but not sighted users

    correct

    hidden => is hidden (with or without styles, depending on browsers) from both sighted users and screen readers

    The HTML5 hidden attribute hides content from display it also is semantic indicator that content is the hidden state, it is typically implemented in browser by a CSS display:none rule in the user agent style sheet. This does mean that authors can override the display effect of hidden by setting display:block on a &alt;element hidden>.

    hidden + aria-hidden=false => As above

    What this combination means is that content is hidden from visual display and has a state of hidden, but is not in the hidden state in the accessibility tree, so should be available to users of software that expose content to users based on whats in the accessibility tree (such as screen readers).

  5. quote: ” and if it’s relevant only to screen readers (say a label to something that’s obvious to a sighted user), I should set it to hidden + aria-hidden=false?”

    Hm, even an obvious label is still something that you’d say “belongs” in the web content, so an off-screen positioning (unless you’ve got rtl stuff going on) is backwards-compatible, matches the semantics of “form fields have labels” and currently still works better than aria-hidden. I think I even see using aria-hidden as a replacement for off-screen positioning as a hack for rtl pages, because while it would work better, it would semantically be saying “there really shouldn’t even be a label here as far as all UAs are concerned”. Which isn’t usually true in this situation; it’s usually a design- and possibly usability-thing to hide the “obvious” label.

    I think of using “hidden” the way we have input type=”hidden” for sending additional info to scripts… we wouldn’t actually give that input to any users, anywhere, no matter what, so now these inputs should have a default “hidden” attribute (?) and I assume an implicit aria-hidden attribute too.

    There was also a mention on WebAIM comments of using aria-hidden in the cases of something like a dialog box, where once that dialog is open, that’s all that should be available to the user– any user, until they close it or do something with it. The (hacky-sounding) proposal was to set aria-hidden on the whole page, and the dialog, who’d be outside the page, would be the only default-nonhidden stuff left over.

  6. After doing some work with icon fonts, whose content is usually set using the content property on :before and :after pseudo-elements in CSS, I found myself wanting a better option to hide the icon font glyph from screen readers. Is there a more widely supported option for this other than speak: none?

  7. Thanks for the interesting an timely post.

    Coincidentally, an aria-hidden solution will be added into the WordPress admin screens very shortly. The aim is to provide meaningfully verbose links for screen reader users whilst keeping visible brief links for sighted users where context is supplied by surrounding text. Simply hiding portions of a link or label doesn’t really work grammatically in all languages.

    One example of where this occurs is the Publish box when adding or updating a page or post. The links in this box are Edit, Edit, Browse, Edit – obviously not enough for screen reader users.

    I’ve blogged more fully about the solution on my own site. Whilst investigating this solution I did some testing on a variety of screen readers – Jaws 14 + NVDA on Windows, VoiceOver on iOS7 iPad and Talkback on Android phone. My results were also heartening, with all the combinations except for Talkback behaving as hoped. On Talkback, both elements of the links were audible – Talkback obviously was not respecting aria-hidden. One other ‘feature’ on VoiceOver was that the visible focus box did not include the aria-hidden text.

    For the screen reader portion, WordPress will be initially sticking to the ‘move it off screen’ approach – good support there, but I note your comments about aria-hidden="false" display:none.

    I also tested the twin text approach with Dragon Naturally Speaking. Usefully, Dragon users can use either form of the link to action it. This is due (I guess) to the well documented lack of support for aria-hidden in Dragon.

  8. Hm, even an obvious label is still something that you’d say “belongs” in the web content, so an off-screen positioning (unless you’ve got rtl stuff going on) is backwards-compatible, matches the semantics of “form fields have labels” and currently still works better than aria-hidden.

    Before I continue, I will say that I’ve actually not found any case as of yet where I would want to hide something from a sighted user while revealing it to screen readers, so my examples kind of … suck =)

    One thing I’d probably do at the event where I’m wanting hidden=true, aria-hidden=false is to combine those with the above-mentioned CSS, for the same reason that I’m likely to add display:none to elements that are [hidden]: backwards compatibility.

  9. One thing I’ve always been curious about is how to balance between using a hidden/clipped element on the screen vs adding an "aria-label" attribute directly on an element. It seems like the use case would often be similar (adding some kind of a description string but hiding it visually) but at least with the label approach, you’re not introducing another element to the DOM and having to worry about hiding it. Any recommendations on when to use either technique?

  10. We already have the beginnings of support for it with hidden/display:none + area-hidden=false. This combination is currently supported by By JAWS/IE, TalkBack/Chrome and Chromevox/Chrome OS

    We also already have support for aria-describedby="hiddenSection". But these are perhaps different use cases?

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

I am thrilled to hear that TPG will be part of the state blanket contract allowing our agencies to use your unique expertise and broad knowledge of accessibility. This is a bright day for citizens of the Commonwealth of Massachusetts.

Sarah Bourne, Director of Assistive Technology – IT Division, Commonwealth of Massachusetts