The ARIA in HTML specification defines the implicit ARIA semantics for HTML elements.
In this specification, the <header> element has an implicit ARIA role of banner only when it is not a descendant of certain sectioning or landmark elements.
If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=banner. Otherwise, role=generic.
This rule defines ARIA semantics. It doesn’t specify how browsers must represent elements internally. And it doesn’t determine how they expose elements to operating system accessibility APIs.
Example 1: header outside other landmarks
In the following example, the <header> element is not inside another sectioning or landmark element. Therefore, it has an implicit ARIA role of banner:
<div>
<header></header>
</div>Example 2: header inside another landmark
In this example, the <header> element is a descendant of <main>, which is a landmark. In this context, the implicit ARIA role of the <header> element is generic, meaning that no implicit ARIA landmark role applies.
<main>
<header></header>
</main>What Chrome exposes in the accessibility tree
If you inspect the second example using Chrome DevTools and view the accessibility tree, you’ll see that the <header> element is not shown with a role of generic. Instead, Chrome exposes it as sectionHeader.
This may seem to contradict the “ARIA in HTML” specification, but it doesn’t!
What “generic” actually means in the specification
In the “ARIA in HTML” spec, the term generic does not mean that the element has no semantics or that it should be removed from the accessibility tree.
It means only one thing: no implicit ARIA role applies.
The specification intentionally stops at defining ARIA semantics. It does not require browsers to expose a literal generic role to assistive technologies.
Under the hood in Blink
Chrome does not expose ARIA roles directly to assistive technologies. Instead, Blink builds an internal accessibility tree made up of accessibility objects (AXObjects). Each AXObject is assigned an internal role based on multiple inputs, including:
- the native HTML element type
- the element’s context in the DOM
- implicit ARIA semantics defined by specifications
- explicit ARIA roles, if present
When a <header> element does not qualify for the banner landmark role, Blink suppresses landmark semantics.
However, the element still represents a structural heading container within a section.
In this situation, Blink assigns a non-landmark structural accessibility role. On macOS, this role maps to AXSectionHeader, which Chrome surfaces in DevTools as sectionHeader.
This mapping reflects a structural role at the platform layer, not an ARIA role.
ARIA roles vs platform accessibility roles
This distinction is important:
- The “ARIA in HTML” spec defines implicit ARIA roles.
- Browsers internally assign accessibility roles that may be more granular.
- Operating system accessibility APIs often have richer role vocabularies than ARIA.
When Chrome exposes sectionHeader, it is:
- Fully compliant with the rule that no
bannerlandmark applies. - Fully compliant with the implicit ARIA role being
generic. - Expressing additional structural meaning at the platform level.
- Not exposing a different ARIA role.
Conclusion
Chrome is not misinterpreting the “ARIA in HTML” specification.
What you see as sectionHeader in the accessibility tree is a platform-level structural role chosen by the browser when landmark semantics do not apply.
This is a small example of how browsers have to reconcile HTML semantics, ARIA rules, and operating system accessibility APIs when constructing an accessibility tree.
Footnote
At the time of writing, the HTML Accessibility API Mappings (HTML-AAM) specification defines <header> elements that are scoped to sectioning content or other landmarks as having no implicit ARIA landmark role, and maps them to the ARIA role generic.
The HTML-AAM also includes an editorial note indicating that this mapping may change in a future revision, and references ongoing work in ARIA to introduce more specific roles for sectional headers and footers.
In December 2024, ARIA added the sectionheader and sectionfooter roles. This work does not retroactively change the current HTML-AAM mapping for <header>, but it signals a possible future direction for how nested headers and footers may be represented at the ARIA role level.
Importantly, browser developer tools may display internal or platform-specific roles such as sectionHeader. These reflect the browser’s internal accessibility object model or platform accessibility APIs, and do not necessarily indicate the computed ARIA role defined by the HTML-AAM.
Additional reading: Header & footer elements change their roles when they're inside of sectioning content