iframe has no accessible title

What is this issue?

An <iframe> element (used to embed another document inside the current page, such as a video player, a map widget, or a third-party form) has no title attribute, and no other naming mechanism (aria-label or aria-labelledby) resolves to non-empty text either. The frame has a role (screen readers identify it as a “frame” or “iframe”) but no name describing what it contains.

This differs from the frame’s own internal content having a heading or title: that content is only announced once a user has already entered the frame. This rule is about the name announced before that decision point, from outside the frame.

Why does this matter?

Screen reader users encounter an <iframe> as a distinct, separate embedded document within the page, conceptually similar to a link that leads somewhere else, except the destination renders inline. When a screen reader announces an unnamed frame, it says only “frame” or “iframe,” with nothing about what’s inside: a video, a map, a chat widget, a payment form, an ad.

Without that context, the user has to decide whether to enter the frame with no information to base that decision on. Entering an iframe changes how many screen readers navigate (some switch into a distinct browsing mode for the frame’s content), so a user who enters one expecting a video and finds a lengthy legal document, or vice versa, has wasted a navigation step figuring out what they walked into.

Who is affected?

• Screen reader users: hear only the generic role “frame” with no description of its content, forcing them to enter every unnamed iframe just to find out what it contains, or skip past content they might have actually wanted.

What users experience

Grace uses JAWS on Windows to compare mortgage rates across a financial comparison site. Each listing embeds a rate-calculator widget in an <iframe> with no title attribute. As she tabs through the page, JAWS announces “frame” before each one, with no indication of which lender’s calculator it is or what it does. She has to enter each frame individually and listen to its internal content just to identify which widget belongs to which lender, a step a sighted user skips entirely by glancing at the widget’s visible branding.

How do I fix it?

Add a descriptive title attribute to every <iframe>, stating what the embedded content is or does from the user’s perspective. This works because title is the primary naming mechanism assistive technology checks for an iframe, giving the screen reader something concrete to announce the moment it reaches the frame, before the user decides whether to enter it.

Write the title around the frame’s purpose, not its technical source: “Mortgage rate calculator” rather than “widget.html,” and “Product demo video” rather than the embed provider’s generic name. If a frame is purely decorative and carries no content a user needs (a hidden tracking pixel, for example), hide it from the accessibility tree entirely with aria-hidden="true" and tabindex="-1" instead of inventing a meaningless title just to pass an automated check.

Code Examples

<iframe src="https://www.youtube.com/embed/abc123"></iframe>
<iframe src="/widget/map.html"></iframe>

<!-- Descriptive title stating the content's purpose -->
<iframe
  src="https://www.youtube.com/embed/abc123"
  title="RedFlag product demo video"
></iframe>

<iframe
  src="/widget/map.html"
  title="Interactive map showing our Sydney office location"
></iframe>

<!-- Purely decorative iframe: hide it instead of naming it -->
<iframe
  src="/tracker.html"
  aria-hidden="true"
  tabindex="-1"
></iframe>

Each descriptive title tells a screen reader user what they’re about to enter before they commit to navigating into it (a video versus a map, in this case) instead of leaving them to explore blind. The decorative example is hidden entirely rather than given a name, since it has no content a user of any kind needs to encounter.

Common Mistakes

Mistake: “The iframe’s src URL is descriptive enough on its own.” Screen readers don’t announce the src attribute’s value to users; it’s not part of the accessible name calculation for a frame at all. A URL that looks self-explanatory to a developer reading the source code is completely invisible to someone using a screen reader.

Mistake: “This only matters for iframes with a lot of content, not small embedded widgets.” Frame size has no bearing on this rule: even a small, single-purpose widget (a chat bubble, a single embedded tweet) still announces as a bare “frame” with no title, and a small unlabeled frame is just as disorienting to encounter as a large one.

Mistake: “Adding title=“iframe” satisfies the check, since it’s not empty.“ A generic, non-descriptive title like "iframe" or "embed" technically passes an automated presence check but provides zero more information than no title at all: it fails the actual intent of the rule even while passing the letter of it. A human reviewer, not just an automated scan, needs to confirm the title genuinely describes the content.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s frame-title rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule checks every <iframe> and <frame> element and flags a violation when it resolves no non-empty accessible name from title, aria-label, or aria-labelledby.

False negative: axe-core confirms a name exists; it cannot judge whether that name is accurate or genuinely descriptive: title="frame" or title="embed" passes the automated check even though it tells a user nothing useful about the frame’s content. False positive: none typical for this check, since resolving to a non-empty accessible name is a binary condition axe-core evaluates reliably. Manual step: read the announced title for every iframe against what it actually embeds, and confirm it’s specific enough that a user could decide whether to enter the frame based on the title alone.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Navigate through the page using the screen reader’s landmark or object navigation shortcut (NVDA: Insert+F7 for the Elements List, filtered to Frames; VoiceOver: the Rotor).
3. Listen to what’s announced for each iframe; it should be a specific description of the frame’s content or purpose, not just “frame” or “iframe” alone.
4. If a title is present, confirm it genuinely describes what’s inside rather than being a generic filler word.
5. If any frame announces with no name, or a name that doesn’t tell you what the frame contains, the check fails.

Related WCAG Success Criteria

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and current value to assistive technology. An iframe with no title has a role (announced as “frame”) but no name, so it fails 4.1.2 specifically on the naming requirement.

Related Issues

Frame title is not unique is the next-step failure for a page with several iframes: each has a title, but two or more share the identical value, making them indistinguishable from each other even though none is technically unnamed.

Frame with focusable content has no accessible name covers the keyboard-specific version of this same underlying problem: an untitled frame that also contains focusable elements, so a keyboard user tabs silently into unannounced content.

Button or link has no accessible name and Link must have discernible text share the identical “role announced, but no name” failure mode this rule documents, applied to interactive controls instead of embedded frames.

References

• W3C Understanding 4.1.2: Name, Role, Value
• W3C Technique H64: Using the title attribute of the frame and iframe elements
• MDN: iframe title