iframe-focusable-content

Frames with tabindex="-1" must not contain focusable content

automaticWCAG 2.1.1 (A)confidence: highseverity: moderateoperable

Checks that same-origin <iframe>/<frame> elements with tabindex="-1" do not contain focusable content, which keyboard users cannot reach: the negative tabindex takes the frame’s whole content out of the tab order.

Applies to. Applies to <iframe>/<frame> elements with an explicit negative tabindex, whose embedded document is same-origin and reachable via contentDocument. A cross-origin or otherwise unreachable frame can't be looked into, so nothing is asserted about it.

Expectation. The frame's embedded document contains no element in its sequential focus navigation order. A negative tabindex on the <iframe> takes its whole browsing context out of the tab order: Tab skips everything inside, so a link or control there cannot be reached by keyboard (ACT akn7bn; in Chromium, Tab goes from the element before the frame to the one after it). An element is in the order by HTML's rules, read in the frame's own document: not when disabled (:disabled, which counts a disabled <fieldset> but not its first <legend>) or inert; a tabindex that parses as an integer decides, and an invalid one ("", "abc") is ignored; otherwise links with href, form controls but hidden inputs, frames, media with controls, an <area> of an image map a rendered <img> uses (usemap matched exactly), the first <summary> of a <details> and editing hosts (contenteditable "", "true" or "plaintext-only") are. Exception: an iframe with both a width and height HTML attribute of 2px or less (a common "tracking pixel" pattern) cannot render any perceptible content, so focusable content inside it never satisfies ACT akn7bn's "visible" requirement and doesn't count.

Examples

pass
<iframe tabindex="-1" width="300" height="150" srcdoc="<p>No focusable content</p>"></iframe>

tabindex="-1" removes the frame from the tab order, and nothing inside it is focusable either.

fail
<iframe tabindex="-1" width="300" height="150" srcdoc="<a href='/x'>Link inside</a>"></iframe>

The host frame is skipped by tabindex="-1", but the link inside it is still reachable by Tab — the browser does not propagate the negative tabindex into the embedded document.

How to check

When this rule can’t decide, it reports cantTell and leaves the question to a person. Each question it can ask is listed here under its reason code, with the steps to answer it. A finding carries the same steps as howToCheck, in the scan’s language. See Output schema.

IFRAME_TABINDEX_NEGATIVE_CONTENT_RUNTIME_REDIRECT

  1. Click on the page just before the frame the report names, then press Tab to move toward it.
  2. Keep pressing Tab and watch whether focus ever lands inside the frame, and where it goes when it would arrive there.
  3. Inspect the focusable element inside the frame in the Elements panel: note whether it is an empty focus guard or a real link or control with content.
  4. If it is a real link or control, try every other keyboard route to it (Shift+Tab, the frame's own controls) to see if it can be reached and used.

Pass. The only focusable element inside the frame is an empty focus guard that sends focus on, and nothing a user needs inside the frame is left out of keyboard reach.

Fail. A real link or control inside the frame cannot be reached or used with the keyboard because focus skips or bounces away from it, which fails WCAG 2.1.1.

View source