Accessibility Guides for sighted keyboard users

When a web page uses CSS media queries like @media (orientation: portrait) or @media (orientation: landscape) to force content into a single orientation, it prevents the page from responding to the user’s actual device position. This is checked by the axe rule css-orientation-lock.

Why this matters

Many users physically cannot rotate their devices. People with mobility impairments may have their phone or tablet mounted to a wheelchair, bed, or desk in a fixed orientation. Users with low vision may prefer landscape mode to enlarge text, while others may find portrait easier to read. Locking orientation removes their ability to choose what works best for them.

Beyond motor and vision disabilities, orientation locking also affects users with cognitive disabilities and dyslexia who may rely on a particular layout for readability. Sighted keyboard users who use external displays or stands may also be impacted.

This rule relates to WCAG 2.1 Success Criterion 1.3.4: Orientation (Level AA), which requires that content not restrict its view and operation to a single display orientation unless a specific orientation is essential. Essential use cases are rare — examples include a piano keyboard app, a bank check deposit interface, or a presentation slide display where the orientation is integral to the functionality.

How to fix it

1. Remove orientation-locking CSS. Look for @media queries that use the orientation feature combined with styles that effectively hide or completely rearrange content for only one orientation (e.g., setting display: none or width: 0 on the body or main content).
2. Use responsive design instead. Rather than checking orientation, use min-width or max-width media queries to adapt your layout to available space. This naturally accommodates both orientations.
3. Test in both orientations. Rotate your device or use browser developer tools to simulate both portrait and landscape modes. Verify that all content remains visible and functional.
4. Only lock orientation when essential. If your application genuinely requires a specific orientation for core functionality (not just aesthetic preference), document the rationale. This is the only valid exception.

Examples

Incorrect: Locking content to portrait only

This CSS hides the main content area when the device is in landscape orientation, effectively forcing users to use portrait mode:

<style>
  @media (orientation: landscape) {
    .content {
      display: none;
    }
    .rotate-message {
      display: block;
    }
  }
  @media (orientation: portrait) {
    .rotate-message {
      display: none;
    }
  }
</style>

<div class="content">
  <h1>Welcome to our site</h1>
  <p>This content is only visible in portrait mode.</p>
</div>
<div class="rotate-message">
  <p>Please rotate your device to portrait mode.</p>
</div>

Incorrect: Using transform to force portrait layout in landscape

<style>
  @media (orientation: landscape) {
    body {
      transform: rotate(-90deg);
      transform-origin: top left;
      width: 100vh;
      height: 100vw;
      overflow: hidden;
      position: absolute;
    }
  }
</style>

This forcibly rotates the entire page, fighting against the user’s chosen orientation and creating a confusing, inaccessible experience.

Correct: Responsive layout that works in both orientations

<style>
  .content {
    padding: 1rem;
  }
  .grid {
    display: grid;
    grid-template-columns: 1fr;
    gap: 1rem;
  }
  @media (min-width: 600px) {
    .grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>

<div class="content">
  <h1>Welcome to our site</h1>
  <div class="grid">
    <div>
      <p>Column one content.</p>
    </div>
    <div>
      <p>Column two content.</p>
    </div>
  </div>
</div>

This approach uses min-width instead of orientation, adapting the layout based on available space. The content remains fully accessible and readable whether the device is held in portrait or landscape.

Correct: Using orientation queries for minor style adjustments (not locking)

<style>
  .hero-image {
    width: 100%;
    height: 200px;
    object-fit: cover;
  }
  @media (orientation: landscape) {
    .hero-image {
      height: 300px;
    }
  }
</style>

<img class="hero-image" src="hero.jpg" alt="A scenic mountain landscape">

Using orientation media queries is acceptable when you’re making minor visual adjustments without hiding or restricting access to content. The key is that all content and functionality remain available in both orientations.

Why This Matters

Web pages often embed content using iframe or frame elements — for ads, third-party widgets, embedded forms, video players, or even internal application components. Each frame is essentially its own document with its own DOM. If axe-core is not running inside those frames, any accessibility violations within them go completely undetected.

This is classified as a critical user impact issue — not because the frame itself is inaccessible, but because undetected violations inside frames can affect all users with disabilities. Blind users relying on screen readers, sighted keyboard-only users, and deafblind users could all encounter barriers hidden within untested frame content. Missing form labels, broken focus management, insufficient color contrast, or missing alternative text inside frames would remain invisible to your testing process.

This rule is a Deque best practice rather than a specific WCAG success criterion. However, the violations that go undetected inside untested frames can relate to numerous WCAG criteria, including 1.1.1 (Non-text Content), 1.3.1 (Info and Relationships), 2.1.1 (Keyboard), 2.4.3 (Focus Order), 4.1.2 (Name, Role, Value), and many others. Comprehensive accessibility testing requires that all content on a page is analyzed, including content within frames.

How the Rule Works

When the iframes configuration property is set to true, axe-core attempts to run inside every iframe and frame element on the page. The rule uses both frame and iframe selectors to check whether the axe-core script is present in each frame’s document. If axe-core is not found inside a frame, the rule returns a “needs review” result for that element.

The rule operates at the page level — meaning results from nodes across different frames are combined into a single result when the entire page is tested. An optional after function processes results from all frames together.

How to Fix It

There are several approaches to ensure frames are properly tested:

1. Use axe-core’s built-in iframe support. When running axe-core programmatically, set the iframes option to true (this is the default). axe-core will automatically attempt to communicate with frames to gather results — but the axe-core script must be present in each frame for this to work.

2. Inject axe-core into all frames. If you control the frame content, include the axe-core script in those documents. If you’re using a testing framework like Selenium, Puppeteer, or Playwright, inject the axe-core script into each frame before running the analysis.

3. Use axe DevTools browser extension. The axe DevTools extension handles frame injection automatically in most cases, making it the simplest option for manual testing.

4. For third-party frames you don’t control, acknowledge that testing coverage is limited and consider testing the third-party content separately, or document it as an area requiring manual review.

Examples

Frame that triggers the issue

An iframe is present on the page, but axe-core is not loaded inside it. The content within the frame remains untested:

<main>
  <h1>Our Application</h1>
  <iframe src="https://example.com/embedded-form" title="Contact form"></iframe>
</main>

If https://example.com/embedded-form does not have axe-core loaded, axe will flag this frame as needing review.

Correct setup with axe-core injected

When using a testing tool like Playwright, ensure axe-core is injected into all frames:

const { AxeBuilder } = require('@axe-core/playwright');

// AxeBuilder automatically analyzes iframe content
const results = await new AxeBuilder({ page })
  .analyze();

Frame content that includes axe-core

If you control the frame source, include the axe-core script directly:

<!-- Content inside the iframe document -->

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Embedded Form</title>
  <script src="/vendor/axe-core/axe.min.js"></script>
</head>
<body>
  <form>
    <label for="email">Email address</label>
    <input type="email" id="email" name="email">
    <button type="submit">Subscribe</button>
  </form>
</body>
</html>

Properly structured frame on the parent page

Always ensure your frames have descriptive title attributes so users understand their purpose:

<iframe src="/embedded-form.html" title="Newsletter subscription form"></iframe>

This won’t fix the axe-core injection issue by itself, but it ensures the frame is accessible while you work on getting full test coverage inside it.

This rule is an informational check rather than a pass/fail test. It identifies elements whose content is hidden from both sighted users and assistive technologies, meaning automated tools like axe cannot inspect that content for issues. The goal is to ensure you don’t overlook potentially inaccessible content simply because it’s currently not visible.

Why this matters

When content is hidden using CSS properties like display: none or visibility: hidden, it is removed from the accessibility tree entirely. This means screen readers cannot access it, and automated testing tools cannot evaluate it. If that hidden content is later revealed — through user interaction, JavaScript toggling, or media queries — it must be fully accessible when it becomes visible.

Several groups of users can be affected by inaccessible hidden content:

• Screen reader users may encounter content that lacks proper labels, headings, or semantic structure once it’s revealed.
• Keyboard-only users may find that revealed content contains focus traps or elements that aren’t keyboard operable.
• Users with low vision or color blindness may encounter contrast or styling issues in content that was never tested because it was hidden during analysis.

If there’s a compelling reason to hide content from sighted users, there’s usually an equally compelling reason to hide it from screen reader users too. Conversely, when content is available to sighted users, it should also be available to assistive technology users.

This rule aligns with Deque best practices for thorough accessibility testing. While it doesn’t map to a specific WCAG success criterion, failing to review hidden content could mask violations of criteria like 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 2.1.1 Keyboard, 4.1.2 Name, Role, Value, and many others.

How to fix it

When axe flags hidden content, you need to:

1. Identify the hidden elements reported by the rule.
2. Trigger their display — interact with the page to make the content visible (e.g., open a modal, expand an accordion, hover over a tooltip).
3. Run accessibility checks again on the now-visible content.
4. Fix any issues found in that content, just as you would for any visible element.
5. Verify hiding technique is appropriate — make sure content hidden with display: none or visibility: hidden is truly meant to be hidden from all users, including assistive technology users.

If you intend content to be visually hidden but still accessible to screen readers, use a visually-hidden CSS technique instead of display: none or visibility: hidden.

Examples

Hidden content that cannot be analyzed

This content is completely hidden from all users and automated tools:

<div style="display: none;">
  <img src="chart.png">
  <p>Quarterly revenue increased by 15%.</p>
</div>

The img element inside may be missing an alt attribute, but axe cannot detect this because the entire div is hidden. You must reveal this content and test it separately.

Hidden content revealed for testing and fixed

Once the content is made visible, you can identify and fix issues:

<div style="display: block;">
  <img src="chart.png" alt="Bar chart showing quarterly revenue increased by 15%">
  <p>Quarterly revenue increased by 15%.</p>
</div>

Using visibility: hidden

<nav style="visibility: hidden;">
  <a href="/home">Home</a>
  <a href="/about">About</a>
</nav>

This navigation is hidden from everyone. If it becomes visible through a JavaScript interaction, ensure it is tested in that visible state.

Visually hidden but accessible to screen readers

If you want content hidden visually but still available to assistive technologies, don’t use display: none or visibility: hidden. Use a visually-hidden class instead:

<style>
  .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;
  }
</style>

<button>
<!-- icon -->
</svg>
  <span class="visually-hidden">Close menu</span>
</button>

This approach keeps the text accessible to screen readers while hiding it visually. Axe can still analyze this content because it remains in the accessibility tree.

Interactive content that toggles visibility

When content is toggled dynamically, make sure both states are tested:

<button aria-expanded="false" aria-controls="panel1">Show details</button>
<div id="panel1" style="display: none;">
  <p>Additional product details go here.</p>
</div>

<script>
  const button = document.querySelector('button');
  const panel = document.getElementById('panel1');
  button.addEventListener('click', () => {
    const expanded = button.getAttribute('aria-expanded') === 'true';
    button.setAttribute('aria-expanded', String(!expanded));
    panel.style.display = expanded ? 'none' : 'block';
  });
</script>

To fully test this, click the button to reveal the panel content, then run your accessibility analysis again to check the revealed content for any violations.

Landmark regions are structural areas of a page — like <main>, <nav>, <header>, <footer>, and <aside> — that help assistive technology users understand the layout and quickly navigate between sections. Screen readers provide shortcut keys that let users jump directly to these landmarks, making it easy to skip to the content they need.

The <aside> element (or role="complementary") represents content that supplements the main content, such as sidebars, related links, or additional context. When an <aside> is nested inside another landmark like <main> or <nav>, screen readers may not expose it as a top-level landmark. This means users who rely on landmark navigation may not be able to discover or jump to that complementary content at all, effectively hiding it from their navigation flow.

This issue primarily affects screen reader users, who depend on landmarks as a primary way to orient themselves and move through a page. When landmarks are improperly nested, the page structure becomes confusing or incomplete, reducing the efficiency and usability of assistive technology.

This rule relates to WCAG 2.1 Success Criterion 1.3.1 (Info and Relationships), which requires that information, structure, and relationships conveyed visually are also available programmatically. It also supports WCAG 2.1 Success Criterion 4.1.2 (Name, Role, Value) and the general best practice of using landmarks correctly so that assistive technologies can present content structure accurately.

How to Fix It

1. Move <aside> elements to the top level of the document body, outside of <main>, <nav>, <header>, <footer>, or any other landmark.
2. Check for role="complementary" on any elements and ensure they are also placed at the top level, not nested inside another landmark.
3. If the content truly belongs inside another landmark and is not meant to be independently navigable, consider whether it actually needs to be an <aside> at all. A simple <div> or <section> without a landmark role may be more appropriate.

Examples

Incorrect: <aside> nested inside <main>

<main>
  <h1>Article Title</h1>
  <p>Main article content goes here.</p>

  <aside>
    <h2>Related Links</h2>
    <ul>
      <li><a href="/topic-a">Topic A</a></li>
      <li><a href="/topic-b">Topic B</a></li>
    </ul>
  </aside>
</main>

In this example, the <aside> is inside <main>, so screen readers may not list it as a top-level landmark. Users navigating by landmarks could miss the related links entirely.

Correct: <aside> at the top level alongside <main>

<main>
  <h1>Article Title</h1>
  <p>Main article content goes here.</p>
</main>

<aside>
  <h2>Related Links</h2>
  <ul>
    <li><a href="/topic-a">Topic A</a></li>
    <li><a href="/topic-b">Topic B</a></li>
  </ul>
</aside>

Now the <aside> is a sibling of <main>, making it a top-level landmark that screen reader users can easily discover and navigate to.

Incorrect: role="complementary" nested inside <nav>

<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
  <div role="complementary">
    <p>Navigation tip: Use keyboard shortcuts to browse faster.</p>
  </div>
</nav>

Correct: role="complementary" moved to the top level

<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

<div role="complementary" aria-label="Navigation tips">
  <p>Navigation tip: Use keyboard shortcuts to browse faster.</p>
</div>

By keeping complementary landmarks at the top level of the page, you ensure all users — including those using assistive technology — can discover and navigate to every section of your content.

Landmarks are one of the primary ways screen reader users orient themselves on a page and navigate between major sections. The contentinfo landmark is specifically intended to hold site-wide footer information — copyright notices, privacy policies, contact links, and similar content. Screen readers like JAWS, NVDA, and VoiceOver provide shortcut keys that let users jump directly to landmarks by role.

When a contentinfo landmark is nested inside another landmark (such as main or navigation), it no longer appears as a top-level landmark in the screen reader’s landmark list. This means blind and deafblind users may not be able to find the footer information efficiently, or they may encounter it unexpectedly while navigating a different section of the page. The organizational benefit of landmarks is undermined when they are improperly nested.

This rule is a Deque best practice aligned with the broader principles of proper landmark usage recommended by the W3C’s ARIA Landmarks specification. While not mapped to a specific WCAG success criterion, correct landmark structure supports WCAG 1.3.1 (Info and Relationships), WCAG 2.4.1 (Bypass Blocks), and the overall goal of providing a clear, navigable document structure.

How to Fix It

1. Locate your contentinfo landmark. This is either a <footer> element that is a direct child of <body> (which implicitly has role="contentinfo") or any element with an explicit role="contentinfo".
2. Check its position in the DOM. If the contentinfo landmark is nested inside a <main>, <nav>, <aside>, <section>, <header>, or any element with a landmark role, it needs to be moved.
3. Move it to the top level. Restructure your HTML so the contentinfo landmark is a direct child of <body>, outside all other landmark regions.

Note that a <footer> element only has the implicit contentinfo role when it is scoped to the <body>. A <footer> nested inside an <article>, <section>, <aside>, <nav>, or <main> does not have the contentinfo role — it becomes a generic element. This means the issue typically arises when you explicitly add role="contentinfo" to a nested element, or when your page structure accidentally places the site-wide <footer> inside another landmark.

Examples

Incorrect: contentinfo Landmark Nested Inside main

<body>
  <main>
    <h1>Welcome</h1>
    <p>Page content goes here.</p>
    <footer>
      <p>&copy; 2024 Example Company</p>
    </footer>
  </main>
</body>

In this example, the <footer> is inside <main>, so it does not receive the implicit contentinfo role. If a developer tries to fix that by adding role="contentinfo" explicitly, the landmark becomes nested inside main, which triggers this rule:

<body>
  <main>
    <h1>Welcome</h1>
    <p>Page content goes here.</p>
    <div role="contentinfo">
      <p>&copy; 2024 Example Company</p>
    </div>
  </main>
</body>

Correct: contentinfo Landmark at the Top Level

<body>
  <main>
    <h1>Welcome</h1>
    <p>Page content goes here.</p>
  </main>
  <footer>
    <p>&copy; 2024 Example Company</p>
  </footer>
</body>

Here, the <footer> is a direct child of <body> and sits outside the <main> landmark. It automatically receives the implicit contentinfo role, and screen reader users can jump directly to it using landmark navigation.

Incorrect: Explicit role="contentinfo" Inside a region

<body>
  <main>
    <h1>Dashboard</h1>
  </main>
  <section aria-label="Additional info">
    <footer role="contentinfo">
      <p>Privacy Policy | Terms of Service</p>
    </footer>
  </section>
</body>

Correct: contentinfo Moved Outside the region

<body>
  <main>
    <h1>Dashboard</h1>
  </main>
  <footer>
    <p>Privacy Policy | Terms of Service</p>
  </footer>
</body>

The contentinfo landmark is now at the top level of the document, making it immediately discoverable through screen reader landmark navigation.

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:

1. 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".
2. 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

1. Identify all banner landmarks on your page. Look for top-level <header> elements and any element with role="banner".
2. Keep only one as the primary site-wide banner. This should be the header that contains your site logo, site name, or global navigation.
3. 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.
4. 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.

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

1. Audit your page for all elements that create a contentinfo landmark. Search for role="contentinfo" and for top-level <footer> elements.
2. Keep only one contentinfo landmark that represents the site-wide footer.
3. 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.
4. 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.

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:

1. 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.
2. If multiple landmarks share the same role, give each a unique accessible name using aria-label or aria-labelledby.
3. 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>

Screen reader users rely heavily on heading navigation to move efficiently through web pages. Most screen readers provide keyboard shortcuts (such as pressing H to jump to the next heading, or 1 to jump to the next h1) that let users skip directly to the main content. When a page lacks a level-one heading, these shortcuts fail, and users are forced to listen through navigation menus, banners, and other content before reaching what they came for.

This is fundamentally a problem of perceivability and navigability. Sighted users can glance at a page and instantly understand its layout — they see the large, bold title and know where the main content begins. Blind, low-vision, and deafblind users don’t have that option. For them, headings serve as a structural outline of the page. A well-organized heading hierarchy starting with an h1 gives these users an equivalent way to quickly grasp the page’s structure and jump to the content they need.

This rule is a Deque best practice and aligns with broader accessibility principles in WCAG, including Success Criterion 1.3.1 (Info and Relationships), which requires that structural information conveyed visually is also available programmatically, and Success Criterion 2.4.6 (Headings and Labels), which requires headings to be descriptive. While not a strict WCAG failure, the absence of an h1 has a moderate impact on usability for assistive technology users.

How to Fix It

1. Add a single h1 element at the beginning of your page’s main content. This heading should describe the primary topic or purpose of the page.
2. Use only one h1 per page. While HTML5 technically allows multiple h1 elements, best practice is to use a single h1 that represents the top-level topic.
3. Build a logical heading hierarchy. After the h1, use h2 for major sections, h3 for subsections within those, and so on. Don’t skip heading levels (e.g., jumping from h1 to h4).
4. Handle iframes carefully. If your page includes an iframe, the heading hierarchy inside that iframe should fit within the parent page’s heading structure. If the parent page already has an h1, the iframe content should start with h2 or lower, depending on where it sits in the hierarchy. When the iframe contains third-party content you can’t control, this may not always be possible, but it’s still the ideal approach.

What the Rule Checks

This rule verifies that the page (or at least one of its frames) contains at least one element matching either h1:not([role]) or [role="heading"][aria-level="1"].

Examples

Incorrect: Page with No Level-One Heading

This page jumps straight to h2 headings without ever establishing an h1. Screen reader users have no top-level heading to navigate to.

<body>
  <nav>
    <a href="/">Home</a>
    <a href="/about">About</a>
  </nav>
  <main>
    <h2>Welcome to Our Store</h2>
    <p>Browse our latest products below.</p>
    <h2>Featured Products</h2>
    <p>Check out what's new this week.</p>
  </main>
</body>

Correct: Page with a Level-One Heading

The h1 clearly identifies the page’s main topic and appears at the start of the main content. Subsections use h2.

<body>
  <nav>
    <a href="/">Home</a>
    <a href="/about">About</a>
  </nav>
  <main>
    <h1>Welcome to Our Store</h1>
    <p>Browse our latest products below.</p>
    <h2>Featured Products</h2>
    <p>Check out what's new this week.</p>
  </main>
</body>

Correct: Using ARIA to Create a Level-One Heading

If you can’t use a native h1 element, you can use the role="heading" and aria-level="1" attributes on another element. Native HTML headings are always preferred, but this approach is valid.

<main>
  <div role="heading" aria-level="1">Welcome to Our Store</div>
  <p>Browse our latest products below.</p>
</main>

Correct: Page with an Iframe That Fits the Heading Hierarchy

When embedding content in an iframe, the iframe’s heading structure should continue from the parent page’s hierarchy rather than introducing a second h1.

<!-- Parent page -->

<body>
  <main>
    <h1>Company Dashboard</h1>
    <h2>Recent Activity</h2>
    <iframe src="activity-feed.html" title="Activity feed"></iframe>
  </main>
</body>

<!-- activity-feed.html -->

<body>
  <h3>Today's Updates</h3>
  <p>Three new items were added.</p>
</body>