Skip to main content
Accessibility AccessLint 0.16

Banner landmark should not be nested within another landmark.

About this AccessLint rule

The banner landmark identifies the site-oriented content at the top of a page, such as the site logo, title, and primary navigation. Screen reader users rely on landmarks to understand page structure and jump between major sections. When a banner landmark is nested inside another landmark like main, nav, article, aside, or section, it loses its meaning as a top-level region. Screen readers may not list it as a banner at all, or they may present a confusing hierarchy that makes it harder to navigate.

In HTML, a <header> element that is a direct child of <body> (not nested inside <article>, <aside>, <main>, <nav>, or <section>) automatically receives the banner role. When a <header> is placed inside one of these sectioning elements, the browser assigns it a generic role instead. Problems arise when a developer explicitly adds role="banner" to a header that is nested inside another landmark, creating a conflict between the DOM structure and the stated ARIA role.

This rule relates to WCAG 2.2 Success Criterion 1.3.1 (Info and Relationships), Level A, which requires that information and relationships conveyed through presentation are programmatically determinable. A misplaced banner landmark misrepresents the page structure, making the programmatic relationships inaccurate.

Who is affected

Screen reader users navigate pages by listing available landmarks. A banner nested inside main or another sectioning element creates a confusing or broken landmark tree. Instead of seeing a clear top-level banner, users may encounter an unexpected hierarchy or miss the banner entirely. This makes it harder to locate site-wide content like the logo or global navigation.

How to fix it

There are two approaches depending on the intent:

If the <header> is meant to be the site banner, move it outside of any sectioning landmark so it is a direct child of <body>. A <header> at the top level automatically receives the banner role without needing an explicit role="banner" attribute.

If the <header> is inside a sectioning element on purpose (for example, a header for an <article> or <section>), remove any explicit role="banner" from it. A header inside a sectioning element is just a local header for that section, not the page-level banner.

Examples

Incorrect: banner nested inside main

The role="banner" is explicitly set on a <header> inside <main>, which nests the banner landmark inside the main landmark.

<body>
<main>
<header role="banner">
<h1>My Website</h1>
<nav aria-label="Primary">
<a href="/">Home</a>
<a href="/about">About</a>
</nav>
</header>
<p>Page content goes here.</p>
</main>
</body>

Correct: banner as a top-level landmark

The <header> is a direct child of <body>, so it automatically has the banner role. No explicit role attribute is needed.

<body>
<header>
<h1>My Website</h1>
<nav aria-label="Primary">
<a href="/">Home</a>
<a href="/about">About</a>
</nav>
</header>
<main>
<p>Page content goes here.</p>
</main>
</body>

Correct: section header without banner role

When a <header> belongs to a specific <article>, it should not have role="banner". Omitting the role lets the browser assign the correct generic role.

<body>
<header>
<a href="/">My Website</a>
</header>
<main>
<article>
<header>
<h2>Article title</h2>
<p>Published on January 5, 2024</p>
</header>
<p>Article content goes here.</p>
</article>
</main>
</body>

In this example, the outer <header> is the page banner and the inner <header> is scoped to its <article>. Neither needs an explicit role attribute because the browser determines the correct role based on context.

Detect accessibility issues automatically

Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.

Help us improve our guides

Was this guide helpful?
๐ŸŒ Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial โ†’

Join teams across 40+ countries