Back in 2010 I wrote some advice on how to hide iframe elements from screen reader users: Making sure hidden frames are hidden
10 years on the advice is largely redundant.
Some background
HTML is an aural UI for screen reader users. Sometimes announcing the element name, when a user navigates to the element, makes sense, other times it seems sort of clunky, jargonistic and even unnecessary (more noise than information). The majority of content is and has been robustly hidden using standard methods, for years.
Screen reader developers make the decisions about how and when the semantics of HTML will be conveyed to users (from what is available in the accessibility tree), hopefully based on user feedback. For most elements there is a strong correlation between the element role and how it is identified to users (unless the role is explicitly overridden using the [ARIA role
] attribute): JAWS for example.
How iframe
elements and their content can be hidden from screen readers
Noting that depending on the platform and screen reader there are multiple ways to interact with content. For example, in JAWS, you can navigate to a iframe
using the tab key (if the iframe
content includes focusable content, or in Firefox the iframe
itself is in the focus order) or using the M virtual navigation key or use the arrow keys to move through content (in virtual mode).
Read Understanding screen reader interaction modes by Léonie Watson for a detailed introduction to screen reader interaction modes.
Mostly Good Times
Nowadays unlike in the past all screen readers ignore iframe
s and their content when they are hidden using the hidden
attribute or CSS display:none
, nothing more is needed. There does not appear to be a method to hide visually displayed iframe
s from all screen readers. The following results are based on testing screen readers with these test cases
Screen reader (latest versions) | iframe + hidden |
iframe + display:none |
|
---|---|---|---|
JAWS | not announced | not announced | not announced |
NVDA | not announced | not announced | not announced |
Narrator | not announced | not announced | iframe content announced and operable |
VoiceOver Mac | not announced | not announced | iframe is in navigation order and announced as “application”, content of iframe is hidden. |
VoiceOver iOS | not announced | not announced | not announced |
Talkback Android | not announced | not announced | In Chrome if navigating by heading the heading in the iframe is announced. Not in Firefox. |
Fun Fact 1: Use of the title
attribute on an iframe
does not result in display of a tooltip when the mouse cursor is over the iframe
.
Fun Fact 2: If you hide content using the hidden
attribute or CSS display:none
you don’t need aria-hidden="true"
as the state is already exposed in the browser accessibility tree!
5 replies on “Hush Sweet IFrame”
What about
role="presentation"
in place ofrole="none"
, any difference?afraid not.
role="none"
is a synonym ofrole="presentation"
since ARIA 1.1. Look here: https://www.w3.org/TR/wai-aria/#note-regarding-the-aria-1-1-none-roleYeah, I think Birkir is aware, i hazard that he was thinking that there may be more robust support across implementations for
role=presentation
as it has been around a lot longer.[…] Hush Sweet IFrame […]