Understand the page structure a screen reader can navigate
Landmarks describe the major purpose of a page area rather than the topic of every paragraph. A <main> element identifies the central content, <nav> identifies navigation links, and a top-level <header> generally provides a banner landmark. A screen-reader user can often open a landmarks list and jump to a chosen region directly.
Know which HTML elements create landmark roles
Modern semantic HTML usually supplies the required roles without extra role attributes. The mapping below describes typical behavior in the correct document context.
Context matters. A <header> inside an <article> is normally an article header, not a second page banner. Similarly, a <footer> inside an article is not usually the site’s contentinfo landmark. A plain <section> does not automatically become a named region, and a form without an accessible name does not automatically supply a form landmark.
Inspect the whole page, not just one component
For a meaningful page-level review, the markup must include the site layout as well as the content. Checking only a copied article fragment can produce a missing-main warning even when the live template supplies <main> around that fragment. Conversely, a fragment can look correct while the full page creates a second main area through a popup, embedded template, or theme wrapper.
Use whichever input method the checker actually provides. If checking a pasted snippet, be clear whether it represents an entire document or an isolated component. If the interface accepts URLs, remember that client-rendered content, authentication, blocked requests, and interactive states may not be visible to a simple server-side fetch. Use the browser’s rendered DOM to investigate any difference between source code and what users encounter.
Look for a clear main area and a sensible landmark hierarchy
Most ordinary webpages should have a single active <main> landmark identifying the primary content. It belongs near the top level of the page structure, rather than inside navigation, a sidebar, or another landmark. If several main regions are exposed in the same document, users may struggle to know which one represents the page’s primary destination. Some specialized document structures allow multiple uniquely named main landmarks, but a single clear main area is the sensible default.
Give repeated navigation landmarks distinguishable names
It is common to have a primary menu, breadcrumbs, and footer navigation on the same page. Each can correctly use <nav>, but different navigation areas need accessible names that communicate their function. Use visible headings with aria-labelledby where possible, or a concise aria-label when no suitable visible label exists.
<nav aria-label="Primary">
<a href="/services/">Services</a>
<a href="/contact/">Contact</a>
</nav>
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">Home</a></li>
<li>Current page</li>
</ol>
</nav>
Do not add the word “navigation” to every accessible label; screen readers already announce the landmark role. For identical menus repeated in different locations, a consistent label may be more informative than arbitrarily inventing two names. Review whether the labels distinguish genuinely different purposes, not merely different positions on the screen.
Compare a confusing layout with a semantic alternative
A layout built entirely from generic <div> elements may be visually polished but convey no landmark structure. The first example uses visual class names that, by themselves, have no landmark meaning:
<div class="site-header">Site identity</div>
<div class="main-menu">Navigation links</div>
<div class="content">Page article</div>
<div class="site-footer">Footer links</div>
When those areas actually perform the expected functions, their semantic counterparts express the structure more clearly:
<header>Site identity</header>
<nav aria-label="Primary">Navigation links</nav>
<main id="main-content">Page article</main>
<footer>Footer links</footer>
These are simplified structural illustrations, not complete publishable page templates. In real markup, links need meaningful destinations, headings should describe the content, and interactive elements must work. A developer can also provide equivalent landmarks with suitable ARIA roles where native elements cannot be used, but native HTML is generally easier to maintain.
Handle search, forms, and named regions carefully
A search field does not establish a search landmark merely because its input type is search. Group the search interface in a <search> element or use role="search" on the enclosing form where appropriate. If a page has site search and product filtering, give each distinct search region a useful name. Avoid stacking redundant search roles on a parent and its child.
Named <form> and <section> elements can become form and region landmarks. That is useful for prominent sections, but not every contact fieldset, card, or article subsection deserves its own landmark. Too many regions make the landmarks list harder to scan. Use headings for normal subsections and reserve landmarks for areas users are likely to navigate to directly.
Check the referenced heading when using aria-labelledby: it should exist in the same relevant document, have a unique ID, and provide a meaningful label. You can inspect broader naming mistakes with the ARIA Attribute Checker and related form labels with the Form Label Checker.
Recognize warnings that need human judgment
A reported “missing landmark” could indicate a structural mistake, or it could reflect an incomplete snippet. An apparent duplicate navigation landmark may be intentional if its purpose is distinct and clearly named. An unlabeled navigation region is not necessarily invalid when it is the only navigation landmark, although useful labels become much more important when there are several.
Review WordPress themes and dynamic layouts
WordPress templates may provide landmarks outside the post editor. A theme can wrap the whole post in <main>, while a page builder independently inserts another main region. Check the rendered page before adding a second landmark to content blocks. Theme headers, reusable navigation patterns, sidebars, search overlays, and footer builders are common places to inspect.
For structural issues introduced by JavaScript, compare the initial and rendered markup with the Source vs Rendered HTML Comparison. For the information hierarchy inside the main region, use the Heading Structure Checker.
Test the result with real keyboard and screen-reader navigation
- Inspect the rendered page: Confirm that the expected landmarks exist in the accessibility tree, not only as visual wrappers or class names.
- Open the screen reader’s landmarks list: Check whether the main area, navigation, and supporting regions are easy to recognize by role and name.
- Try the skip link: If your site provides a “Skip to content” control, confirm it moves focus or the reading position appropriately to the main content.
- Test responsive and interactive states: Open menus and overlays, then verify that landmarks exposed to assistive technology match what is currently relevant.
- Review alongside other checks: A correct landmark hierarchy does not guarantee good link text, form labels, focus visibility, or overall WCAG conformance.
The goal is navigation that makes sense to people, not a particular landmark count. W3C’s design guidance recommends keeping landmark regions relatively few and assigning them according to page purpose; that guidance is not a universal numerical pass/fail threshold.
Frequently asked questions about HTML landmarks
Does every webpage need a main landmark?
For ordinary content pages, providing one clear main landmark is a strong accessibility practice. It helps assistive technology users identify the primary content quickly. Examine unusual document and application structures individually.
Should I add role="navigation" to <nav>?
Usually not. The native element already exposes the navigation role in modern browsers. Add accessible names when they help distinguish multiple navigation areas, rather than repeating the element’s implied role.
Is a header inside an article another banner landmark?
Generally no. A header within an article or another qualifying sectioning context serves that content area; it does not normally represent the page-wide banner.
Can a successful landmark check prove WCAG compliance?
No. Landmarks cover only part of accessibility. You must also review relevant WCAG success criteria, keyboard access, visual presentation, form behavior, and real assistive-technology use.
