WCAG 1.3.1Level AWarningStructure

How to fix: Missing landmark regions

A page needs landmark regions, at minimum a <main> for its primary content and a <nav> for its navigation, so assistive technology can identify and jump directly to the major areas of the page.

What it is

Landmarks are the high-level regions of a page: the main content, the primary navigation, the banner header, and the footer. Native HTML elements like <main>, <nav>, <header>, and <footer> expose these regions to assistive technology automatically, and ARIA equivalents such as role="main" or role="navigation" do the same when you cannot use the native element. WCAG Success Criterion 1.3.1 Info and Relationships requires that this kind of structure be available in code, not just implied by layout.

The most important landmarks are <main> and <nav>. The <main> element wraps the unique, central content of the page (one per page), giving screen reader users a single keystroke to skip past the repeated header and menus straight to what they came for. The <nav> element marks a block of navigation links so users can find and move through the menu deliberately. When a page is built entirely from generic <div> and <span> wrappers, none of these regions exist for assistive technology, even though they are visually obvious.

The fix is to swap the generic wrappers for the right semantic elements: a <main> around the primary content, a <nav> around each navigation block, and ideally <header> and <footer> for the page banner and footer. Where you genuinely cannot change the tag, add the matching ARIA role instead. No visual change is required; landmarks are purely structural.

Who it affects & why it matters

Screen reader users benefit the most. Assistive technology offers a landmarks menu and shortcut keys to jump between regions, so a user can leap to the navigation, skip to the main content, or move to the footer in one step. Without landmarks, that whole navigation layer disappears and the user must tab through everything linearly, re-reading the same header and menu on every page.

Keyboard-only users gain a related benefit when a real <main> exists, since skip links and focus management can target it reliably. People with cognitive disabilities also benefit from a consistent, well-signposted structure. Landmarks add no visible change, so they improve the experience for assistive-tech users at zero cost to your visual design.

Missing landmarks relate to SC 1.3.1, a Level A criterion. AccessKnight reports it at warning severity rather than critical, because a page can still be used without landmarks, but their absence forces assistive-technology users into slow, linear navigation and removes a heavily relied-upon shortcut. Programmatic structure is a foundational part of WCAG, and WCAG 2.1 Level AA, which includes every Level A criterion, is the benchmark U.S. courts apply to ADA website claims.

Web accessibility lawsuits have risen sharply and most often target businesses under $25 million in revenue, and a thin, landmark-free page is a clear signal in any audit that semantic structure was skipped. Adding landmarks is one of the highest-leverage, lowest-risk fixes available: you are renaming wrappers to semantic elements, with no change to how the page looks.

How to fix it

Identify the primary content area of the page and wrap it in a single <main> element (only one per page).
Wrap each navigation block in a <nav> element, or add role="navigation" if you cannot change the tag.
Add <header> for the page banner and <footer> for the footer to round out the landmark set.
If you must keep a generic wrapper, apply the matching ARIA role (for example role="main") instead.
Avoid burying real content outside any landmark, and re-scan to confirm both a main and a nav region are present.

Before

<div class="header">...</div>
<div class="menu">
  <a href="/">Home</a>
</div>
<div class="content">...</div>

After

<header>...</header>
<nav>
  <a href="/">Home</a>
</nav>
<main>...</main>

How AccessKnight detects this

AccessKnight runs two page-level checks. It looks for a <main> element or any element with role="main"; if none exists, it flags the page and recommends adding a <main> element. Separately, it looks for a <nav> element or any element with role="navigation"; if none exists, it flags the page and recommends adding a <nav> element. A page can therefore produce up to two findings under this rule. Supplying the missing semantic landmark element (or its ARIA-role equivalent) clears the corresponding finding.

Frequently asked questions

Is missing landmarks a Level A or AA issue?

It relates to WCAG 2.1 Success Criterion 1.3.1 Info and Relationships, which is Level A. AccessKnight reports it at warning severity because the page remains usable without landmarks, but their absence meaningfully slows down navigation for screen reader users.

What landmarks does AccessKnight actually check for?

This rule checks specifically for a main landmark (a <main> element or role="main") and a navigation landmark (a <nav> element or role="navigation"). Adding <header> and <footer> is good practice and rounds out your landmark structure, but the two findings this rule can raise are about the missing main and nav regions.

Can I use ARIA roles instead of the HTML5 elements?

Yes. role="main" satisfies the main-landmark check and role="navigation" satisfies the nav-landmark check, so they are valid fallbacks. Prefer the native <main> and <nav> elements when you can, since they carry the role automatically and need no extra attribute, and only reach for the ARIA role when changing the tag is not possible.

How many <main> elements should a page have?

Exactly one. The <main> element is meant to wrap the single, unique primary content area of the page, so screen reader users can jump straight to it. Repeated headers, sidebars, and navigation should live outside <main>, in their own landmarks like <nav>, <header>, and <footer>.