Does an HTML <header> element always expose the banner landmark role? What decides whether <header> and <footer> become banner and contentinfo?

## The mapping is contextual, not fixed Most HTML elements map to one ARIA role no matter where they appear. `<header>` and `<footer>` do not. Their role in the accessibility tree is computed from their ancestry: - `<header>` → `banner`, and `<footer>` → `contentinfo`, when the element is **not** a descendant of `<article>`, `<aside>`, `<main>`, `<nav>` or `<section>` (nor of an element carrying the equivalent explicit roles). - Otherwise → generic. No landmark, no rotor entry. So the same element, unchanged, is a landmark in one position and not in another: ```html <body> <header> <!-- role: banner --> <a href="/">Acme</a> </header> <main> <article> <header> <!-- role: generic, NOT banner --> <h2>Release notes 4.2</h2> <p>Posted 12 March</p> </header> <p>…</p> <footer> <!-- role: generic, NOT contentinfo --> <p>Filed under: releases</p> </footer> </article> </main> <footer> <!-- role: contentinfo --> <p>© 2026 Acme</p> </footer> </body> ``` ## Why the spec works this way `banner` means "this is the site's masthead" and `contentinfo` means "this is the page's footer information" — both are page-level claims, and both are expected to appear roughly once. But `<header>` and `<footer>` are also the right elements for *component-level* furniture: an article's byline block, a card's meta row, a `<section>`'s intro. Without the scoping rule, a feed of fifty posts would emit fifty banner landmarks and the landmark list would become unusable. Making the role conditional lets one element serve both jobs — page masthead and component header — without the author having to intervene. This is also a neat illustration of why "just add `role=banner` to be explicit" is bad advice: it overrides the context-aware mapping with a fixed one, which is exactly what you do not want on a nested header. ## The bug this causes in real code The common regression is a layout refactor that moves the site header inside a wrapper. If a framework's shell renders ```html <main> <header>…site masthead…</header> …page content… </main> ``` the masthead silently stops being a banner landmark. Nothing looks different; the page still renders identically; only the landmark list changed. The same happens when a developer wraps the whole page in `<section class="page">` for styling — every top-level header and footer inside it loses its landmark role at once. The reverse mistake also happens: a footer meant to be the article's is left as a sibling of `<main>`, and now the page reports contentinfo content that actually belongs to one article. ## How to check it rather than reason about it Do not eyeball the ancestry; read the accessibility tree. Browser devtools expose the computed role for a selected node, and an accessibility-tree or landmarks view will list what the page actually exposes. Automated checks also flag well-known landmark problems — duplicate banners, content sitting outside every landmark — but the fastest confirmation is to look at the computed role of the header itself and see whether it says `banner` or `generic`. ## Adjacent facts worth knowing A page is expected to have at most one banner and one contentinfo. Duplicates are not a parse error, but they defeat the purpose, and audits routinely flag them. `<header>` and `<footer>` have a content restriction of their own: neither may contain another `<header>` or `<footer>`, and neither may contain `<main>`. That is a separate rule from the role mapping, but it comes from the same idea — these are furniture wrappers, not general-purpose containers. Finally, `<footer>` is not required to be last, and `<header>` is not required to be first. They are defined by their role in the content, not their position, so a byline `<header>` can legitimately appear after an image, and a footer's contents are "information about its section" rather than "the bottom of it".