Questions about how many header, footer, or h1 elements are allowed in a page are extremely common in web development, and they are often framed as strict accessibility rules. In reality, accessibility is less about counting elements and more about meaning, structure, and relationships.
This article clarifies what is valid, what is accessible, and what actually matters when using header, footer, and h1 elements in a single document.
The Core Principle: Semantics Over Superstition
HTML is not a set of fragile rules that break accessibility when slightly bent. It is a semantic language designed to describe the structure of a document.
The key question is not "how many of these elements am I allowed to use?", but rather "Do these elements accurately describe the structure of the content?".
Multiple header Elements
Is it allowed? Yes. You can have multiple header elements in a single document. A header represents introductory content for its nearest sectioning ancestor, such as:
bodymainarticlesectionnav
Example
<header>
<h1>Site name</h1>
</header>
<main>
<article>
<header>
<h2>Article title</h2>
</header>
<p>Article content…</p>
</article>
</main>
This structure is both valid HTML and accessible. Each header introduces its own section. Screen readers expose headers as structural landmarks tied to their sections. Multiple headers are not confusing when the hierarchy is clear.
Multiple footer Elements
Is it allowed? Also yes. Like header, the footer element is section-scoped. A footer contains information related to its nearest ancestor section, such as:
- Author information
- Related links
- Metadata
Example
<article>
<p>Post content…</p>
<footer>
<p>Written by Alex</p>
</footer>
</article>
<footer>
<p>© 2026 Example site</p>
</footer>
Screen readers announce footers as landmarks only when they are top-level. Nested footers are treated as part of their section, which is expected behaviour.
Multiple h1 Elements
Is it allowed? A really strong yes. HTML5 explicitly allows multiple h1 elements. Each h1 represents the top heading of its sectioning context.
Example
<main>
<article>
<h1>Article title</h1>
<section>
<h2>Introduction</h2>
</section>
</article>
<article>
<h1>Another article</h1>
<section>
<h2>Overview</h2>
</section>
</article>
</main>
The Real Accessibility Question About Headings
The real issue is not the number of h1s, but whether the heading hierarchy makes sense.
A good heading structure involves headings that reflect the content structure, that levels are not skipped arbitrarily, and sections are clearly defined
//Poor Heading Structure
<h1>Main title</h1>
<h4>Subsection</h4>
Skipping levels creates confusion for screen reader users who navigate by headings.
Screen Readers and Navigation
Many assistive technology users navigate pages by headings, landmarks or regions. Proper use of header, footer, and heading levels enables faster navigation, clear mental models of the page and predictable reading order
The problem is not multiplicity: it is misrepresentation.
Practical Guidelines
header and footer elements should be used to introduce or conclude meaningful sections of content, not as generic wrappers. Headings should reflect the real structure of the page rather than visual styling choices, helping users understand how content is organised.
Clarity should always be prioritised over rigid or outdated rules, and heading navigation should be tested with a screen reader to ensure the structure works in practice.
If the structure makes sense to a human, it usually makes sense to assistive technology.
Conclusions
Using multiple header and footer elements in a document is both valid and accessible when they correctly describe their respective sections. Multiple h1 elements are also allowed and often appropriate, particularly in documents composed of distinct articles or regions.
Accessibility does not depend on counting elements, but on providing a clear and logical hierarchy that accurately represents the content.
HTML accessibility is ultimately about expressing meaning rather than following myths or arbitrary conventions.
Top comments (1)
I was under the impression that while when HTML5 came out, you could restart the heading level hierarchy in a new section, that got walked back a few years ago?