The state of hidden content support in 2016

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!

Categories: Development

About Steve Faulkner

Steve is the Technical Director at TPGi. He joined TPGi 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.

Comments

Ted Drake says:

I was surprised to see decent support for hidden: http://caniuse.com/#search=hidden. I do have a question. Will toggling the hidden attribute trigger role=”alert”?

Steve Faulkner says:

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.

Andreas says:

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.)

Steve Faulkner says:

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’.

Andreas says:

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.

Neil Osman says:

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

Steve Faulkner says:

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.

Hi,

What’s about a input field with a “+” and a “-” buttons.

Should we hide from screen reader the two buttons – but they are focusable – breaking the 4th ARIA rule?

Sample : The travelers (after the dates) in the Flights form here : http://www.airtransat.com/en-US/americas?str_flightType=RT&str_gateway=FAO-YUL&str_pax=1-1-0-2&str_date=_03%2F22%2F2016

Mukesh Pant says:

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?

Mukesh Pant says:

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.

Steve Faulkner says:

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.

Steve Faulkner says:

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.

Evert says:

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;
}

Esther Brunner says:

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.

Steve Faulkner says:

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.

Esther Brunner says:

Hi Steve, thank you for your answer!