NOTE: Support for iframes in screen readers can be flakey if there is complicated programmed content in them. Generally, iframes 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? It's a big question because there are millions of embedded Youtube videos on the websites that don't have the title attribute. This is just one example.

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

IE and Firefox provide a tab stop for an iframe, Chrome and Safari, do not. So is it a component that should provide the Name, Role and Value?

What do other a11y professionals say?

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

@davidmacd @dylanbarrell It should. For frames at least however JAWS announces title element of embedded page instead of title attribute.

— Sam J (@mixolydian) January 8, 2015

@pauljadam @davidmacd SC 4.1.2 simply because it is listed as one of sufficient techniques for SC 4.1.2.

— Makoto Ueki (@mak_en) January 8, 2015

@davidmacd I think only a failure if the iframe itself conveys something distinct - an ad block or video player, for example.

— Jared Smith (@jared_w_smith) January 8, 2015

@davidmacd Usually, but not always. They’re sometimes used to inject content and there may be no visual or content distinction to them.

— Jared Smith (@jared_w_smith) January 8, 2015

@davidmacd Yes, probably. But I think a blanket <iframe> w/o title = failure is probably too broad.

— Jared Smith (@jared_w_smith) January 8, 2015

@davidmacd @dylanbarrell Basic case I'm making here is DoubleClick iframes always crash my JAWS speech because JAWS announces the source.

— Sam J (@mixolydian) January 9, 2015

@davidmacd In absence of title JAWS announces src value of iframe. For injected ads this is often a very long string that crashes speech.

— Sam J (@mixolydian) January 9, 2015

@davidmacd I consider missing iframe titles a failure under 4.1.2 unless it is non user facing and properly hidden from AT and all users

— Jon Avila (@JonAvilaSSB) January 9, 2015

What do Screen Readers do when they encounter an iframe?

The behavior documented below is for iframes with simple content. Experience has taught me that all bets are off when the iframe is populated with a complex programmed application.

iframes in JAWS

• Announces role of iframe and title element of the source URL document on tab focus or arrowing into it
• If the user tabs directly into the iframe content without stopping on the iframe (or jumps to a heading in the iframe) then there is no announcement of the iframe or it's title
• Allows the user to ignore the iframe and its content completely. Go to Utilities>settings center>Web/HTML/PDF>Headings and Frames >Ignore inline frame

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

See table below for full test results.

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 on line 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."

What does the HTML spec say

The iframe section of the HTML5 spec says:

When an iframe element is inserted into a document, the user agent must create a nested browsing context

This it is a distinct node in the DOM. It is described in the HTML5 spec as a parent/child relationship with the main page. I think this indicates it is not seemless continuation of the surrounding context.

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 accessibility issue, and there appears to be room for interpretation, so I doubt anyone will fall on their sword on how you as an accessibility pro call it, (except maybe those who put Youtube videos on their site) but I propose the following:

A missing title on an iframe is almost always a failure of WCAG 4.1.2 unless it is presenting content that is not distinct from its surrounding context and has no tab stops inside it.

 

A title is not required if content in iframe is not distinct from surrounding content and has *no* tab stops inside it, and the author adds tabindex="-1" on iframe so it doesn't receive tab focus.

Screen reader text of iframe here

Rationale:

• WCAG says the title "should be" present Technique H64
• The posts in the archives are in favor 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.)
• Most automated testing tools fail the missing title
• The two most popular browsers for screen reader users (IE and Firefox) provide a tab stop for the iframe (tests below). I suggest under 4.1.2 everything that receives focus should provide an accName (Title) to the accessibility API.
• If there are has tab stops in the iframe, then *do not* add tabindex=-1, because some browser and assisitive technology combinations will skip entry to the tabs inside the iframe unless the user arrows into the frame and then tabs.
• However, in the unlikely situation where there are no tab stops inside the iframe, and the author removes the iframe from the tab order (tabindex="-1") AND the content is indistinct from its surrounding context, then we should assume the author is not using it as an interface component and therefore it does not need an AccName (Title Tribute).

Feel free to comment on Twitter @davidmacd

Author information:

David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.

Appendix:Test results on an iframe with popular screen readers

An example iframe

test link following the frame

Accessibility Support technology used

	JAWS 16 (Setting can allow iframe to be ignored completely)	NVDA 2014.4 (Setting can allow no announcement of iframe ROLE)	VoiceOver (No setting for iframe)
FireFox34.0.5 (Tab stop on iframe)	On tab focus: Announces "iframe content Frame" When virtual cursor encouters frame, the title is announce followed by "iframe content document". End of frame is announced Jumping directly to content inside the frame (i.e., heading navigation, tabbing into it etc) without focusing on iframe: there is no announcement of the iframe or it's title. It is as if the content is part of the page. No announcement when tabbing out of iframe to another control (the "announce start and end of frame" settings does nothing, it is not for iframes.)	On tab focus the screen reader does nothing Arrowing into iframe ROLE is announced "iframe" Jumping directly to content inside the frame (i.e., heading navigation) without focusing on iframe: Title of iframe is announced followed by ROLE "iframe" Turning off iframe setting stops all announcements and treats iframe content as if its on the page.	N/A
IE11.0.9 (Tab stop on iframe)	On tab focus: JAWS announces "iframe content Frame" Virtual cursor encouters frame, JAWS speaks "iframe content Frame" and title of the embedded page, NOT the title attribute. Jumping directly to content inside the frame (i.e., heading navigation) without focusing on iframe: there is no announcement of the iframe or it's title. It is as if the content is part of the page. No announcement when leaving iframe (the "announce start and end of frame" settings does nothing, it is not for iframes.)	On tab focus: JAWS announces full URL address then says iframe followed by "say all" of iframe contents. Title is never read regardless of setting Jumping directly to content inside the frame (i.e., heading navigation) without focusing on iframe: it announces URL address then says iframe followed by whatever has focus or virtual cursor Leaving the iframe is announced Turning off iframe setting stops all announcements and treats iframe content as if its on the page.	N/A
Chrome 39.0.2171.95 m (No tab stop on iframe)	Arrow to frame: iframe is announced "iframe" title attribute is read Arrowing into iframe: title element of the source url document in the iframe is read. Jumping directly to content inside the frame (i.e., heading navigation) without focusing on iframe: Title IS NOT read nor the ROLE "iframe". Announcement upon leaving iframe	Arrow to frame: iframe is announced "iframe" title attribute is read Arrowing into iframe: title element of the document in the iframe is not read but ROLE of iframe is announced. Jumping directly to content inside the frame (i.e., heading navigation) without focusing on iframe: Title IS announced followed by ROLE "iframe" followed by focues content. Announcement upon leaving iframe	N/A
Safari MacOS (No tab stop on iframe)	N/A	N/A	Upon entering the ROLE iframe and its ACCNAME title IS announced. VO will stop on the iframe when navigating by container