Inline Frame (iframe) Accessibility

Nearly every accessibility project we take involves some amount of content loaded onto the page in an iframe, from YouTube videos to 3rd party widget, so this has become a significant topic to address as the use of iframes on an accessible website seems to be somewhat misunderstood.

There are two common misconceptions that are nearly perfect opposites:

It’s impossible to make iframes accessible
As the page author I’m not responsible for the accessibility of content or features I pull into my site from a 3rd party using iframes

You may have guessed already, but both of these statements are false. The truth, however, is a bit more complex because as with everything involving accessibility it depends on the specific content and context.

Guidelines

There are some overarching rules of iframes we can use to break this down, however:

All content and functionality contained within the iframe must meet all WCAG criteria for the page containing the iframe to be conformant.^†
The content and functionality contained within the iframe is added to the accessibility tree of the parent document and together they are treated as a single document.
It is possible for a user to choose to open the iframe contents in a new tab/window (either via mechanism provided by the User Agent, use of a browser plugin, or use of an assistive technology).

The second point above is particularly interesting because it means it would be possible for the iframe content to conform to WCAG and the containing page (without the iframe) to conform, but for them to fail together. For example, if the iframe content is intended to be within a section with a Heading level 2 (<h2>) but the included content has its own Heading level 1 (<h1>) this would cause a violation of WCAG 1.3.1.

Before we continue, let’s take a look at the primary WCAG criteria that apply to the use of iframes:

1.3.1 Info and Relationships (Level A) - Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text
- Regions, headings, and other structure within the iframe should still make sense in the context of the containing page
1.4.4 Resize Text (Level AA) - Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality
- The iframe should resize responsively along with the containing page
1.4.10 Reflow (Level AA) - Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions
- The iframe should avoid scrolling separately from the page
2.4.1 Bypass Blocks (Level A) - A mechanism is available to bypass blocks of content that are repeated on multiple Web pages
- If the iframe represents a distinct section of content an appropriate accessible name should be provided (via the title attribute)
4.1.2 Name, Role, Value (Level A) - For all user interface components the name and role can be programmatically determined
- Any iframe which is visible on the page it should have an appropriate accessible name (via the title attribute) and a description as to its purpose

Based on these criteria we can deduce some general guidelines to follow:

If iframes aren’t absolutely necessary for content management, avoid using them! Instead, use CSS to accomplish the same visual presentation
The contents of an iframe should be tested separately, as well as in the context of the page
Avoid any <meta name="viewport"> settings within the iframe document that would prevent scaling of the window, such as user-scalable=0 or maximum-scale=2.
- Other viewport settings such as width=device-width, initial-scale=1 are acceptable as they enable user-specified scaling of the page.
If the contents of the iframe aren't responsive due to 3rd party limitations it may be necessary to either allow scrolling scrolling=auto or to ensure the frame can grow as necessary and handle scrolling in the host document
Avoid double-scrolling scenarios where the contents of the iframe and the host page have their own independent scrollbars
Avoid dynamically changing the primary content of an iframe, such as by updating the src or using JavaScript to rewrite the page contents
- If you must display an entirely new page, replace the iframe entirely with a new one inside of an ARIA live region
Make sure you can navigate through iframes by using a keyboard alone.

Specific Use Cases

The above guidelines are great, but there may be some specific use cases that aren’t really covered. Let’s look at these here. If you have other use cases in mind, please send us a message so we can work together to document it here.

Mechanism for content reuse

The idea here is that the iframe is inserting content that is intended to be inlined^‡ and neither the iframe nor the included content have any special section or region that would set it apart from the rest of the page.

In this case it would be possible to use role=”presentation” to indicate that the iframe has no semantic intent and in this case the title attribute would be omitted. Note that the presentation role is not inherited by the contents of the iframe so it wouldn’t cause a cascading failure. It is important to use this approach only if it would not be necessary for the user to navigate directly to the iframe bypassing earlier content.

Embedding Multimedia Content

It’s important to include a title attribute to indicate the nature of this content and possibly also a more detailed description using aria-describedby to make it clear what the user should expect. Take extra care to test by using a keyboard and look for keyboard traps (you can tab into the iframe but not back out). Test using a screen reader. You’ll probably need to set an allow for features such as Full Screen for video content, but pay very close attention to security controls on 3rd party content.

Security

Another serious concern relating to iframes that we need to address is to use appropriate security controls. This is particularly relevant when using iframes to pull in 3rd party content (a common use case).

While it may not be immediately obvious, security is absolutely an accessibility concern. Referring to the core principles that our software be Perceivable, Operable, Understandable, and Robust we find that a website security incident may violate each of these principles. For example, users may find it hard to understand how to identify and respond appropriately to security threats and incidents they would encounter. Users of assistive technologies may find it hard to perceive that the incident is even occurring, if the relevant details are faked or omitted by an attacker.

Some general security principles to keep in mind regarding iframes include:

Use the sandbox attribute
- Never combine “allow-scripts” with “allow-same-origin”
- Only provide exceptions when absolutely necessary
Use the referrerpolicy attribute (we suggest “same-origin” as a default)
Use the allow attribute if necessary to provide specific permissions to device capabilities (such as Full Screen), but avoid providing unnecessary permissions
Use clean user-understandable URLs in the src and never include credentials or private information, including security tokens
All embedded pages should set an appropriate X-Frame-Options header All pages should provide a Content Security Policy (CSP)

Summary

Following all of these guidelines doesn’t guarantee an accessible iframe implementation, but it’s a good starting point and hopefully we’ve included enough resources here to help you get where you need to go. If you need help with your implementation, we’re available to hire for accessibility consulting.