How to Verify Accessible HTML Landmarks

Verifying that accessible landmark elements are correctly mapped in HTML is critical for ensuring users of assistive technologies, such as screen readers, can efficiently navigate and understand a webpage's layout. Web development engineers validate these landmarks through a combination of browser developer tools, automated accessibility audits, browser extensions, and manual testing with screen readers. By confirming that native HTML5 elements correctly translate into Accessible Rich Internet Applications (ARIA) roles in the accessibility tree, engineers guarantee a seamless structural experience.

Inspecting the Browser Accessibility Tree

The primary method for checking landmark mappings is using the Accessibility panel within modern browser developer tools (such as Chrome DevTools, Firefox Developer Tools, or Safari Web Inspector).

  1. Open DevTools and navigate to the Elements or Inspector tab.
  2. Select the accessibility sub-panel to view the Accessibility Tree.
  3. Inspect key structural elements to verify their computed roles. For example:
    • <header> maps to role="banner" (when not inside a sectioning element like <article> or <section>).
    • <nav> maps to role="navigation".
    • <main> maps to role="main".
    • <footer> maps to role="contentinfo" (when at the page root level).
    • <aside> maps to role="complementary".
    • <section> or <form> maps to role="region" or role="form" when provided with an accessible name via aria-label or aria-labelledby.

If the computed role does not display the expected landmark role, the element may be nested incorrectly or suppressed by an invalid role override.

Running Automated Accessibility Scanners

Automated testing tools catch common structural mistakes, such as missing primary landmarks or duplicate landmarks lacking distinct labels.

  • Lighthouse and Axe Core: Run automated audits through the Chrome Lighthouse tab or the Axe browser extension. These tools flag missing <main> landmarks, orphaned content outside of landmarks, and duplicate landmarks that need unique aria-label attributes.
  • Linters and CI/CD Integrations: Incorporate tools such as eslint-plugin-jsx-a11y or automated testing suites (like Cypress or Playwright paired with @axe-core) to catch structural regressions before code reaches production.

Using Landmark Visualization Extensions

Specialized browser extensions provide visual overlays of all landmarks on a rendered page:

  • Landmarks Extension: Highlights all declared landmarks directly in the viewport, showing the nesting levels and labels.
  • Accessibility Insights for Web: Includes an automated "Ad-hoc tools" feature that draws borders around all landmarks and displays their assigned roles, making it easy to identify regions of the page that fall outside of any landmark.

Manual Validation with Screen Readers

The final step is manual verification using popular screen readers to ensure that the landmarks behave as expected during navigation.

  • NVDA (Windows): Press D to jump forward between landmarks, or press Insert + F7 to open the Elements List and select the "Landmarks" radio button to review all detected landmarks and their labels.
  • JAWS (Windows): Press R to cycle through regions/landmarks, or press Insert + F3 to view the list of landmarks.
  • VoiceOver (macOS/iOS): Open the VoiceOver Rotor using Control + Option + U (or a two-finger rotation on iOS), navigate to the "Landmarks" menu, and verify the full list of page regions.

During manual testing, verify that every significant area of the page is enclosed within an appropriate landmark, that there is only one top-level <main> element, and that multiple landmarks of the same type (such as primary and secondary <nav> elements) have unique, descriptive labels.