Accessibility

Accessibility Guides for deafblind

Learn how to identify and fix common accessibility issues flagged by Axe Core — so your pages are inclusive and usable for everyone. Also check our HTML Validation Guides.

Scan Your Site Free

Document should not have more than one banner landmark

Landmarks are structural markers that allow assistive technology users to quickly navigate to key sections of a page. Screen readers like JAWS, NVDA, and VoiceOver provide shortcut keys that let users jump directly to landmarks such as the banner, navigation, main content, and footer. When a page has more than one banner landmark, users encounter ambiguity — they can’t tell which banner is the primary site-wide header, defeating the purpose of landmark navigation.

This issue primarily affects blind users and deafblind users who rely on screen readers, as well as sighted keyboard users who may use browser extensions for landmark navigation. When landmarks are duplicated, these users must spend extra time sorting through repeated or redundant regions to find the content they need.

This rule is a Deque best practice for accessible landmark structure. While it doesn’t map to a specific WCAG success criterion, it directly supports the goals of WCAG 1.3.1 Info and Relationships and WCAG 2.4.1 Bypass Blocks by ensuring that the page structure is logical and navigable.

Understanding the Banner Landmark

A banner landmark represents the site-wide header — the region that typically contains the site logo, site name, global navigation, and search. There are two ways a banner landmark is created:

A <header> element that is a direct child of <body> (not nested inside <main>, <article>, <section>, <aside>, or <nav>) automatically has an implicit role="banner".
Any element with role="banner" explicitly assigned.

Although the HTML5 spec allows multiple <header> elements on a page, only a top-level <header> maps to the banner landmark role. A <header> nested inside an <article> or <section> does not become a banner landmark — it’s simply a header for that section. The confusion arises when developers place multiple <header> elements directly under <body>, or mix explicit role="banner" with a top-level <header>.

How to Fix It

Identify all banner landmarks on your page. Look for top-level <header> elements and any element with role="banner".
Keep only one as the primary site-wide banner. This should be the header that contains your site logo, site name, or global navigation.
Remove or restructure any additional banner landmarks:
- If you have extra <header> elements at the top level, nest them inside a sectioning element like <section> or <article> so they lose their implicit banner role.
- If you have extra role="banner" attributes, remove them.
Don’t use role="banner" on a <header> that is already a direct child of <body> — it’s redundant. Conversely, don’t add role="banner" to multiple elements.

Examples

Incorrect: Multiple Banner Landmarks

<body>
  <header>
    <h1>My Website</h1>
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
    </nav>
  </header>
  <header>
    <p>Welcome to the promotional section</p>
  </header>
  <main>
    <p>Page content here.</p>
  </main>
</body>

Both <header> elements are direct children of <body>, so both become banner landmarks. Screen readers will report two banners.

Incorrect: Mixing `role="banner"` with a Top-Level `<header>`

<body>
  <header>
    <h1>My Website</h1>
  </header>
  <div role="banner">
    <p>Site-wide announcement</p>
  </div>
  <main>
    <p>Page content here.</p>
  </main>
</body>

The <header> implicitly has role="banner", and the <div> explicitly has role="banner", resulting in two banner landmarks.

Correct: Single Banner Landmark

<body>
  <header>
    <h1>My Website</h1>
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
    </nav>
  </header>
  <main>
    <article>
      <header>
        <h2>Article Title</h2>
        <p>Published on January 1, 2025</p>
      </header>
      <p>Article content here.</p>
    </article>
  </main>
</body>

Only the first <header> is a direct child of <body> and maps to the banner landmark. The second <header> is nested inside <article>, so it does not create a banner landmark.

Correct: Using `role="banner"` on a Single Element

<body>
  <div role="banner">
    <h1>My Website</h1>
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
    </nav>
  </div>
  <main>
    <p>Page content here.</p>
  </main>
</body>

Only one element carries the banner role, so screen readers correctly identify a single banner landmark.

Document should not have more than one contentinfo landmark

Landmarks are one of the primary ways screen reader users orient themselves on a page. Tools like JAWS, NVDA, and VoiceOver allow users to pull up a list of landmarks and jump directly to any one of them. The contentinfo landmark typically contains information like copyright notices, privacy policies, and contact links that apply to the entire page. When multiple contentinfo landmarks exist, screen reader users encounter duplicate entries in their landmarks list and cannot tell which one is the actual page footer. This creates confusion and slows down navigation.

The contentinfo landmark is generated in two ways: by adding role="contentinfo" to an element, or by using a <footer> element that is a direct child of <body> (or not nested inside <article>, <aside>, <main>, <nav>, or <section>). A <footer> nested inside one of those sectioning elements does not map to the contentinfo role, so it won’t trigger this issue. However, role="contentinfo" explicitly applied to any element will always create a contentinfo landmark regardless of nesting.

Who is affected

Screen reader users (blind and deafblind users) rely on landmark navigation to move efficiently through a page. Duplicate contentinfo landmarks clutter the landmarks list and make it harder to find the real page footer.
Sighted keyboard users who use browser extensions or assistive tools for landmark-based navigation are also affected.

Related standards

This rule is a Deque best practice. While not mapped to a specific WCAG success criterion, it supports the principles behind WCAG 1.3.1 Info and Relationships and WCAG 2.4.1 Bypass Blocks, which emphasize correct semantic structure and efficient navigation. The ARIA specification itself states that role="banner", role="main", and role="contentinfo" should each be used only once per page.

How to fix it

Audit your page for all elements that create a contentinfo landmark. Search for role="contentinfo" and for top-level <footer> elements.
Keep only one contentinfo landmark that represents the site-wide footer.
If you need footer-like content inside articles or sections, use <footer> nested within <article>, <section>, or <main> — these do not create a contentinfo landmark.
Remove any extra role="contentinfo" attributes from elements that are not the page-level footer.

Examples

Bad example: multiple `contentinfo` landmarks

In this example, role="contentinfo" is used on two separate elements, creating duplicate contentinfo landmarks. The <footer> at the bottom also creates a third one since it is a direct child of <body>.

<header>Visit Your Local Zoo!</header>

<main>
  <h1>The Nature of the Zoo</h1>
  <article>
    <h2>In the Zoo: From Wild to Tamed</h2>
    <p>What you see in the zoo are examples of inborn traits left undeveloped.</p>
    <div role="contentinfo">
      <p>Article metadata here</p>
    </div>
  </article>
  <article>
    <h2>Feeding Frenzy: The Impact of Cohabitation</h2>
    <p>Some animals naturally group together with their own kind.</p>
    <div role="contentinfo">
      <p>Article metadata here</p>
    </div>
  </article>
</main>

<footer>
  <p>Brought to you by North American Zoo Partnership</p>
</footer>

Good example: single `contentinfo` landmark

Here, role="contentinfo" is used exactly once for the page footer. Article-level footers use <footer> nested inside <article>, which does not create a contentinfo landmark.

<div role="banner">
  <p>Visit Your Local Zoo!</p>
</div>

<div role="main">
  <h1>The Nature of the Zoo</h1>
  <article>
    <h2>In the Zoo: From Wild to Tamed</h2>
    <p>What you see in the zoo are examples of inborn traits left undeveloped.</p>
    <footer>
      <p>Article metadata here</p>
    </footer>
  </article>
  <article>
    <h2>Feeding Frenzy: The Impact of Cohabitation</h2>
    <p>Some animals naturally group together with their own kind.</p>
    <footer>
      <p>Article metadata here</p>
    </footer>
  </article>
</div>

<div role="contentinfo">
  <p>Brought to you by North American Zoo Partnership</p>
</div>

Good example: using semantic HTML5 elements

This version uses HTML5 semantic elements. The single top-level <footer> maps to the contentinfo role. The <footer> elements inside each <article> do not.

<header>
  <p>Visit Your Local Zoo!</p>
</header>

<main>
  <h1>The Nature of the Zoo</h1>
  <article>
    <h2>In the Zoo: From Wild to Tamed</h2>
    <p>What you see in the zoo are examples of inborn traits left undeveloped.</p>
    <footer>
      <p>Article metadata here</p>
    </footer>
  </article>
  <article>
    <h2>Feeding Frenzy: The Impact of Cohabitation</h2>
    <p>Some animals naturally group together with their own kind.</p>
    <footer>
      <p>Article metadata here</p>
    </footer>
  </article>
</main>

<footer>
  <p>Brought to you by North American Zoo Partnership</p>
</footer>

What this rule checks

The axe-core rule landmark-no-duplicate-contentinfo finds all elements that map to the contentinfo landmark role, filters out any that don’t actually resolve to that role (such as <footer> elements nested inside sectioning elements), and verifies that only one contentinfo landmark remains on the page. If more than one is found, the rule reports a violation.

Document should not have more than one main landmark

Landmarks are semantic regions that help assistive technology users understand the structure of a page and jump between sections efficiently. The main landmark specifically identifies the primary content area — the unique content that distinguishes this page from others on the site. When multiple main landmarks exist, screen readers present all of them in the landmarks list, making it unclear which one contains the actual primary content.

This issue primarily affects blind and deafblind users who rely on screen readers, as well as keyboard-only users with mobility disabilities who use landmark-based navigation. Screen readers like JAWS, NVDA, and VoiceOver allow users to press a shortcut key to jump directly to the main landmark. If there are two or more main landmarks, the user must guess which is correct, defeating the purpose of this navigational aid.

While this rule is categorized as a Deque best practice rather than a specific WCAG success criterion violation, it strongly supports WCAG 1.3.1 (Info and Relationships) and WCAG 2.4.1 (Bypass Blocks). Properly structured landmarks help users understand page organization and skip repetitive content.

How to Fix It

Audit your page for duplicate main landmarks. Search your HTML for multiple <main> elements or multiple uses of role="main". Remember that a <main> element has an implicit role="main", so a <main> and a <div role="main"> on the same page creates a duplicate.
Consolidate into a single main landmark. Wrap all primary content in one <main> element and remove any others.
Check iframes. If your page contains <iframe> elements, ensure each iframe’s document also has at most one main landmark.
Use complementary landmarks for other sections. Content that is not the primary focus — such as sidebars — should use <aside> (or role="complementary") instead of <main>.

It’s also a good practice to structure your entire page with semantic HTML5 landmark elements — <header>, <nav>, <main>, and <footer> — so all content is contained within a recognizable region. You can pair these with their ARIA equivalents (role="banner", role="navigation", role="main", role="contentinfo") for maximum compatibility across screen readers, though modern browsers and assistive technologies handle the HTML5 elements well on their own.

Examples

Incorrect: Multiple `main` Landmarks

This page has two main landmarks, which makes it ambiguous for screen reader users.

<header>
  <h1>My Website</h1>
</header>
<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>
<main>
  <h2>Articles</h2>
  <p>Article content here.</p>
</main>
<main>
  <h2>Sidebar</h2>
  <p>Related links and info.</p>
</main>
<footer>
  <p>&copy; 2024 My Website</p>
</footer>

Incorrect: Mixing `<main>` with `role="main"`

Even though these are different elements, both create a main landmark, resulting in duplicates.

<main>
  <p>Primary content here.</p>
</main>
<div role="main">
  <p>More content here.</p>
</div>

Correct: Single `main` Landmark with Proper Page Structure

All primary content is in one <main> element, and the sidebar uses <aside> instead.

<header>
  <h1>My Website</h1>
</header>
<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>
<main>
  <h2>Articles</h2>
  <p>Article content here.</p>
</main>
<aside>
  <h2>Sidebar</h2>
  <p>Related links and info.</p>
</aside>
<footer>
  <p>&copy; 2024 My Website</p>
</footer>

Correct: Page with an Iframe

The parent page and the iframe document each have at most one main landmark.

<!-- Parent page -->

<main>
  <h1>Dashboard</h1>
  <iframe src="widget.html" title="Statistics widget"></iframe>
</main>

<!-- widget.html -->

<main>
  <p>Widget content here.</p>
</main>

Document should have one main landmark

Landmarks are structural regions of a page — like header, navigation, main content, and footer — that assistive technologies use to build an outline of the page. When a screen reader user opens a page, they can pull up a list of landmarks and jump directly to the section they need. Without a main landmark, there is no way for these users to skip past repeated headers and navigation to reach the content they came for. This makes the page significantly harder to use.

This rule is a Deque best practice aligned with the WAI-ARIA technique ARIA11: Using ARIA landmarks to identify regions of a page. Users who are blind, deafblind, or who have mobility impairments and rely on screen readers or alternative navigation methods are the most directly affected. Without landmarks, these users must tab or arrow through every element on the page to find the content they need.

How landmarks work

HTML5 introduced semantic elements that automatically create landmark regions:

HTML5 Element	Implicit ARIA Role
`<header>`	`role="banner"`
`<nav>`	`role="navigation"`
`<main>`	`role="main"`
`<footer>`	`role="contentinfo"`
`<aside>`	`role="complementary"`

Modern browsers and screen readers understand these HTML5 elements natively. For maximum compatibility, you can also add the explicit ARIA role alongside the HTML5 element (e.g., <main role="main">). This redundancy is harmless and can help with older assistive technologies.

How to fix the problem

Wrap your primary content in a <main> element. Every page should have exactly one <main> landmark.
Place all other visible content inside appropriate landmarks. Use <header>, <nav>, <footer>, and <aside> as needed so that no content is orphaned outside a landmark region.
Check iframe elements. If an iframe contains landmarked content, it should have no more than one <main> landmark.
Don’t nest <main> elements. There should be only one <main> per page (or per iframe).

Note that landmarks primarily benefit screen reader users. Sighted users and screen magnifier users don’t perceive landmarks, so they still need visible skip-navigation links to bypass repeated content.

Examples

Incorrect: no `main` landmark

This page has no <main> element, so screen reader users have no way to jump directly to the primary content.

<header>
  <p>Company Logo</p>
</header>
<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>
<div class="content">
  <p>This is the primary content of the page.</p>
</div>
<footer>
  <p>&copy; 2024 Company Name</p>
</footer>

Correct: page with one `main` landmark

Replacing the generic <div> with a <main> element gives screen reader users a direct navigation point to the primary content.

<header>
  <p>Company Logo</p>
</header>
<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>
<main>
  <p>This is the primary content of the page.</p>
</main>
<footer>
  <p>&copy; 2024 Company Name</p>
</footer>

Correct: using both HTML5 elements and ARIA roles for maximum compatibility

<header role="banner">
  <p>Company Logo</p>
</header>
<nav role="navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>
<main role="main">
  <p>This is the primary content of the page.</p>
</main>
<footer role="contentinfo">
  <p>&copy; 2024 Company Name</p>
</footer>

Incorrect: multiple `main` landmarks

Having more than one <main> element confuses assistive technologies about which section is the true primary content.

<main>
  <p>Article content here.</p>
</main>
<main>
  <p>Sidebar content here.</p>
</main>

Correct: single `main` with an `aside` for secondary content

<main>
  <p>Article content here.</p>
</main>
<aside>
  <p>Sidebar content here.</p>
</aside>

Landmarks should have a unique role or role/label/title (i.e. accessible name) combination

HTML landmark elements like <header>, <nav>, <main>, <aside>, <form>, <section>, and <footer> — as well as elements with explicit ARIA landmark roles — create navigational waypoints that assistive technologies expose to users. Screen readers often provide a list of all landmarks on the page or allow users to jump between them using keyboard shortcuts. When two or more landmarks share the same role and have no accessible name (or share the same accessible name), they appear identical in that list. A user hearing “navigation” and “navigation” has no way of knowing whether the first is the site-wide menu and the second is a breadcrumb trail.

This issue primarily affects blind users, deafblind users, and sighted keyboard users who rely on assistive technology landmark navigation features. It is flagged as a Deque best practice rule. While it doesn’t map directly to a specific WCAG success criterion, it strongly supports the intent of WCAG 1.3.1 (Info and Relationships) and WCAG 2.4.1 (Bypass Blocks), which require that structural information is programmatically available and that users have mechanisms to navigate past repeated blocks of content.

How to Fix the Problem

The fix depends on whether you truly need multiple landmarks of the same type:

If only one landmark of a given role exists on the page, no additional labeling is needed — it’s already unique by its role alone.
If multiple landmarks share the same role, give each a unique accessible name using aria-label or aria-labelledby.
If duplicate landmarks aren’t necessary, consider removing or consolidating them.

When choosing accessible names, pick labels that clearly describe the purpose of each landmark, such as “Primary navigation,” “Footer navigation,” or “Search form.”

Examples

Incorrect: Duplicate `<nav>` landmarks with no accessible names

Screen reader users see two identical “navigation” landmarks with no way to tell them apart.

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

<nav>
  <a href="/terms">Terms</a>
  <a href="/privacy">Privacy</a>
</nav>

Correct: Duplicate `<nav>` landmarks with unique accessible names

Each landmark now has a distinct label that screen readers announce.

<nav aria-label="Main">
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

<nav aria-label="Footer">
  <a href="/terms">Terms</a>
  <a href="/privacy">Privacy</a>
</nav>

Incorrect: Two `<aside>` elements with the same `aria-label`

Even though labels are present, they are identical, so the landmarks are still indistinguishable.

<aside aria-label="Related content">
  <p>Popular articles</p>
</aside>

<aside aria-label="Related content">
  <p>Recommended products</p>
</aside>

Correct: Two `<aside>` elements with unique `aria-label` values

<aside aria-label="Popular articles">
  <p>Popular articles</p>
</aside>

<aside aria-label="Recommended products">
  <p>Recommended products</p>
</aside>

Correct: Using `aria-labelledby` to reference visible headings

If your landmarks already contain headings, you can point to those headings instead of duplicating text in aria-label.

<nav aria-labelledby="nav-main-heading">
  <h2 id="nav-main-heading">Main Menu</h2>
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

<nav aria-labelledby="nav-breadcrumb-heading">
  <h2 id="nav-breadcrumb-heading">Breadcrumb</h2>
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

Correct: Only one landmark of a given role — no label needed

When a landmark role appears only once on the page, it is inherently unique.

<header>
  <h1>My Website</h1>
</header>

<main>
  <p>Page content goes here.</p>
</main>

<footer>
  <p>&copy; 2024 My Website</p>
</footer>

Incorrect: Duplicate ARIA landmark roles without unique names

Using explicit ARIA roles doesn’t change the requirement — duplicates still need unique names.

<div role="complementary">
  <p>Sidebar content A</p>
</div>

<div role="complementary">
  <p>Sidebar content B</p>
</div>

Correct: Explicit ARIA landmark roles with unique accessible names

<div role="complementary" aria-label="Author bio">
  <p>Sidebar content A</p>
</div>

<div role="complementary" aria-label="Related links">
  <p>Sidebar content B</p>
</div>

Links must have discernible text

Links are one of the most fundamental interactive elements on the web. When a link lacks an accessible name, screen reader users hear something like “link” with no further context, making it impossible to understand the link’s purpose or destination. This affects people who are blind, deafblind, or have low vision and rely on screen readers, as well as keyboard-only users who navigate through links sequentially.

A link’s accessible name can come from several sources: its visible text content, an aria-label attribute, an aria-labelledby reference, a title attribute, or the alt text of an image contained within it. If none of these provide a non-empty string, the link has no discernible text, and this rule will flag it.

Beyond just having text, links must also be programmatically focusable. Avoid relying on device-specific JavaScript events like onmouseover or mouseout(), which are inaccessible to keyboard users. Use device-independent alternatives like onfocus, onblur, focus(), and blur(). Additionally, don’t hide link text from assistive technologies using display: none, visibility: hidden, or aria-hidden="true" on the link or its text content.

It’s also important to use semantic <a> elements with a valid href attribute rather than simulating links with <span> or <div> elements and click handlers. Real links are focusable by default and convey the correct role to assistive technologies.

Related WCAG Success Criteria

This rule relates to two Level A success criteria that apply across WCAG 2.0, 2.1, and 2.2:

WCAG 2.4.4 (Link Purpose in Context): Users must be able to determine the purpose of each link from the link text alone, or from the link text combined with its programmatically determined context.
WCAG 4.1.2 (Name, Role, Value): All user interface components, including links, must have an accessible name and role that can be programmatically determined.

This rule is also required under Section 508, EN 301 549, and Trusted Tester guidelines.

How to Fix It

Add visible text content inside the <a> element.
For image links, provide meaningful alt text on the <img> element.
Use aria-label when you need to provide an accessible name that differs from or supplements the visible text.
Use aria-labelledby to reference another element’s text as the link’s accessible name.
Don’t hide link text from screen readers with aria-hidden="true" or CSS that removes elements from the accessibility tree.
Ensure links are focusable by using proper <a> elements with href attributes and avoiding mouse-only event handlers.

Examples

Empty link (incorrect)

A link with no text or accessible name:

<a href="/settings"></a>

A link that only contains an image with no alt text:

<a href="/home">
  <img src="logo.png" alt="">
</a>

A link with its text hidden from assistive technologies:

<a href="/profile">
  <span aria-hidden="true">Profile</span>
</a>

Link with visible text (correct)

<a href="/settings">Settings</a>

Image link with descriptive alt text (correct)

<a href="/home">
  <img src="logo.png" alt="Homepage">
</a>

Link with `aria-label` (correct)

This is useful when multiple links share the same visible text, such as repeated “Read more” links:

<h3>Accessibility Updates</h3>
<p>New WCAG 2.2 guidelines have been published.
  <a href="/wcag22" aria-label="Read more about WCAG 2.2 updates">Read more</a>
</p>

<h3>Screen Reader Tips</h3>
<p>Learn how to navigate tables with a screen reader.
  <a href="/sr-tips" aria-label="Read more about screen reader tips">Read more</a>
</p>

Link with `aria-labelledby` (correct)

<h3 id="report-title">Annual Report 2024</h3>
<a href="/report-2024.pdf" aria-labelledby="report-title">Download PDF</a>

Icon link with visually hidden text (correct)

For links that use icons without visible text, use a visually hidden <span> to provide an accessible name:

<a href="/search">
  <svg aria-hidden="true" focusable="false">
    <use href="#icon-search"></use>
  </svg>
  <span class="visually-hidden">Search</span>
</a>

The visually-hidden class hides the text visually but keeps it available to screen readers:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Accessibility Guides for deafblind

Understanding the Banner Landmark

How to Fix It

Examples

Incorrect: Multiple Banner Landmarks

Incorrect: Mixing role="banner" with a Top-Level <header>

Correct: Single Banner Landmark

Correct: Using role="banner" on a Single Element

Who is affected

Related standards

How to fix it

Examples

Bad example: multiple contentinfo landmarks

Good example: single contentinfo landmark

Good example: using semantic HTML5 elements

What this rule checks

How to Fix It

Examples

Incorrect: Multiple main Landmarks

Incorrect: Mixing <main> with role="main"

Correct: Single main Landmark with Proper Page Structure

Correct: Page with an Iframe

How landmarks work

How to fix the problem

Examples

Incorrect: no main landmark

Correct: page with one main landmark

Correct: using both HTML5 elements and ARIA roles for maximum compatibility

Incorrect: multiple main landmarks

Correct: single main with an aside for secondary content

How to Fix the Problem

Examples

Incorrect: Duplicate <nav> landmarks with no accessible names

Correct: Duplicate <nav> landmarks with unique accessible names

Incorrect: Two <aside> elements with the same aria-label

Correct: Two <aside> elements with unique aria-label values

Correct: Using aria-labelledby to reference visible headings

Correct: Only one landmark of a given role — no label needed

Incorrect: Duplicate ARIA landmark roles without unique names

Correct: Explicit ARIA landmark roles with unique accessible names

Related WCAG Success Criteria

How to Fix It

Examples

Empty link (incorrect)

Link with visible text (correct)

Image link with descriptive alt text (correct)

Link with aria-label (correct)

Link with aria-labelledby (correct)

Icon link with visually hidden text (correct)

Incorrect: Mixing `role="banner"` with a Top-Level `<header>`

Correct: Using `role="banner"` on a Single Element

Bad example: multiple `contentinfo` landmarks

Good example: single `contentinfo` landmark

Incorrect: Multiple `main` Landmarks

Incorrect: Mixing `<main>` with `role="main"`

Correct: Single `main` Landmark with Proper Page Structure

Incorrect: no `main` landmark

Correct: page with one `main` landmark

Incorrect: multiple `main` landmarks

Correct: single `main` with an `aside` for secondary content

Incorrect: Duplicate `<nav>` landmarks with no accessible names

Correct: Duplicate `<nav>` landmarks with unique accessible names

Incorrect: Two `<aside>` elements with the same `aria-label`

Correct: Two `<aside>` elements with unique `aria-label` values

Correct: Using `aria-labelledby` to reference visible headings

Link with `aria-label` (correct)

Link with `aria-labelledby` (correct)