Accessibility Guides for Trusted Tester

An image map consists of a single image with numerous clickable sections. Because screen readers cannot translate graphics into text, an image map, like all images, must contain alternative text for each of the distinct clickable parts, as well as for the larger image itself.

In the absence of alternative text, screen readers often announce the image’s filename. Filenames do not accurately describe images and are therefore inconvenient for screen reader users.

What this Accessibility Rule Checks

Ensures that image map area elements have alternative text.

When you assign a role like link, button, or menuitem to an element, you are telling the browser and assistive technologies that this element is an interactive command. Screen readers rely on the accessible name of these elements to communicate their purpose to the user. If no accessible name exists, a screen reader might announce something like “button” or “link” with no additional context — leaving the user with no way to understand what the control does.

This issue primarily affects users who are blind or have low vision and rely on screen readers, but it also impacts users with mobility impairments who may use voice control software to activate elements by name. If there is no name, voice control users cannot target the element with a spoken command.

Related WCAG Success Criteria

This rule maps to WCAG Success Criterion 4.1.2: Name, Role, Value (Level A). This criterion requires that all user interface components have a name that can be programmatically determined. It applies across WCAG 2.0, 2.1, and 2.2, and is also referenced in EN 301 549 (9.4.1.2), Trusted Tester guidelines, and RGAA.

The Trusted Tester guidelines further specify that the purpose of each link or button must be determinable from some combination of its text, accessible name, accessible description, or programmatically determined context.

How to Fix It

Ensure that every element with role="link", role="button", or role="menuitem" has an accessible name through one of these methods:

1. Inner text content — Place readable text inside the element.
2. aria-label attribute — Add a non-empty aria-label with a descriptive name.
3. aria-labelledby attribute — Point to the id of another element that contains visible, non-empty text.
4. title attribute — Use a title attribute as a fallback (though aria-label or visible text is preferred).

When possible, prefer using native HTML elements (<a>, <button>) over custom ARIA roles, as they come with built-in accessibility behaviors. If you must use ARIA roles, always make sure the accessible name is clear and describes the action or destination.

Examples

Incorrect: No accessible name

These elements will be flagged because screen readers cannot determine their purpose.

<!-- Empty element with no text or label -->

<div role="link"></div>

<!-- Empty aria-label provides no name -->

<div role="button" aria-label=""></div>

<!-- aria-labelledby points to a non-existent element -->

<div role="menuitem" aria-labelledby="nonexistent"></div>

<!-- aria-labelledby points to an empty element -->

<div role="link" aria-labelledby="empty-label"></div>
<div id="empty-label"></div>

Correct: Accessible name provided

Each of these elements has a discernible name that screen readers can announce.

<!-- Inner text content -->

<div role="link" tabindex="0">Visit our help center</div>

<!-- aria-label attribute -->

<div role="button" tabindex="0" aria-label="Close dialog"></div>

<!-- aria-labelledby pointing to visible text -->

<div role="menuitem" tabindex="0" aria-labelledby="menu-label">
  <span id="menu-label">Save document</span>
</div>

<!-- Combination of aria-label and inner text -->

<div role="link" tabindex="0" aria-label="Learn more about pricing">
  Learn more
</div>

<!-- title attribute as a fallback -->

<div role="button" tabindex="0" title="Submit form"></div>

Preferred: Use native HTML elements

Native elements handle naming and keyboard behavior automatically, reducing the chance of accessibility issues.

<a href="/help">Visit our help center</a>

<button type="button">Close dialog</button>

Note: When testing with RGAA, issues reported by this rule may need to be mapped to a different RGAA test, such as 6.2.1 for links.

Elements with aria-hidden must not contain focusable elements.

Using the property aria-hidden="true" on an element removes the element and all of its child nodes from the accessibility API, rendering the element fully unavailable to screen readers and other assistive technology.

aria-hidden may be used with extreme discretion to hide visibly displayed content from assistive technologies if the act of hiding this content is meant to enhance the experience of assistive technology users by reducing redundant or superfluous content.

If aria-hidden is employed to hide material from screen readers, the same or equal meaning and functionality must be made available to assistive technologies.

Using aria-hidden="false" on content that is a descendant of an element that is hidden using aria-hidden="true" will not reveal that content to the accessibility API, nor will it be accessible to screen readers or other assistive technology.

The rule applies to any element whose aria-hidden attribute value is true.

By adding aria-hidden="true" to an element, authors assure that assistive technologies will disregard the element. This can be used to hide aesthetic elements, such as icon typefaces, that are not intended to be read by assistive technologies.

A focusable element with aria-hidden="true" is disregarded as part of the reading order, but is still part of the focus order, making it unclear if it is visible or hidden.

What this Accessibility Rule Checks

For all user interface components, including form elements, links, and script-generated components, the name and role can be identified programmatically; user-specified states, properties, and values can be set programmatically; and user agents, including assistive technologies, are notified of changes.

Ensures every ARIA input field has an accessible name.

This rule ensures that each ARIA input field has a name that is accessible.

There must be accessible names for the following input field roles:

• combobox
• listbox
• searchbox
• slider
• spinbutton
• textbox

What this Accessibility Rule Checks

The names of ARIA input fields must be accessible.

Makes certain that each ARIA toggle field has an accessible name.

Ensures that any element having a semantic role has a name that is easily accessible.

Among the semantic roles are:

• checkbox
• menu
• menuitemcheckbox
• menuitemradio
• radio
• radiogroup
• switch

What this Accessibility Rule Checks

There is an accessible name for ARIA toggle fields.

This rule demands the absence of any blink elements. Blinking items might be challenging to activate, and flashing writing can be challenging to read.

The blink tag causes information to blink, as the name implies. Although you might enjoy the appearance, blinking text and objects (such as links and buttons) might be challenging to read and operate, especially for people with poor hand-eye coordination or limited dexterity.

For those who have visual or cognitive impairments, reading blinking letters can be quite challenging. Text that blinks can be annoying, especially for people who have cognitive difficulties. Some people may find it challenging to understand. The blink element should never be used due to these reasons.

What this Accessibility Rule Checks

Verifies that the blink element is never utilized.

When a button lacks an accessible name, assistive technologies like screen readers can only announce it generically — for example, as “button” — with no indication of its purpose. This is a critical barrier for people who are blind or deafblind, as they rely entirely on programmatically determined names to understand and interact with interface controls. A sighted user might infer a button’s purpose from an icon or visual context, but without a text-based name, that information is completely lost to assistive technology users.

This rule maps to WCAG 2.0, 2.1, and 2.2 Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that all user interface components have a name that can be programmatically determined. It is also covered by Section 508, EN 301 549 (9.4.1.2), and Trusted Tester guidelines, which require that the purpose of every link and button be determinable from its accessible name, description, or context.

How to fix it

Ensure every <button> element or element with role="button" has an accessible name through one of these methods:

1. Visible text content inside the button element.
2. A non-empty aria-label attribute that describes the button’s purpose.
3. An aria-labelledby attribute that references an element containing visible, non-empty text.
4. A title attribute (use as a last resort, since title tooltips are inconsistently exposed across devices).

If a button is purely decorative and should be hidden from assistive technologies, you can assign role="presentation" or role="none" and remove it from the tab order with tabindex="-1". However, this is rare for interactive buttons.

Common mistakes to avoid

• Leaving a <button> element completely empty.
• Using only a value attribute on a <button> — unlike <input> elements, the value attribute on <button> does not provide an accessible name.
• Setting aria-label to an empty string (aria-label="").
• Pointing aria-labelledby to an element that doesn’t exist or contains no text.
• Using only an icon or image inside a button without providing alternative text.

Examples

Incorrect: empty button

<button id="search"></button>

A screen reader announces this as “button” with no indication of its purpose.

Incorrect: button with only a value attribute

<button id="submit" value="Submit"></button>

The value attribute does not set the accessible name for <button> elements.

Incorrect: empty aria-label

<button id="close" aria-label=""></button>

An empty aria-label results in no accessible name.

Incorrect: aria-labelledby pointing to a missing or empty element

<button id="save" aria-labelledby="save-label"></button>
<div id="save-label"></div>

The referenced element exists but contains no text, so the button has no accessible name.

Correct: button with visible text

<button>Submit order</button>

Correct: icon button with aria-label

<button aria-label="Close dialog">
  <svg aria-hidden="true" focusable="false">
    <use href="#icon-close"></use>
  </svg>
</button>

The aria-label provides the accessible name, while aria-hidden="true" on the SVG prevents duplicate announcements.

Correct: button labeled by another element

<h2 id="section-title">Shopping cart</h2>
<button aria-labelledby="section-title">
  <svg aria-hidden="true" focusable="false">
    <use href="#icon-arrow"></use>
  </svg>
</button>

The button’s accessible name is drawn from the referenced heading text.

Correct: button with aria-label and visible text

<button aria-label="Search products">Search</button>

When both aria-label and inner text are present, aria-label takes precedence as the accessible name. Use this when you need a more descriptive name than what the visible text alone conveys.

Correct: button with title (last resort)

<button title="Print this page">
  <svg aria-hidden="true" focusable="false">
    <use href="#icon-print"></use>
  </svg>
</button>

The title attribute provides an accessible name, but visible text or aria-label are preferred because title tooltips may not be available to touch-screen or keyboard-only users.

Each page must have a main landmark to allow users to rapidly traverse repetitive blocks of material or interface elements (such as the header and navigation) and get the primary content.

Due to the fact that websites frequently display secondary, repetitive content on several pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to a page’s principal content. This saves keystrokes and reduces physical discomfort.

It is more difficult and time-consuming for users who cannot use a mouse to navigate using the keyboard if the interface does not provide features to facilitate keyboard navigation. To activate a link in the middle of a web page, for instance, a keyboard user may have to browse through a significant number of links and buttons in the page’s header and primary navigation.

Extremely motor-impaired users may require several minutes to browse through all of these pieces, which can cause to tiredness and potential physical pain for some users. Even users with less severe limitations will require more time than users with a mouse, who can click on the desired link in less than a second.

What this Accessibility Rule Checks

Checks for the presence of at least one of the following features:

• an internal skip link
• a header
• a geographical landmark

Color contrast is one of the most common accessibility barriers on the web. When text doesn’t stand out enough from its background, it becomes difficult or impossible to read for many users. People with low vision experience reduced contrast sensitivity, meaning everything appears roughly the same brightness, making it hard to distinguish outlines, edges, and details. Approximately 1 in 12 people cannot see the full spectrum of colors — about 8% of men and 0.4% of women in the United States have some form of color vision deficiency. Nearly three times as many people have low vision compared to total blindness. Without sufficient contrast, these users simply cannot read your content.

This rule maps to WCAG 2.1 Success Criterion 1.4.3: Contrast (Minimum), which is a Level AA requirement. It is also referenced in WCAG 2.0, WCAG 2.2, the Trusted Tester methodology, EN 301 549, and RGAA. The user impact is considered serious because insufficient contrast directly prevents users from perceiving text content.

How Contrast Ratios Work

Contrast ratio is calculated by comparing the relative luminance of two colors on a scale from 1:1 (no contrast, e.g., white on white) to 21:1 (maximum contrast, black on white). WCAG defines two thresholds:

• Normal text (below 18pt or below 14pt bold): minimum 4.5:1 contrast ratio
• Large text (at least 18pt / 24px, or at least 14pt bold / 19px): minimum 3:1 contrast ratio

“Large text” is defined this way because larger characters have wider strokes that are easier to read at lower contrast levels.

What This Rule Checks

The color-contrast rule in axe-core examines each text element on the page and compares the computed foreground text color against the computed background color. It accounts for background color transparency and opacity. Elements that are found to have a 1:1 contrast ratio are flagged as “incomplete” and require manual review.

This rule does not flag:

• Text elements with a background-image (these require manual testing)
• Text that is visually hidden by other overlapping elements
• Images of text
• Text inside disabled controls (including child elements of disabled buttons)

Some foreground scenarios are harder for automated tools to evaluate, including CSS gradients, pseudo-element backgrounds, backgrounds created with CSS borders, and elements repositioned off-screen with CSS.

How to Fix It

1. Identify the failing elements by running axe. Each violation will report the current contrast ratio and the colors involved.
2. Adjust the foreground color, background color, or both until the required ratio is met (4.5:1 for normal text, 3:1 for large text).
3. Use a contrast checker tool like the axe DevTools browser extension, the WebAIM Contrast Checker, or the built-in color contrast analyzer in browser developer tools to test color combinations before deploying.
4. Test with real content — sometimes dynamic content or themed components produce contrast issues that static checks miss.

Examples

Insufficient contrast (fails)

This light gray text on a white background has a contrast ratio of approximately 2.6:1, which fails the 4.5:1 requirement.

<p style="color: #aaaaaa; background-color: #ffffff;">
  This text is hard to read.
</p>

Sufficient contrast (passes)

Darkening the text color to #595959 against a white background achieves a contrast ratio of approximately 7:1, meeting the requirement.

<p style="color: #595959; background-color: #ffffff;">
  This text is easy to read.
</p>

Large text with lower contrast requirement (passes)

Large text (18pt or larger) only needs a 3:1 contrast ratio. This example uses #767676 on white, which has a ratio of approximately 4.5:1 — well above the 3:1 threshold for large text.

<h1 style="font-size: 24pt; color: #767676; background-color: #ffffff;">
  Large heading text
</h1>

Semi-transparent background (fails)

Transparency can reduce effective contrast. Here, the semi-transparent white background doesn’t provide enough contrast depending on what’s behind it.

<div style="background-color: #cccccc;">
  <p style="color: #777777; background-color: rgba(255, 255, 255, 0.3);">
    Text with a semi-transparent background.
  </p>
</div>

Semi-transparent background fixed (passes)

Increasing the background opacity or adjusting colors restores sufficient contrast.

<div style="background-color: #cccccc;">
  <p style="color: #333333; background-color: rgba(255, 255, 255, 0.85);">
    Text with a more opaque background.
  </p>
</div>

Using CSS classes (passes)

In practice, you’ll likely use CSS classes rather than inline styles. Ensure your design system tokens and theme colors meet contrast requirements.

<style>
  .card {
    background-color: #1a1a2e;
  }
  .card-text {
    color: #e0e0e0;
  }
</style>

<div class="card">
  <p class="card-text">
    Light text on a dark background with good contrast.
  </p>
</div>

The <title> element is the very first piece of information screen reader users hear when a page loads. It’s also what appears in browser tabs, bookmarks, and search engine results. When a page has no title — or has an empty or generic one like “Untitled” — screen reader users are forced to read through the page content to figure out its purpose. For users who navigate between multiple open tabs or use their browser history to find a previous page, missing or vague titles create serious barriers.

This rule relates to WCAG 2.4.2 Page Titled (Level A), which requires that web pages have titles describing their topic or purpose. Because this is a Level A criterion, it represents a minimum baseline for accessibility. The rule also aligns with Trusted Tester guideline 12.A and EN 301 549.

The users most affected by missing or poor page titles include:

• Screen reader users (blind and deafblind users), who rely on the title as the first orientation cue when a page loads
• Users with cognitive disabilities, who benefit from clear, descriptive titles to understand where they are
• Keyboard-only users and anyone navigating between multiple tabs, who use titles to distinguish pages

How to fix it

1. Add a <title> element inside the <head> of every HTML document.
2. Write meaningful text inside the <title> — it must not be empty or contain only whitespace.
3. Make each title unique across your site so users can distinguish between pages.
4. Put the most unique information first. If you include a site or brand name, place it at the end (e.g., “Contact Us – Acme Corp” rather than “Acme Corp – Contact Us”). This way, screen reader users hear the distinguishing content immediately instead of listening to the same brand name on every page.
5. Align the title with the page’s <h1> heading. They don’t need to be identical, but they should be closely related since both describe the page’s purpose.
6. Avoid placeholder text like “Untitled,” “Page 1,” or “New Document.”

Beyond accessibility, descriptive titles improve SEO since search engines use them to filter, rank, and display results.

Examples

Incorrect: missing <title> element

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <h1>Our Products</h1>
  </body>
</html>

This page has no <title> element at all. Screen reader users will hear no identifying information when the page loads.

Incorrect: empty <title> element

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title></title>
  </head>
  <body>
    <h1>Our Products</h1>
  </body>
</html>

A <title> element is present but contains no text, which is equivalent to having no title.

Incorrect: generic or placeholder title

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Untitled Document</title>
  </head>
  <body>
    <h1>Our Products</h1>
  </body>
</html>

While technically not empty, a placeholder title provides no useful information about the page’s content.

Correct: descriptive and unique title

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Our Products – Acme Corp</title>
  </head>
  <body>
    <h1>Our Products</h1>
  </body>
</html>

The title clearly describes the page content, places the unique information first, and includes the site name at the end for context. It also closely matches the <h1> heading on the page.

When a form field has more than one <label> element pointing to it (either via the for attribute or by nesting), assistive technologies have no reliable way to determine which label is the correct one. This inconsistency means that users who are blind, have low vision, or are deafblind may hear the wrong label, an incomplete label, or a confusing combination of labels when interacting with a form. Users with mobility impairments also benefit from properly associated labels, since a single clear <label> expands the clickable area of the associated input.

This rule relates to WCAG 2.0, 2.1, and 2.2 Success Criterion 3.3.2: Labels or Instructions (Level A), which requires that labels or instructions are provided when content requires user input. Multiple conflicting labels undermine this requirement because the user cannot reliably receive a single, clear label for the field.

How to Fix

Ensure that each form field has only one <label> element associated with it. You can associate a label with a field in one of two ways — but use only one label per field:

1. Explicit association — Use the for attribute on the <label> matching the id of the input.
2. Implicit association — Wrap the input inside the <label> element.

If you need to provide additional descriptive text beyond the label, use aria-describedby to point to supplementary instructions rather than adding a second <label>.

If you have a situation where one label must be visually hidden, hide the redundant label using CSS (display: none or visibility: hidden) so it is fully removed from the accessibility tree, and remove its for attribute. Using aria-hidden="true" alone on a <label> is not sufficient to prevent all screen readers from associating it with the field.

Examples

Incorrect: Two explicit labels for one input

Both <label> elements use for="username", causing unpredictable screen reader behavior.

<label for="username">Username</label>
<label for="username">Enter your username</label>
<input type="text" id="username" />

Incorrect: One explicit and one implicit label

The input is both wrapped in a <label> and referenced by another <label> via for.

<label for="email">Email</label>
<label>
  Email address:
  <input type="text" id="email" />
</label>

Incorrect: Nested labels

Labels should never be nested inside each other.

<label>
  Enter your comments:
  <label>
    Comments:
    <textarea id="comments"></textarea>
  </label>
</label>

Correct: Single explicit label

One <label> with a for attribute matching the input’s id.

<label for="username">Username</label>
<input type="text" id="username" />

Correct: Single implicit label

The input is wrapped inside a single <label>.

<label>
  Email address:
  <input type="text" id="email" />
</label>

Correct: Label with supplementary instructions using aria-describedby

When you need to provide extra guidance beyond the label, use aria-describedby instead of a second label.

<label for="password">Password</label>
<input type="password" id="password" aria-describedby="password-hint" />
<p id="password-hint">Must be at least 8 characters with one number.</p>

Correct: Using the title attribute as a label

When a visible label is not appropriate (rare cases), the title attribute can serve as an accessible name.

<textarea id="search" title="Search terms"></textarea>

Correct: Select inside a single label

<label>
  Choose an option:
  <select id="options">
    <option selected>Option A</option>
    <option>Option B</option>
  </select>
</label>

tabindex="-1" cannot be present in <frame> and <iframe> elements with focusable content.

The browser is unable to move the focus to the content included in a frame when it has a negative tabindex. This stops keyboard navigation from skipping all of its content, and if the frame is scrollable, it also prevents the focus from moving to any element from which the frame may be scrolled.

What this Accessibility Rule Checks

Examine all frame and iframe elements that contain a negative tabindex value, such as tabindex="-1". If there are any such frames, make sure they don’t have nested frames that do contain focusable items.

Screen reader users rely on frame titles to understand what each embedded region of a page contains. Many screen readers offer a feature that lists all frames on a page by their titles, allowing users to jump directly to the one they need. When frames lack titles or share identical titles, this feature becomes useless — users are left guessing which frame is which, or the screen reader falls back to unhelpful information like “frame,” “javascript,” a filename, or a URL.

This issue primarily affects users who are blind, deafblind, or who navigate with assistive technologies. It relates to WCAG 2.0, 2.1, and 2.2 Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that all user interface components have an accessible name that can be programmatically determined. When frames share a title, their accessible names fail to uniquely identify them, violating this criterion. The rule is also covered by Trusted Tester guideline 12.D, which requires that the combination of accessible name and description for each <iframe> describes its content, as well as EN 301 549 section 9.4.1.2.

How to Fix It

1. Add a title attribute to every <frame> and <iframe> element.
2. Make each title unique across the page. No two frames should share the same title.
3. Make each title descriptive. The title should clearly summarize the content or purpose of the frame. Avoid generic labels like “frame” or “untitled.”
4. Match the frame’s inner document <title> to the title attribute on the frame element when possible. Some screen readers replace the frame’s title attribute with the inner document’s <title> element, so keeping them consistent ensures a reliable experience.

Tips for Writing Good Frame Titles

• Keep titles brief but informative — describe what the frame contains, not just that it exists.
• Put the most distinctive information first. If you include a brand name, place it at the end so users don’t have to hear it repeatedly while scanning a list of frames.
• Replace placeholder titles like “untitled” or “page” with meaningful descriptions.
• If the framed content has a visible heading, consider aligning the frame title with that heading for consistency.

Examples

Incorrect: Frames with Duplicate Titles

In this example, two iframes share the same title, making it impossible for screen reader users to tell them apart.

<iframe src="/news.html" title="Company Updates"></iframe>
<iframe src="/events.html" title="Company Updates"></iframe>

Incorrect: Frame with an Empty Title

An empty title provides no useful information to assistive technology users.

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

Incorrect: Frames with No Title

Without any title attribute, screen readers fall back to announcing unhelpful information like the URL or “frame.”

<iframe src="/navigation.html"></iframe>
<iframe src="/main-content.html"></iframe>

Correct: Frames with Unique, Descriptive Titles

Each frame has a distinct title that clearly describes its content.

<iframe src="/news.html" title="Latest Company News"></iframe>
<iframe src="/events.html" title="Upcoming Events Calendar"></iframe>

Correct: Frame Title Matching the Inner Document Title

For the best experience, align the title attribute with the <title> element in the framed document.

<!-- Parent page -->

<iframe src="/contact.html" title="Contact Form"></iframe>

<!-- contact.html -->

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Contact Form</title>
</head>
<body>
  <h1>Contact Us</h1>
  <form>
    <label for="email">Email</label>
    <input type="email" id="email" name="email">
    <button type="submit">Send</button>
  </form>
</body>
</html>

Correct: Hiding Decorative or Non-Content Frames

If a frame is purely decorative or contains no meaningful content for users (such as a tracking pixel), hide it from assistive technology entirely instead of giving it a misleading title.

<iframe src="/tracking-pixel.html" title="" aria-hidden="true" tabindex="-1"></iframe>

Note that this approach should only be used when the frame genuinely contains no content that any user would need to access.

When used in a document, the frame or iframe element’s title attribute must not be empty in order to provide context for users of screen reader software.

Users of screen readers depend on the title of a frame to describe its contents. If the HTML for a frame or iframe element lacks a title attribute, navigating within the element can be a frustrating and time-consuming experience for users of this technology.

Users of screen readers can see a list of the frames on a page and their respective titles. Providing each frame with a distinct, descriptive label facilitates easy navigation. Without titles, it’s easy to get lost trying to jump from one frame to the next. Screen readers will instead provide information like “frame,” “JavaScript,” the filename, or the URL if no title is provided. This data is unlikely to be useful in most situations.

What this Accessibility Rule Checks

Make sure the title attribute of every iframe and frame element is both distinct and not empty.

Screen readers rely on distinct sound libraries for each language, with pronunciation rules, intonation patterns, and phonetics tailored to that specific language. When a user navigates to a page, the screen reader checks the lang attribute on the <html> element to determine which sound library to load. If no lang attribute is present, the screen reader falls back to whatever default language the user configured during setup. For someone who speaks multiple languages and browses websites in different languages, this creates a serious problem — the screen reader will attempt to read foreign-language content using the wrong pronunciation rules, producing garbled or incomprehensible speech.

This issue primarily affects blind and deafblind users who rely on screen readers, but it also impacts users with cognitive disabilities who may use text-to-speech tools. When text is read aloud with the wrong language rules, even simple words become unrecognizable, effectively making the content inaccessible.

Related WCAG Success Criteria

This rule maps to WCAG 2.0, 2.1, and 2.2 Success Criterion 3.1.1: Language of Page at Level A — the most fundamental level of conformance. This criterion requires that the default human language of each web page can be programmatically determined. It is also referenced by the Trusted Tester guidelines (11.A), EN 301 549, and RGAA.

How to Fix It

Add a lang attribute with a valid language code to the opening <html> element. The value should represent the primary language of the page content.

You can use a simple two-letter language code (like en for English, fr for French, or de for German), or you can be more specific with a regional dialect code like en-US for American English or fr-CA for Canadian French. A full list of valid language subtags is available in the IANA Language Subtag Registry.

If sections of your page contain content in a different language than the primary one, use the lang attribute on those specific elements so screen readers can switch sound libraries mid-page.

For languages written right to left (such as Arabic or Hebrew), also include the dir attribute with a value of rtl to indicate the text direction.

Examples

Incorrect: Missing lang attribute

This will trigger the rule because the <html> element has no lang attribute:

<html>
  <head>
    <title>My Website</title>
  </head>
  <body>
    <h1>Welcome</h1>
  </body>
</html>

Correct: lang attribute with a valid language code

<html lang="en">
  <head>
    <title>My Website</title>
  </head>
  <body>
    <h1>Welcome</h1>
  </body>
</html>

Correct: Using a regional dialect code

<html lang="en-US">
  <head>
    <title>My Website</title>
  </head>
  <body>
    <h1>Welcome</h1>
  </body>
</html>

Correct: Handling inline language changes

When a portion of the page is in a different language, use the lang attribute on the containing element:

<html lang="en">
  <head>
    <title>My Website</title>
  </head>
  <body>
    <p>The French word for hello is <span lang="fr">bonjour</span>.</p>
  </body>
</html>

Correct: Right-to-left language with dir attribute

<html lang="ar" dir="rtl">
  <head>
    <title>موقعي</title>
  </head>
  <body>
    <h1>مرحبا</h1>
  </body>
</html>

Screen readers rely on language-specific sound libraries to pronounce text accurately. Each language has its own pronunciation rules, intonation patterns, and phonetic characteristics, so screen readers load the appropriate library based on the declared language of the document. When the <html> element has no lang attribute or contains an invalid value — such as a misspelling or a fabricated code — the screen reader cannot determine which library to use. It defaults to whatever language the user configured during setup, which means content written in French might be read aloud using English pronunciation rules. The result is speech that sounds like a confusing, unintelligible accent.

This issue primarily affects blind users and deafblind users who rely on screen readers, but it also impacts users with cognitive disabilities who may use text-to-speech tools to aid comprehension. When pronunciation is wrong, understanding drops dramatically.

Related WCAG Success Criteria

This rule maps to WCAG Success Criterion 3.1.1: Language of Page (Level A), which requires that the default human language of each web page can be programmatically determined. This is a Level A requirement — the most fundamental level of accessibility — meaning it must be satisfied for basic compliance under WCAG 2.0, 2.1, and 2.2. It is also required by the Trusted Tester methodology, EN 301 549, and RGAA.

How to Fix It

1. Add a lang attribute to the opening <html> element.
2. Set its value to a valid BCP 47 language tag that represents the primary language of the page.
3. Double-check the spelling of the language code. Common valid codes include "en" (English), "fr" (French), "es" (Spanish), "de" (German), "ja" (Japanese), and "ar" (Arabic).
4. You can optionally include a regional subtag, such as "en-US" for American English or "fr-CA" for Canadian French.
5. For XHTML documents served as XML, use xml:lang instead of or in addition to lang.

If the language changes within the document for specific passages, use the lang attribute on the appropriate element to indicate the switch. For right-to-left languages, also include the dir="rtl" attribute.

Examples

Incorrect: Missing lang attribute

<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Welcome to my website.</p>
  </body>
</html>

Without a lang attribute, screen readers cannot determine the page language and will default to the user’s configured language, which may not match the content.

Incorrect: Invalid lang value

<html lang="english">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Welcome to my website.</p>
  </body>
</html>

The value "english" is not a valid BCP 47 language tag. The correct code for English is "en".

Correct: Valid lang attribute

<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Welcome to my website.</p>
  </body>
</html>

Correct: Regional subtag

<html lang="fr-CA">
  <head>
    <title>Ma page</title>
  </head>
  <body>
    <p>Bienvenue sur mon site web.</p>
  </body>
</html>

Correct: Language change within the page

<html lang="en">
  <head>
    <title>Multilingual Page</title>
  </head>
  <body>
    <p>This paragraph is in English.</p>
    <p lang="es">Este párrafo está en español.</p>
  </body>
</html>

Correct: Right-to-left language

<html lang="ar" dir="rtl">
  <head>
    <title>صفحتي</title>
  </head>
  <body>
    <p>مرحبا بكم في موقعي.</p>
  </body>
</html>

The dir="rtl" attribute ensures the text direction is correctly rendered for right-to-left languages like Arabic and Hebrew.

Images are a fundamental part of web content, but they are inherently visual. Screen readers cannot interpret the pixels of an image — they rely entirely on a text alternative to describe the image’s content and purpose to the user. Without alternative text, a screen reader may read out the image’s file name (e.g., “IMG_20230415_093012.jpg”), which is meaningless and confusing. In the worst case, the image is silently skipped, and the user misses critical information.

This rule primarily affects people who are blind or deafblind, who depend on screen readers or braille displays to access content. Users with low vision who rely on text magnification or high-contrast modes can also benefit from well-written alternative text.

Why This Matters

This rule maps to WCAG 2.2 Success Criterion 1.1.1: Non-text Content (Level A), which requires that all non-text content presented to the user has a text alternative that serves an equivalent purpose. It is also required by Section 508 and EN 301 549. Because it is a Level A requirement, it represents the absolute minimum baseline for accessibility — failing it means your content is fundamentally inaccessible to many users.

How to Provide Alternative Text

There are three main techniques for giving an image accessible alternative text:

1. The alt attribute — the most common and preferred method for <img> elements.
2. The aria-label attribute — provides an accessible name directly on the element.
3. The aria-labelledby attribute — points to the id of another element that contains the descriptive text.

Writing Good Alt Text

When writing alternative text, consider these questions:

• Why is this image here? What role does it play in the content?
• What information does it convey? What would a sighted user take away from it?
• If you removed the image, what words would replace it to preserve the same meaning?

Keep alt text concise and descriptive. Avoid phrases like “image of” or “picture of” — screen readers already announce the element as an image. Don’t use the file name as alt text. Focus on the image’s purpose and meaning, not a pixel-by-pixel description.

Handling Decorative Images

Not every image carries meaning. Decorative images — such as visual separators, background flourishes, or images whose content is fully described in surrounding text — should be hidden from assistive technology. To do this, use an empty alt attribute: alt="".

Do not omit the alt attribute entirely. If alt is missing, screen readers will often fall back to reading the file name, which creates a worse experience than having no announcement at all. An empty alt="" explicitly tells the screen reader to skip the image.

You can also use role="presentation" or role="none" to mark an image as decorative, but an empty alt attribute is simpler and more widely supported.

Examples

Incorrect: Missing Alt Text

The alt attribute is completely absent. A screen reader may announce the file name instead.

<img src="team-photo.jpg">

Incorrect: Unhelpful Alt Text

The alt text contains the file name rather than a meaningful description.

<img src="chart-q3.png" alt="chart-q3.png">

Correct: Descriptive Alt Text Using the alt Attribute

<img src="team-photo.jpg" alt="The engineering team gathered around a whiteboard during a planning session">

Correct: Alt Text Using aria-label

<img src="revenue-chart.png" aria-label="Bar chart showing quarterly revenue increasing from $2M in Q1 to $3.5M in Q4">

Correct: Alt Text Using aria-labelledby

<p id="chart-desc">Bar chart showing quarterly revenue growth from Q1 to Q4 2024.</p>
<img src="revenue-chart.png" aria-labelledby="chart-desc">

Correct: Decorative Image with Empty Alt

This separator line serves no informational purpose and should be hidden from screen readers.

<img src="decorative-line.svg" alt="">

Correct: Decorative Image Using role="presentation"

<img src="decorative-swirl.png" role="presentation">

What This Rule Checks

This axe-core rule (image-alt) inspects every <img> element on the page and verifies that it has an accessible text alternative. Specifically, it checks that each <img> has at least one of the following:

• A non-empty alt attribute
• An aria-label attribute
• An aria-labelledby attribute that references a valid element
• An empty alt="" (or role="presentation" / role="none") to indicate the image is decorative

If none of these conditions are met, the rule flags the image as a critical accessibility violation.

Ensures that input buttons have legible text.

Without an accessible name, screen reader users cannot determine the purpose of a input type="button".

Without a discernible and accessible name, screen reader users cannot grasp the purpose of an image. A title for a photograph may just convey advisory information about the image. When used as a control, unnamed actionable visual images such as buttons have no clear definition of the destination, purpose, function, or action for the non-text material.

What this Accessibility Rule Checks

The text on input buttons must be readable.

An <input type="image"> element renders an image that functions as a submit button. Unlike standard <input type="submit"> buttons that display their value attribute as visible text, image buttons rely entirely on their visual appearance to communicate purpose. This means assistive technologies have no way to determine the button’s function unless you explicitly provide alternative text.

This is a critical accessibility barrier for several groups of users. Blind and deafblind users who rely on screen readers will hear something generic like “button” or, worse, the image file name (e.g., “btn_submit_v2.png”), which provides no useful information. Users with low vision who use screen magnifiers in combination with screen readers are similarly affected. Without a clear accessible name, these users cannot confidently interact with forms.

This rule relates to two WCAG success criteria at Level A — the minimum conformance level:

• WCAG 1.1.1 (Non-text Content): All non-text content must have a text alternative that serves the equivalent purpose. An image button is non-text content, so it needs alternative text.
• WCAG 4.1.2 (Name, Role, Value): All user interface components must have a programmatically determinable name. Buttons must expose their name to assistive technologies.

This requirement is also mandated by Section 508, EN 301 549, and the Trusted Tester guidelines.

How to fix it

Provide a non-empty accessible name for every <input type="image"> element using one of these methods:

1. alt attribute (preferred): Add an alt attribute that describes the button’s action. This is the most straightforward and widely supported approach.
2. aria-label attribute: Set an aria-label with a concise description of the button’s action.
3. aria-labelledby attribute: Reference the id of another visible element that describes the button’s action.

Writing effective alternative text

The alternative text for an image button should describe the action the button performs, not the image itself. Ask yourself: “What happens when the user clicks this button?” The answer is your alternative text.

• ✅ “Submit”, “Search”, “Add to cart”, “Log in”
• ❌ “Green arrow icon”, “button.png”, “click here”

Avoid filler words like “image of” or “button” — assistive technologies already announce the element’s role as a button.

Important: Simply placing text next to the image button in the HTML is not sufficient. Screen readers need a programmatically associated label, not visually adjacent text. Nearby text cannot be reliably determined as the button’s label by assistive technologies.

Examples

Incorrect: missing alternative text

The image button has no alt, aria-label, or aria-labelledby attribute. A screen reader might announce this as “submit.png button” or just “button.”

<form action="/search">
  <label for="query">Search</label>
  <input type="text" id="query" name="q">
  <input type="image" src="search-icon.png">
</form>

Incorrect: empty alt attribute

An empty alt attribute tells assistive technologies to ignore the element, effectively hiding the button entirely.

<input type="image" src="search-icon.png" alt="">

Correct: using the alt attribute

<form action="/search">
  <label for="query">Search</label>
  <input type="text" id="query" name="q">
  <input type="image" src="search-icon.png" alt="Search">
</form>

Correct: using aria-label

<input type="image" src="submit-arrow.png" aria-label="Submit order">

Correct: using aria-labelledby

The aria-labelledby attribute points to the id of a visible element. Make sure the referenced element exists and is not hidden with display: none or aria-hidden="true".

<h2 id="checkout-heading">Complete your purchase</h2>
<form action="/checkout">
<!-- form fields -->

  <input type="image" src="checkout-btn.png" aria-labelledby="checkout-heading">
</form>

What the rule checks

This rule verifies that every <input type="image"> element has a discoverable accessible name. It fails if the element has no alt, aria-label, or aria-labelledby attribute, or if those attributes are empty or resolve to an empty string.

Every form element — such as text inputs, checkboxes, radio buttons, and select menus — must have a programmatically associated label so that assistive technologies can identify and announce the purpose of each field. Without these labels, screen reader users cannot determine what information is expected, and users with motor impairments lose the benefit of a larger clickable target area that a properly associated <label> provides.

Why This Matters

When a form element lacks a programmatic label, screen readers either announce it generically (e.g., “edit text” or “checkbox”) or skip meaningful context entirely. This leaves blind, low-vision, and deafblind users unable to understand what data a field expects or what option a checkbox represents. They must guess based on surrounding content, which is unreliable and error-prone.

Labels also benefit users with motor impairments. When a <label> element is properly associated with an input, clicking the label text activates or focuses the associated control. This creates a larger click target, which is especially helpful for people with limited dexterity.

Sighted users often rely on visual proximity to infer a field’s purpose, but assistive technologies need an explicit programmatic relationship between the label text and the form control to convey the same information.

Relevant Standards

This rule maps to WCAG Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that all user interface components have an accessible name that can be programmatically determined. It applies across WCAG 2.0, 2.1, and 2.2, as well as Section 508 (§1194.22(n)), EN 301 549 (9.4.1.2), and Trusted Tester guidelines. The user impact is considered critical.

How to Fix It

There are several ways to associate a label with a form element. Use the approach that best fits your situation, listed here from most recommended to least recommended.

1. Explicit <label> with for and id (Recommended)

The most common and reliable method is to use a <label> element whose for attribute matches the id of the form control. This creates an unambiguous programmatic association.

2. Implicit <label> (Wrapping)

Wrap the form control inside a <label> element. The association is implied by the parent-child relationship.

3. aria-label

Use aria-label when the field’s purpose is conveyed visually through an icon or layout rather than visible text. This creates an invisible label that only screen readers announce.

4. aria-labelledby

Use aria-labelledby when the label text already exists elsewhere on the page, or when you need to combine multiple pieces of text into a single label. Reference one or more element id values.

5. placeholder (Not Recommended)

A placeholder attribute can technically provide an accessible name, but it disappears once the user begins typing, removing the visible label. This creates usability problems for everyone and is not a recommended approach.

General Tips

• Ensure all id values are unique on the page.
• Make label text descriptive and meaningful when read aloud in isolation.
• Remember that buttons (<button>, <input type="submit">, etc.) are self-labeling through their text content or value attribute and do not need a separate <label>.
• Hidden inputs (<input type="hidden">) do not need labels since they are not presented to users.

Examples

Incorrect: Input without a label

<div>First name:</div>
<input type="text" id="firstname">

The <div> text is visually near the input, but there is no programmatic relationship. A screen reader will announce only “edit text” with no context.

Correct: Explicit label with for and id

<label for="firstname">First name:</label>
<input type="text" id="firstname">

Correct: Implicit label by wrapping

<label>
  First name:
  <input type="text">
</label>

Correct: aria-label for visually implied fields

<input type="text" aria-label="Search">
<button type="submit">🔍</button>

Correct: aria-labelledby referencing existing text

<div id="temp-label">Temperature</div>
<div id="high-label">High:</div>
<div id="low-label">Low:</div>

<input type="text" aria-labelledby="temp-label high-label">
<input type="text" aria-labelledby="temp-label low-label">

The first input is announced as “Temperature High:” and the second as “Temperature Low:”, combining the referenced text in order.

Incorrect: Relying only on placeholder

<input type="text" placeholder="Enter your email">

While this technically provides an accessible name, the visible hint disappears when the user starts typing, making it difficult to verify the field’s purpose. Always prefer a persistent visible label.

Correct: Visible label with supplementary placeholder

<label for="email">Email address</label>
<input type="text" id="email" placeholder="name@example.com">

Incorrect: Checkbox without a label

<input type="checkbox" id="terms">
I agree to the terms and conditions

The text is adjacent but not associated with the checkbox.

Correct: Labeled checkbox

<input type="checkbox" id="terms">
<label for="terms">I agree to the terms and conditions</label>

Why This Matters

Many users cannot perceive color differences reliably. Approximately 8% of men and 0.4% of women have some form of color vision deficiency, and there are nearly three times more people with low vision than those who are totally blind. For these users, if a link within a paragraph is styled only with a different color — say, blue text in a block of black text — it can be completely invisible as a link.

People with low vision often experience reduced contrast sensitivity, meaning everything appears roughly the same brightness. Without a non-color cue like an underline or a sufficient luminance difference, these users cannot detect that certain text is interactive. This can cause them to miss important navigation, actions, or information entirely.

This rule relates to WCAG 2.0/2.1/2.2 Success Criterion 1.4.1: Use of Color (Level A), which requires that color is not used as the only visual means of conveying information, indicating an action, or distinguishing a visual element. Links embedded in text are one of the most common places where this requirement is violated.

How the Rule Works

The axe rule link-in-text-block checks links that appear inside blocks of text (such as paragraphs) and evaluates them in three steps:

1. Non-color distinction present → Pass. If the link has a visual style that doesn’t depend on color — such as an underline, a border, a background color, or a distinct font weight/style — the rule passes automatically.

2. No non-color distinction and contrast below 3:1 → Fail. If the link relies only on color and the contrast ratio between the link text color and the surrounding text color is less than 3:1, the rule fails.

3. No non-color distinction but contrast is 3:1 or higher → Needs Review. If the link relies only on color but meets the 3:1 contrast threshold, the rule flags it for manual testing. You must verify that the link receives a distinct visual style (such as an underline) on :focus and :hover states.

How to Fix It

The simplest and most reliable fix is to give links a non-color visual indicator. Here are your options, in order of recommendation:

• Underline the link — This is the most universally understood link indicator.
• Add a border — A border-bottom can work as an alternative to text-decoration.
• Use a distinct font style — Bold or italic can help, though underline is more conventional for links.
• Add a background or outline — A subtle background color difference can work if it’s clearly visible.

If you choose to rely on color contrast alone (3:1 minimum between link text and surrounding text), you must also ensure the link gains a distinct non-color style on :hover and :focus. This two-part requirement exists because static contrast alone may not be sufficient for all users, but a visual change on interaction confirms the element is interactive.

Examples

Incorrect: Link distinguished only by color with insufficient contrast

<style>
  p { color: #333333; }
  a { color: #555555; text-decoration: none; }
</style>

<p>
  Learn more about our
  <a href="/services">consulting services</a>
  and how we can help.
</p>

In this example, the link has no underline and the color contrast between #555555 and #333333 is well below 3:1. Users with low vision or color blindness cannot identify the link.

Correct: Link has an underline (recommended)

<style>
  p { color: #333333; }
  a { color: #0056b3; text-decoration: underline; }
</style>

<p>
  Learn more about our
  <a href="/services">consulting services</a>
  and how we can help.
</p>

The underline provides a clear non-color visual cue, making the link identifiable regardless of color perception.

Correct: Link uses a bottom border instead of underline

<style>
  p { color: #333333; }
  a {
    color: #0056b3;
    text-decoration: none;
    border-bottom: 2px solid #0056b3;
  }
</style>

<p>
  Read our
  <a href="/guide">accessibility guide</a>
  for detailed instructions.
</p>

Correct: Color-only link with sufficient contrast plus hover/focus styles

<style>
  p { color: #333333; }
  a {
    color: #0000ee;
    text-decoration: none;
  }
  a:hover,
  a:focus {
    text-decoration: underline;
  }
</style>

<p>
  Visit our
  <a href="/help">help center</a>
  for answers to common questions.
</p>

Here the contrast between #0000ee and #333333 exceeds 3:1, and the link gains an underline on hover and focus. This satisfies the requirement, though note that axe will still flag this for manual review since it cannot automatically verify the hover/focus styles in all cases.

Incorrect: Underline removed with no replacement

<style>
  a { color: #1a73e8; text-decoration: none; }
  p { color: #000000; }
</style>

<p>
  Check out our
  <a href="/blog">latest blog posts</a>
  for updates.
</p>

Even though the blue color may seem obvious to sighted users with full color vision, removing the underline without providing another non-color indicator makes this link invisible to users with color blindness or low contrast sensitivity.

When used as links, link text and alternative text for images must be recognizable by screen readers, have no duplicate labels, and be focusable.

• Accessibility is hindered by inaccessible link components, as they are a crucial component of a website.
• Users who traverse a webpage using only the keyboard (and no mouse) can only click on links that can gain programmed emphasis. Inaccessible to these users is any link that cannot gain programmatic focus.
• Similar to sighted people, screen reader users must know where a link leads. This information is provided via inner link text, albeit it will not be utilized if a screen reader cannot access it.
• Only the links and form components that can get programmatic focus can be activated by keyboard users, including those with visual impairments or those who cannot use a mouse. Keyboard users cannot access events activated only by other sorts of focus, such as onmouseover events that depend on the mouse hover focus. By default, only links and form elements receive keyboard emphasis. Add tabindex="0" to items that are not links or form components to make them focusable.

What this Accessibility Rule Checks

Ensures that each link’s name is accessible.

Elements of type <marquee> are prohibited because they are deprecated, add difficulty for users with limited dexterity, and distract users with cognitive or attention problems.

The marquee element produces difficult-to-read and-click-on scrolling text. Furthermore, it can be disturbing to viewers, particularly those with low eyesight, cognitive impairments, or concentration difficulties.

People with attention difficulties or cognitive impairments may be distracted by scrolling content. People with inadequate fine motor skills may not be able to precisely click on links inside scrolling content. Users with visual impairments may not be able to read the content of the scrolling text with sufficient clarity.

What this Accessibility Rule Checks

Prevents the use of the deprecated marquee element.

The document must not use <meta http-equiv="refresh"> with a refresh time of less than 20 hours, as this could prohibit users with disabilities from controlling when the page is refreshed.

Since consumers do not anticipate a page to immediately reload, this behavior might be unsettling. Reloading also returns the programmatic emphasis to the page’s top, away from where the user had it. Such resets are irritating to users.

Redirection and page refresh via the <meta> element are problematic for users with impairments in a number of ways. Redirects and refreshes are problematic for the primary reason that the user has no control over when they occur. If the objective of the <meta> element is to redirect the user to a new location, server-side rather than client-side procedures should be implemented. Moving or auto-updating content might be a hindrance for those who have problems reading stationary material fast and for those who have trouble monitoring moving objects. It can also present difficulties for screen readers.

What this Accessibility Rule Checks

Examines whether the http-equiv="refresh" attribute is present on meta elements with a content value of less than 20 hours.

Screen readers do not announce nested interactive controls.

Screen readers do not notify focusable components with interactive control ancestors (any element that accepts user input, such as buttons or anchor elements) and they produce an empty tab stop. In other words, even if you tab to the element, the screen reader won’t say its name, function, or status.

What this Accessibility Rule Checks

Ensure that no focusable child elements are present in any interactive controls.