Skip to main content
Accessibility AccessLint 0.16

Page should not have more than one contentinfo landmark.

About this AccessLint rule

The contentinfo landmark identifies a region that contains information about the page or site, such as copyright notices, privacy policies, and contact details. In HTML, the <footer> element automatically receives the contentinfo role when it is a direct child of the <body> element (or not nested inside a sectioning element like <article>, <aside>, <main>, <nav>, or <section>). A page must have no more than one top-level contentinfo landmark.

When a page contains multiple contentinfo landmarks at the top level, screen reader users lose the ability to quickly and reliably navigate to the site's footer information. Screen readers provide shortcut keys to jump between landmark regions, and landmarks work best when each type appears only once at the top level, giving users a predictable page structure. Duplicate contentinfo landmarks create ambiguity: a user jumping to "the footer" has no way to know which one contains the information they need.

This rule relates to WCAG 2.0 Success Criterion 1.3.1 (Info and Relationships), Level A, which requires that the structure and relationships conveyed visually are also available programmatically. Duplicate top-level landmarks break the expected structural contract of a well-formed page.

How to fix it

The fix depends on why multiple contentinfo landmarks exist.

If the page has more than one <footer> element as a direct child of <body>, determine which one is the true site-wide footer and keep it. Move or nest the others inside sectioning elements. A <footer> inside an <article>, <section>, or <aside> does not receive the contentinfo role, so it won't conflict.

If the page uses role="contentinfo" on multiple elements, remove the role from all but one. Any remaining footer-like regions should either be nested inside sectioning elements or given a different, more appropriate role.

Examples

Incorrect: two top-level footers

<body>
<header>
<h1>My site</h1>
</header>
<main>
<p>Page content goes here.</p>
</main>
<footer>
<p>Contact: info@example.com</p>
</footer>
<footer>
<p>&copy; 2024 Example Inc.</p>
</footer>
</body>

Both <footer> elements are direct children of <body>, so each one maps to the contentinfo role. The page now has two contentinfo landmarks.

Correct: single top-level footer

<body>
<header>
<h1>My site</h1>
</header>
<main>
<p>Page content goes here.</p>
</main>
<footer>
<p>Contact: info@example.com</p>
<p>&copy; 2024 Example Inc.</p>
</footer>
</body>

Combining the content into one <footer> gives the page a single contentinfo landmark.

Correct: footer nested inside a sectioning element

<body>
<header>
<h1>My site</h1>
</header>
<main>
<article>
<h2>Blog post title</h2>
<p>Article content.</p>
<footer>
<p>Written by Jane Doe on March 5, 2024</p>
</footer>
</article>
</main>
<footer>
<p>&copy; 2024 Example Inc.</p>
</footer>
</body>

The <footer> inside the <article> does not become a contentinfo landmark because it is scoped to its parent sectioning element. Only the bottom <footer> (a direct child of <body>) maps to contentinfo, so the page has exactly one.

Incorrect: duplicate role="contentinfo"

<body>
<div role="contentinfo">
<p>Contact: info@example.com</p>
</div>
<div role="contentinfo">
<p>&copy; 2024 Example Inc.</p>
</div>
</body>

Correct: single explicit contentinfo role

<body>
<footer>
<p>Contact: info@example.com</p>
<p>&copy; 2024 Example Inc.</p>
</footer>
</body>

Using a single <footer> element is preferable to applying role="contentinfo" manually, since the browser handles the role mapping automatically.

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