back to CanAdapt home

The iframe delemna: Is it a failure of WCAG to not have a title on an iframe?

Description

iframe support in screen readers is a little flakey if there is complicated content in them and generally they should be avoided for voluminous, or complicated applications.

However, what about simple content? They work well with screen readers. Then the question arises, should they have a title attribute?

4.1.2 of WCAG says that every user Interface Component must provide a Name, Role and Value. The Title attribute is presented to the accessibility api as the ACCNAME. The announcement of the iFrame is annouced as the Role.

But is an iframe a user interface component under WCAG? Here's the WCAG definition.

user interface component

 

a part of the content that is perceived by users as a single control for a distinct function

Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.

Note 2: User interface components include form elements and links as well as components generated by scripts.

There is a variety of opinions among respected accessibility professionals.

@davidmacd it should not be! Reason: iframes mostly cannot be seen and their use is technical. Exposing them to AT is an outdated mistake

— holistica11y (@dylanbarrell) January 7, 2015

@davidmacd bypass blocks

— Paul J Adam (@pauljadam) January 8, 2015

@davidmacd yes, should be ignored

— holistica11y (@dylanbarrell) January 8, 2015

@davidmacd more to the 4.1.2 no tile = no name

— goetsu (@goetsu) January 7, 2015

What do Screen Readers do when they encounter an iFrame?

The behaviour documented below is for iframes with simple content. Experience is taught me that all bets are off on the iframe's behaviour with screen readers when it is populated with a complex programmed application.

iFrames using NVDA

• By default NVDA announces the source URL (which I fine annoying) of the iframe, and the Role="iFrame"
• This can be turned off:
• Preferences>Document Formatting>Report iFrames
• This will cause it to treat the iframe content like any other content on the page.
• NVDA does not announce the title of the iFrame in any browser that we tested, and provides no setting to turn on the title.

iFrames JAWS

• Announces role of iFrame and it's title on tab focus, but if the user moves directly into the iframe content without stopping on the iframe (e.g., jumping to a heading in the iframe) then there is no annoucement of the iframe or it's title
• Allows the user to ignore the iFrame completely. Go tp Utilities>settings center>Web/HTML/PDF>Headings and Frames >Ignore iline frame

iFrames using Voice Over on Safari

VoiceOver has no controls for iFrame in settings. When user enters the iframe the (Role) is spoken and Title attribute is spoken before content is spoken. When user leaves frame they are notified.

What does WCAG say?

I don't remember any conclusive discussion in meetings during my 12 years on the WCAG on committee. In the old days it was mostly all about the Frame element which was deprecated in HTML5. However, there are some hints. Here are a few brief online exchanges:

http://lists.w3.org/Archives/Public/w3c-wai-gl/2014JulSep/0183.html

and then prior to that we are in 2004 with a recommendation that we require a title by a committee member who is a screen reader user.

http://lists.w3.org/Archives/Public/w3c-wai-gl/2004OctDec/0109.html

There is no explicit "Common Failure" in WCAG but Technique H64 says:

"[The Title attribute on iframes and the Title element] should be provided, since the first facilitates navigation among frames and the second clarifies the user's current location."

Conclusion

This is one of the most ambiguous issues I've come across in determining WCAG failure or not. IE and FF browsers provide a tab stop on the iFrame, Chrome and Safari browsers don't. Screen readers are all over the map on their support of the Title attribute on iframes. WCAG discussion is limited both in the specification and in the mail archives.

It's not a critical issue, so I doubt anyone will fall on their sword on how you as an accessibility pro call it, (except maybe Youtube who have millions of untitled iframes all over the web) but I propose it is a failure of WCAG to leave out a title on an iframe because

• WCAG hints at this in Technique H64

• The few posts in the archives are in favour of the title
• Screen reader users I've discussed this with have said they prefer to have the choice to turn them on or off.
• Most a11y professionals I've discussed this with map it to a failure of 4.1.2 Name, Role, Value or 2.4.1 Bypass Blocks (although some think its an artifact issue from the days of html frames.)

However, if the author removes the iframe from the tab order (tabindex="-1") then we should assume they are not using it as an interface componenent and therefore it does not need an AccName (Title Tribute).

I'm interested in your opinion. tweet me at @davidmacd

Appendix

An example iframe

Accessibility Support technology used