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.
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.
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
iframes 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
iframes from all screen readers. The following results are based on testing screen readers with these test cases
|Screen reader (latest versions)||
|JAWS||not announced||not announced||not announced|
|NVDA||not announced||not announced||not announced|
|Narrator||not announced||not announced||
|VoiceOver Mac||not announced||not announced||
|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
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”
role="presentation"in place of
role="none", any difference?
role="none"is a synonym of
role="presentation"since ARIA 1.1. Look here: https://www.w3.org/TR/wai-aria/#note-regarding-the-aria-1-1-none-role
Yeah, I think Birkir is aware, i hazard that he was thinking that there may be more robust support across implementations for
role=presentationas it has been around a lot longer.
[…] Hush Sweet IFrame […]