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!
Comments
I was surprised to see decent support for hidden: https://caniuse.com/#search=hidden. 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.
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.)
Hi Andreas,
hiddenanddisplay:nonehide 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:
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.
Thanks. 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 : https://www.airtransat.com/en-US/americas?str_flightType=RT&str_gateway=FAO-YUL&str_pax=1-1-0-2&str_date=_03%2F22%2F2016
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?
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.
no it isn’t a requirement.
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.
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.
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;
}
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.
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.
Hi Steve, thank you for your answer!