The state of hidden content support in 2016

Posted on Tuesday, 26 January 2016 by Steve Faulkner

ARIA and HTML5 I have reported previously on support in browsers and screen readers (SR) for aria-hidden and the HTML5 hidden attribute. The last time was 2 years ago, the orginal article published 2 years prior in 2012 still gets lots of page views. As its a subject that developers are interested in, so here is an update.

Support for HTML5 hidden and aria-hidden in 2016

Summary

All major browsers and screen readers:

  • support the use of the hidden attribute to hide content
  • support the use of the CSS display:none to hide content
  • support the use of the aria-hidden attribute to hide visible content from screen reader users

The Details

Screen reader support for hidden content – tests and results for

  • Windows 10
    • Firefox 43
    • Internet Explorer 11
    • Chrome 47
    • JAWS 17
    • Window Eyes 9
    • NVDA 2015.4
    • Narrator 10
  • VoiceOver on iOS 9.2.1 (iPhone 6)
  • VoiceOver on OSX El Capitan
  • ChromeVox  on Chrome OS 47
  • Orca 3.16 on Linux

Notes:

In some browser and screen reader combinations aria-hidden=false on an element that is hidden using the hidden attribute or CSS display:none results in the content being unhidden. This behaviour does not have consensus support among browser implementers and I strongly recommend, it not be used.

Why no Edge testing? The Edge browser does not yet have sufficient accessibility support for testing to be useful.

The hidden attribute hides content due to browser’s implementation of CSS display:none on content hidden using the attribute. If the default UA CSS is overidden, then aria-hidden=true will have to be used alongside the hidden attribute:

See the Pen gPvoNR by steve faulkner (@stevef) on CodePen.

Tests and results on github – issues and PR’s welcome!

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 Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including HTML 5.1, ARIA in HTML, Notes on Using ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility.

Comments

  1. I do have a question. Will toggling the hidden attribute trigger role=”alert”?

    It will have same support for triggering as changing the display from none to whatever. hidden currently has no special wiring to acc API’s its effect is due to it’s UA CSS styling, hence the example in the notes.

  2. Unfortunately, in our experience, it also depends on what type of content element we’re talking about. Focusable elements, e.g. links, cannot be hidden reliably, as they can still be reached by screenreaders in focus mode. (And there are situations in which it would improve the user experience, if such elements could be hidden.)

  3. Hi Andreas,

    Focusable elements, e.g. links, cannot be hidden reliably

    hidden and display:none hide interactive content fom all users reliably.
    I can’t think of a case where interactive content should be available to some users and not to others:

    Fourth rule of ARIA use
    Do not use role="presentation" or aria-hidden="true" on a visible focusable element .
    Using either of these on a visible focusable element will result in some users focusing on ‘nothing’.

  4. Steve,
    Thank for your reply, although ‘can’t think of a case’ is an argument, which seems in principle limited in scope (no matter how far you can actually think). ;o)
    We’ve worked on systems, where interactive maps with POIs are not accessible, but the same info is presented in a table, which is only hidden visually, but made accessible for screenreader users. There, it would be an advantage to help screenreader users reliably avoid the maps application. Or, quite regularly in teaser design, you would want to reduce link redundancy for screenreader users, but that is limited by aria-hidden not reliably working for focusable elements. Of course, I fully agree with you that great care must be taken what to hide for whom.

  5. As opposed to VO and TB, Jaws failures are inconsistent across browsers

    In this case its due to browser failure, JAWS has to hack DOM in IE.

  6. When a page or tab content loads, it is getting read by screen reader before user actually starts interaction with page. Is it acceptable scenario?
    Can we use aria-hidden conditionally to hide this content from screen readers till user takes action on page?

  7. Adding to above comment from Vincent François, should we hide the ‘*’ used in labels of mandatory fields from screen reader? Is that required?

    What about special terms and conditions mentioned using * on the same block of text.

  8. Adding to above comment from Vincent François, should we hide the ‘*’ used in labels of mandatory fields from screen reader? Is that required?

    no it isn’t a requirement.

  9. When a page or tab content loads, it is getting read by screen reader before user actually starts interaction with page. Is it acceptable scenario?

    Depending upon the screen reader and user preferences set, the content of the document may be announced without user interaction, this is expected and not uncommon.

    Can we use aria-hidden conditionally to hide this content from screen readers till user takes action on page?

    This is not a good idea as in the case of windows screen readers, when a user navigates non interactive content in virtual mode they are not interacting with the browser content, but a virtual representation of it.

  10. Would there be any objection/problem with using a css-selector like this:

    [hidden][aria-hidden=”false”] {
    clip: rect(0 0 0 0);
    display: inherit;
    position: absolute;
    }
    [hidden][aria-hidden=”false”]:focus {
    clip: auto;
    }

  11. Hi Steve

    > I can’t think of a case where interactive content should be available to some users and not to others

    What about the case of a button that only alters the visual appearance of some other element (i.e. the height of a container) but has no effect on content presented in the accessibility tree? – I think it would improve the experience of screen reader users if we’d hide such visible and focusable buttons instead of announcing an interaction devoid of meaning for them.

  12. Hi Esther,

    We can’t assume that people who use assistive tech that makes use of the accessibility tree have no need for visual display changes. Users of screen readers for example include low vision users and those with cognitive impairments.

Comments for this post are closed.