Skip to main content
Accessibility AccessLint 0.16

Frames must have an accessible name.

About this AccessLint rule

Every <iframe> element that is visible to assistive technologies needs a non-empty accessible name. Without one, screen reader users encounter a frame with no description of what it contains. They hear something like "frame" with no additional context, which forces them to enter the frame and explore its contents just to understand its purpose. When a page has multiple iframes, this becomes especially disorienting.

Screen readers allow users to navigate between frames on a page. The accessible name of each frame is announced during this navigation, giving users a quick way to identify and skip to the content they want. A missing or generic name like "frame" or "iframe" removes that ability.

This rule maps to WCAG 2 success criterion 4.1.2 (Name, Role, Value) at Level A. That criterion requires user interface components to have a name that can be programmatically determined. Since browsers and assistive technologies generally treat <iframe> elements as UI components, each one must have a meaningful accessible name.

How to fix it

There are three ways to give an <iframe> an accessible name:

  1. Add a title attribute that describes the frame's content or purpose. This is the most widely supported approach across browser and assistive technology combinations.
  2. Add an aria-label attribute with a descriptive text string. Be aware that some browser and assistive technology combinations ignore aria-label on iframes and only read the title attribute.
  3. Use aria-labelledby to reference a visible text element elsewhere on the page.

Because of the aria-label inconsistency mentioned above, using the title attribute is the safest choice for broad support.

The name should describe the purpose or content of the frame. Avoid generic labels like "frame", "iframe", or "content". A name like "Video player" or "Contact form" tells the user what to expect.

If the iframe is purely decorative or should not be exposed to assistive technologies, add aria-hidden="true" to remove it from the accessibility tree. In that case, no accessible name is needed. Note that hiding an iframe from assistive technologies does not remove it from keyboard tab order unless you also set a negative tabindex. Behavior around focus and hidden iframes varies across browsers, so test carefully.

Examples

Incorrect: iframe with no accessible name

This iframe has no title, aria-label, or aria-labelledby attribute. Screen readers will announce it as a generic frame with no description.

<iframe src="/promotions.html"></iframe>

Incorrect: iframe with a generic title

A title like "iframe" gives no useful information to the user.

<iframe title="iframe" src="/promotions.html"></iframe>

Correct: iframe with a descriptive title

The title attribute clearly describes the content of the frame.

<iframe title="Current promotions" src="/promotions.html"></iframe>

Correct: iframe with aria-label

The aria-label attribute provides the accessible name directly. Keep in mind that some assistive technologies may not read aria-label on iframes, so the title attribute is a more reliable alternative.

<iframe aria-label="Current promotions" src="/promotions.html"></iframe>

Correct: iframe with aria-labelledby

The iframe gets its accessible name from a visible element on the page.

<h2 id="promo-heading">Current promotions</h2>
<iframe aria-labelledby="promo-heading" src="/promotions.html"></iframe>

Correct: decorative iframe hidden from assistive technologies

When an iframe is decorative or not relevant to the user, hide it from the accessibility tree. No accessible name is required in this case.

<iframe src="/decorative-animation.html" aria-hidden="true" tabindex="-1"></iframe>

Detect accessibility issues automatically

Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.

Help us improve our guides

Was this guide helpful?
๐ŸŒ Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial โ†’

Join teams across 40+ countries