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

> Canonical HTML version: https://rocketvalidator.com/accessibility-validation/accesslint/0.16/labels-and-names/frame-focusable-content
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

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.

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

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

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

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

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