Accessibility Guides for sighted keyboard users

The screen orientation (such as portrait or landscape) of mobile applications should not be restricted to a single mode. Users should be able to shift the orientation of their device between portrait and landscape without losing readability. Additionally, upon opening a page, it should appear in the current orientation of the user.

Users of assistive technologies may not have access to orientation features on their devices or assistive technologies.

What this Accessibility Rule Checks

Unless a specific display orientation is important, content does not confine its view and functionality to a single display orientation, such as portrait or landscape.

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.

Notifies users of content that is hidden and unable to be checked for accessibility issues.

It is impossible to automatically check hidden content for accessibility rules breaches.

Screen reader users and sighted people must both be able to view visually hidden content. When content needs to be hidden from seeing users for a compelling reason, it is typically also necessary to hide it from blind users for the same reason. Making the content accessible to blind users makes sense when it is already available to sighted users.

When the CSS values display: none or visibility: hidden are used, content will be hidden from screen reader users (and all sighted users as well). The items become accessible to screen reader users when CSS properties are changed to display: block, display: inline, or other display values.

What this Accessibility Rule Checks

Checks for the presence of the hidden item content CSS style property values of display: none and visibility: hidden, and notifies users of their presence.

Ensures the complementary landmark or aside is at top level.

Complementary content is content that supports the primary idea of a page or document. Users of screen readers have the option to bypass supplemental content that shows at the accessibility API’s top level. Embedding an <aside> element within another landmark may prevent the ability for screen reader users to browse through supplemental content.

What this Accessibility Rule Checks

Do not insert <aside> elements or elements containing role="complementary" inside landmark-marked content.

The contentinfo landmark must be at top level.

Placement of the contentinfo landmark within another landmark can contradict its purpose by preventing blind screen reader users from rapidly locating and navigating to the intended landmark.

It defeats the purpose of an existing contentinfo landmark when screen reader users must wade through too much extra information to discover what they seek, such as not being able to quickly determine which landmark provides the content information they seek.

What this Accessibility Rule Checks

This rule locates the components corresponding to the footer:not([role]) and [role="contentinfo"] selectors, and then tests whether the landmark has a body context.

Ensures there is only one banner landmark at most on the page.

Landmarks enable blind people to navigate and rapidly locate content. In the absence of landmarks, screen reader users must wade through too much unnecessary information to locate anything.

JAWS, NVDA, and VoiceOver all support using ARIA landmarks to navigate to specific portions of a web page. Landmarks offer a more elegant answer to the challenge of offering a way for readers to bypass the page’s main content. There is no visible change to the website’s layout, making it inconspicuous and undetectable. Obviously, the fact that this technique is invisible is advantageous for users of screen readers, but not for sighted keyboard users or users of screen magnifiers with impaired eyesight. In this sense, HTML 5 regions and ARIA landmarks cannot replace the conventional “skip navigation” links just yet.

There is presently no method built into browsers to alert users when HTML 5 regions or ARIA landmarks are available. Users of screen readers are the only ones who can benefit from them. There is a Firefox ARIA landmark extension that provides landmark navigation to Firefox, however this is not a native browser capability.

What this Accessibility Rule Checks

This rule locates all banner landmarks, filters out those that do not correspond to their job, and checks that there is only one.

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.

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

landmark-unique is a new best practice rule ensuring that landmarks have an unique role or accessible name (i.e. role, label, title) combination.

What this Accessibility Rule Checks

Ensures landmarks are unique.

To enable screen reader users to navigate the heading structure with keyboard shortcuts rather than wasting time listening to more of the website to understand its structure, make sure the page, or at least one of its frames, contains a h1 element that appears before the start of the main content.

Users of screen readers can utilize keyboard keys to move straight to the first h1, which should, in theory, let them access the web page’s main content. Screen reader users must listen to more of the website in order to understand its structure if there is no h1 or if it appears elsewhere other than at the start of the main material, wasting significant time.

Keep in mind that unlike a visual user, a blind user cannot just glance at a web page and comprehend its layout. Without reading the entire material, visual users can learn a lot about the website layout. Users who are blind do not have such option. Unless there is another convenient way to gain a “glimpse,” screen readers read sequentially, which requires listening to the entire web page. It turns out that one method to do that is to use headers. Keyboard shortcuts can be used by screen reader users to move around a document’s heading hierarchy.

What this Accessibility Rule Checks

This rule locates every element that matches the subsequent selector and confirms that there is at least one of them: h1:not([role]), [role="heading"][aria-level="1"]