Frames with Focusable Content Must Not Have tabindex=”-1″

By default, browsers move keyboard focus to the <iframe> element first. Once focus enters the frame, users can then navigate to focusable elements inside it, such as buttons, links, or form fields.

If an <iframe> is given tabindex="-1", it is removed from the keyboard tab order. When that happens, the browser never enters the frame at all, and none of the focusable content inside can be reached through normal keyboard navigation.

WCAG Success Criteria Affected

Using tabindex="-1" on a frame that contains focusable content commonly results in failures of:

• SC 2.1.1 Keyboard (Level A)
  Users cannot reach interactive content using the keyboard.
• SC 2.4.3 Focus Order (Level A)
  Focus order is interrupted because entire sections of content are skipped.

In assistive technologies such as screen readers, the frame may be announced, but keyboard focus will never enter it, leaving users aware of content they cannot access.

Why This Matters

Keyboard users rely on predictable focus movement to explore and operate a page. When a frame has a negative tabindex:

• Keyboard focus cannot enter the frame
• All interactive elements inside are skipped
• Scrollable frame content may be unreachable by keyboard
• Users may know content exists, but cannot access it

This affects users who:

• Navigate using only a keyboard
• Use screen readers with keyboard navigation
• Depend on the focus order to understand the page structure

If focus cannot enter a frame, its contents are effectively inaccessible.

What Counts as Focusable Content

A frame is considered to contain focusable content if it includes any elements that can receive keyboard focus, such as:

• Buttons and links
• Form inputs
• Custom components with keyboard interaction
• Scrollable regions that require focus for keyboard scrolling
• Nested frames that themselves contain focusable elements

If any of these are present, the frame must not have tabindex="-1".

Correct Usage

Frames that contain only static, non-interactive content may use tabindex="-1" safely, because there is nothing for keyboard users to interact with.

<iframe
  srcdoc="<p>Hello world</p>"
  tabindex="-1"
  title="Static content frame"
></iframe>

Frames that contain focusable or interactive content must either omit tabindex or use a non-negative value (typically 0).

<iframe
  srcdoc="<button>Click me</button>"
  tabindex="0"
  title="Interactive content frame"
></iframe>

In this case, focus can enter the iframe and move to the button inside.

Incorrect Usage

The following pattern fails because the frame contains focusable content but is removed from the keyboard navigation order:

<iframe
  srcdoc="<button>Click me</button>"
  tabindex="-1"
  title="Interactive content frame"
></iframe>

Although the button itself is focusable, keyboard users can never reach it, because focus never enters the frame.

Important Clarifications

Sequential focus vs programmatic focus

tabindex="-1" still allows an element to receive focus programmatically (for example, via element.focus() in JavaScript). However, this does not satisfy WCAG requirements.

WCAG requires that users be able to reach content through normal keyboard navigation, not only through scripted focus changes. Screen reader and keyboard users cannot rely on JavaScript-driven focus to discover content.

<frame> vs <iframe>

The <frame> element is obsolete and rarely used in modern web content. However, this rule still applies to it for completeness. In practice, <iframe>is the primary element of concern.

Rule Description

<frame> and <iframe> elements that contain focusable content must not have tabindex="-1". Keyboard focus must be able to enter the frame so users can access and interact with its contents.

The Algorithm (In Simple Terms)

1. Identify all <iframe> (and legacy <frame>) elements
2. Check whether any have tabindex="-1"
3. For each such frame, inspect its contents:
   • Does it contain focusable elements?
   • Does it contain nested frames with focusable elements?
4. If yes, the rule fails
5. If the content is entirely static and non-interactive, the frame may pass

Common Failures

• Embedding interactive widgets inside iframes with tabindex="-1"
• Adding negative tabindex “defensively” without reviewing frame content
• Updating iframe content without revisiting focus behaviour
• Third-party embeds are introducing focusable elements unexpectedly

A common misconception is:

“The content inside the frame is accessible, so the frame itself doesn’t matter.”

This is false. If focus cannot enter the frame, the content inside cannot be reached.

How to Test This

1. Navigate the page using the Tab key only
2. Confirm that focus lands on the iframe
3. Confirm that focus can move to interactive elements inside the frame
4. Repeat the test with a screen reader running
5. If focus skips the frame entirely, investigate tabindex usage

Best Practice

Avoid applying tabindex to iframes unless you fully control and audit their contents. Negative tabindex on frames is fragile. Content changes over time, and a harmless frame today can become an accessibility failure tomorrow.

Wrapping Up

Frames are part of the keyboard navigation path. If they contain interactive content, they must allow focus to enter. Removing frames from the tab order can silently block access to entire sections of a page. When in doubt, do not use tabindex="-1"on frames, especially when their contents may change. Accessible focus flow depends on predictability, not assumptions.