Iframes with interactive content must not be excluded from the tab order.

When an <iframe> element has tabindex="-1", it is removed from the page's sequential focus navigation order (the tab order). This means that any interactive content inside the iframe, such as links, buttons, or form fields, may become unreachable by keyboard. The behavior is inconsistent across browsers: some allow arrow keys to reach elements inside the iframe, while others make them completely inaccessible. Either way, the result is a broken keyboard experience.

Keyboard-only users, including people who rely on switch devices or other assistive technologies that simulate keyboard input, cannot interact with content trapped inside a negatively tab-indexed iframe. Screen reader users are also affected, since many screen readers follow the browser's focus order when navigating interactive elements.

Why this matters

WCAG Success Criterion 2.1.1 (Keyboard), a Level A requirement, states that all functionality must be operable through a keyboard interface. Every page has a global tab order built by combining the focus orders of the main document and any embedded documents (iframes). When an iframe has a negative tabindex, its internal focus order is excluded from the page's global tab order. A button or link may exist inside the iframe and be focusable within that document, but users can never reach it because the iframe itself acts as a wall blocking keyboard navigation.

How to fix it

There are three approaches depending on the purpose of the iframe:

If the iframe content is interactive and functional, remove tabindex="-1" from the <iframe> element. Without a negative tabindex, the iframe's internal focus order is included in the page's global tab order, and users can tab into the frame and reach its interactive elements normally. You can also set tabindex="0" explicitly, though omitting the attribute entirely has the same effect.

If the interactive elements inside the iframe should genuinely be non-focusable, add tabindex="-1" to each focusable element inside the iframe's document instead. This removes the elements themselves from the focus order rather than cutting off the entire iframe.

If the iframe is purely decorative and has no meaningful content, add aria-hidden="true" to the <iframe> element. This hides the frame from assistive technologies entirely. Only use this when the iframe content does not need to be perceived or interacted with by any user.

Examples

Incorrect: iframe with interactive content excluded from tab order

This iframe contains a link, but tabindex="-1" on the iframe prevents keyboard users from reaching it.

<iframe tabindex="-1" srcdoc="<a href='/'>Home</a>"></iframe>

Correct: iframe without a negative tabindex

Removing the tabindex attribute allows the iframe's content to participate in the page's tab order.

<iframe srcdoc="<a href='/'>Home</a>"></iframe>

Correct: iframe with tabindex="0"

Setting tabindex="0" explicitly also keeps the iframe in the normal tab order.

<iframe tabindex="0" srcdoc="<a href='/'>Home</a>"></iframe>

Correct: iframe with no interactive content

When the iframe contains no focusable elements, a negative tabindex does not cause any keyboard accessibility problem.

<iframe tabindex="-1" srcdoc="<h1>Hello world</h1>"></iframe>

Correct: decorative iframe hidden from assistive technology

If the iframe is decorative, use aria-hidden="true" instead of relying on a negative tabindex to suppress it.

<iframe aria-hidden="true" srcdoc="<canvas></canvas>"></iframe>

Learn more:

W3C Reference

Understanding Success Criterion 2.1.1: Keyboard

→

MDN Reference

Using the iframe element

→

W3C Reference

Understanding Success Criterion 2.4.1: Bypass Blocks

→