Frame with focusable content has no accessible name

What is this issue?

An <iframe> element contains one or more focusable elements inside its embedded document (an input field, a link, a button, anything that receives keyboard focus when a user presses Tab) but the frame itself has no title attribute and no aria-label or aria-labelledby resolving to non-empty text. There’s a role (the frame) and interactive content inside it, but no name announced before a keyboard user’s focus crosses into that content.

This is closely related to, but narrower than, iframe has no accessible title: every frame flagged by this rule is also missing a title, but this rule specifically flags the cases where that missing title has a direct keyboard-operation consequence, because there’s genuinely interactive content inside for a keyboard user to tab into.

Why does this matter?

When a sighted keyboard user presses Tab and their focus moves into an iframe, nothing on screen necessarily signals the transition: a focus outline just appears somewhere new, possibly inside embedded content styled to look like it belongs to the surrounding page. For a screen reader user, the situation is worse: focus moves silently into the frame’s interactive content with no announcement of what that content is, before they start interacting with unfamiliar controls.

The consequence compounds with every additional focusable element inside the frame. A user who doesn’t know they’ve entered a booking widget, a payment form, or a third-party chat tool has to explore blind: tabbing through unfamiliar fields and buttons one at a time, trying to infer the frame’s purpose from its contents, when a single announced title before the frame would have told them immediately.

Who is affected?

• Screen reader users: get no announcement of what embedded content they’re entering as focus crosses into the frame, and have to explore its interactive elements one at a time to understand its purpose.
• Keyboard users: tab into unidentified interactive content with no orientation cue, making it harder to predict what a given Tab press is about to do once focus is inside unfamiliar embedded controls.

What users experience

Diego uses NVDA on Windows to book an appointment through a healthcare provider’s website, which embeds a third-party scheduling widget in an untitled <iframe> containing a date picker, a time-slot list, and a submit button. As he tabs through the page, focus moves into the frame with no announcement; NVDA gives no indication he’s left the main page’s content. He starts interacting with what he assumes is still the main page’s form, only realizing partway through that he’s inside a separate embedded scheduling tool once the field labels stop making sense in context, forcing him to restart the booking process from the beginning.

How do I fix it?

Give every iframe containing focusable content a descriptive title attribute, stating what that embedded content is or lets the user do. This works the same way it does for any untitled frame: the title is announced before focus enters the frame’s content, giving the user context before they start interacting with unfamiliar controls instead of after.

Prioritize this fix on any iframe containing form fields, buttons, or links over a purely static, non-interactive embed: the keyboard-operation consequence this rule targets only exists where there’s something inside the frame for a user to actually tab into and interact with.

Code Examples

<iframe src="/booking-widget"></iframe>

<iframe src="/booking-widget" title="Appointment booking form"></iframe>

With the title in place, a screen reader announces “Appointment booking form” the moment focus reaches the frame, before the user starts tabbing through its date picker and time-slot controls; they now know what they’re about to interact with instead of discovering it after the fact.

Common Mistakes

Mistake: “We already fixed our other iframes for frame-title, so this rule shouldn’t find anything new.” This rule specifically targets frames with focusable content inside them, which is a subset of all untitled frames; it’s entirely possible for a scan to flag new instances here that a broader frame-title review missed, particularly interactive third-party embeds added after the last audit.

Mistake: “The interactive elements inside the frame have their own labels, so the frame itself doesn’t also need one.” Labels on the individual fields inside the frame only help once a user has already entered it and started exploring. The frame’s own title is what orients the user before that point: the two serve different moments and neither substitutes for the other.

Mistake: “This is really the same issue as frame-title, so fixing one fixes both automatically.” Adding a title does resolve both findings for a given frame, since they share the same fix, but they’re tracked as separate rules because they represent different consequences (naming in general versus a specific keyboard-operation harm) mapped to different WCAG criteria, 4.1.2 and 2.1.1 respectively.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s frame-focusable-content rule as part of every scan. This rule is one of six rules RedFlag explicitly force-enables beyond their default tag membership in the scan configuration, alongside target-size, identical-links-same-purpose, css-orientation-lock, meta-refresh-no-exceptions, and focus-order-semantics, included because it maps to WCAG criteria RedFlag’s scan targets even though axe-core doesn’t tag it into the default rule set. The rule inspects each <iframe>’s content for focusable descendant elements and flags a violation when a frame with at least one is missing a non-empty accessible name.

False negative: axe-core confirms a name exists once one is added; it cannot judge whether that name is accurate for the specific interactive content inside: a vague title like “Form” passes the automated check even if the frame contains a multi-step payment flow. False positive: none typical for this check, since detecting focusable descendant elements combined with a missing accessible name is a binary condition. Manual step: confirm the title describes the frame’s interactive purpose specifically enough that a keyboard user knows what to expect before tabbing in.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running, using only the keyboard.
2. Tab through the page and note every point where focus moves into an iframe’s content.
3. Listen for an announcement immediately before focus enters the frame; it should name the frame’s purpose, not silently move into unfamiliar controls.
4. Continue tabbing through the frame’s interactive elements and confirm each is itself properly labelled once inside.
5. If focus enters a frame with interactive content and nothing is announced beforehand, the check fails.

Related WCAG Success Criteria

2.1.1 Keyboard: All functionality must be operable through a keyboard interface. An untitled frame with focusable content doesn’t block keyboard operation outright, but a user can’t reliably predict or understand what a given Tab press does when focus silently crosses into unannounced embedded controls, which undermines this criterion’s intent even though the controls themselves remain technically reachable.

Related Issues

iframe has no accessible title is the broader version of this rule’s underlying defect: any untitled frame, whether or not it contains focusable content.

Frame title is not unique covers a frame that does have a title, but one that’s indistinguishable from another frame’s title on the same page.

Element in the focus order has no matching interactive role shares this rule’s underlying concern (focus landing somewhere a user can’t make sense of), applied to elements directly on the page rather than inside an embedded frame.

Scrollable region must be keyboard accessible is another case of focusable or interactive content needing explicit accessible handling so a keyboard user can operate it predictably, just for a scrollable region instead of an iframe.

References

• W3C Understanding 2.1.1: Keyboard
• W3C Technique H64: Using the title attribute of the frame and iframe elements
• MDN: iframe title