ARIA Landmarks and Heading Structure: A Screen-Reader Navigation Guide for E-Commerce Pages

Quick answer: A sighted shopper scans a page visually and jumps straight to the product grid, skipping the header and nav bar without thinking about it. A screen-reader user gets the same shortcut a different way — through landmark regions (banner, navigation, main, search, contentinfo), a logical heading hierarchy (one <h1>, no skipped levels), and a skip link at the top of the page. These three things aren’t separate checklist items; they’re one navigation system, and it only works if all three are marked up correctly. Get the markup right and a screen reader user can jump straight to your product listings the same way a sighted user’s eyes do. Get it wrong — landmarks missing or misapplied, headings out of order, no skip link — and every visit starts with tabbing or listening through the entire header and nav menu first.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for page structure and how to implement it, not whether a specific site carries legal risk.

Why these three things are one system, not three tasks

Screen readers expose two navigation modes that have no sighted equivalent: a landmarks list and a headings list, both callable at any time (NVDA and JAWS use a dedicated Elements List; VoiceOver has a Rotor). A user can pull up either list and jump directly to, say, “main” or “Product Reviews” without listening to anything in between. WebAIM’s guidance on page structure puts it plainly: page regions like <header>, <nav>, <main>, and <footer> “programmatically define the essential semantic structure of a page, allowing screen reader users to easily navigate among these major page areas.” Skip links exist for the same reason, aimed at keyboard-only users who don’t have a landmarks list to jump through — a single link that does the equivalent of a sighted user’s eyes skipping straight past the header.

None of this works if only one piece is in place. A page with perfect landmarks but a scrambled heading order still leaves a user unable to tell which section they landed in. A page with clean headings but no main landmark still forces a full read-through to find where the repeated header content ends.

Landmark regions: which ones, and how many

The WAI-ARIA Authoring Practices Guide’s landmark regions pattern defines the roles that matter for a typical e-commerce page — banner, navigation, main, search, contentinfo — and states how many of each a page should have: “Each page may have one banner landmark” and “Each page should have one main landmark,” while roles that can legitimately repeat (navigation, search, region) carry a different rule: “If a page includes more than one [landmark of that type], each should have a unique label.” That last rule matters specifically for e-commerce: a product listing page commonly has a primary site-navigation <nav> in the header and a filter sidebar that also behaves like a navigation region. Both existing without distinct aria-label values means a screen-reader user’s landmarks list shows two entries both labeled “navigation,” with no way to tell which is which without opening each one.

Native HTML elements are the simplest way to get most of this for free — <header>, <nav>, <main>, <footer> map directly to the banner, navigation, main, and contentinfo roles without an explicit role attribute. The one common way this breaks silently: WebAIM notes that <header>, <main>, and <footer> only expose their landmark role when they’re direct children of <body> — nest a <header> inside another wrapping <div> (common in component-based frameworks) and it stops being announced as a banner landmark at all, with no visual difference and no error to catch it.

<header>...primary nav, logo, search, cart icon...</header>
<nav aria-label="Product filters">...faceted search sidebar...</nav>
<main>
  <h1>Women's Running Shoes</h1>
  ...product grid...
</main>
<footer>...site links, contact info...</footer>

Heading hierarchy: one <h1>, no skipped levels

WCAG’s own Understanding SC 2.4.6 Headings and Labels requires that “headings and labels describe topic or purpose” — a real requirement, but one that’s about clarity, not nesting order. The no-skipped-levels rule that most teams actually mean when they talk about “correct heading structure” comes from established practice rather than the letter of that one success criterion: WebAIM’s guidance is direct that “when creating a heading structure for a web page, avoid skipping heading levels or applying illogical heading levels,” and that “a page should typically have only one first-level heading that describes the page’s overall content.” On a product page, that means a single <h1> for the product name, <h2>s for major sections (Description, Reviews, You May Also Like), and <h3>s nested under those — not a <h1> product name followed directly by <h4> subsection titles because that’s what matched the target font size in the design file.

The underlying legal hook for getting the structure programmatically correct — as opposed to just visually consistent — is WCAG SC 1.3.1 Info and Relationships (Level A), which requires that “information, structure, and relationships conveyed through presentation can be programmatically determined.” A heading styled to look smaller with CSS but still marked up as an <h2> still reads as an <h2> to a screen reader — the structure a sighted user perceives through font size has to actually exist in the markup, not just the visual styling.

Skip links: WCAG’s own example is an e-commerce filter sidebar

WCAG SC 2.4.1 Bypass Blocks (Level A) exists so that “people who navigate sequentially through content” get “more direct access to the primary content of the web page” instead of tabbing through every repeated header and nav item on every single page. Its sufficient techniques include both a literal skip link (“adding a link at the top of each page that goes directly to the main content area”) and the landmark/heading structure above, since a landmarks or headings list serves the same bypass purpose for a screen-reader user. Notably, the standard’s own worked example is close to this exact scenario: “an online retailer provides a link above the [filter] list” so a shopper can “skip the filters and get to the product results quickly” — this isn’t a generic accessibility example adapted to e-commerce, it’s the specification’s own case for it.

A skip link is simple to build and easy to get wrong invisibly: it needs to be the first focusable element on the page, and it needs to actually move keyboard focus to the target (usually via tabindex="-1" on the destination), not just scroll it into view. A link that visually scrolls to #main-content without moving focus there leaves a keyboard user’s next Tab press starting back near the top of the page.

What a scan catches here, and what still needs a person

Automated tools can confirm that landmark elements and headings exist and that heading levels don’t technically skip in the DOM. What they can’t judge: whether a <nav> region actually contains navigation-appropriate content instead of being a container of convenience, whether two landmarks of the same type have genuinely distinct (not just technically different) labels, or whether a skip link’s target actually receives focus when activated — all of which require someone to actually navigate the page with a landmarks list and a keyboard, not just parse the markup. Our piece on what automated scanners structurally can’t catch covers this gap in more general terms.

FAQ

Do I need aria-label on every landmark? No — only when more than one landmark of the same role exists on a page (two <nav> elements, for example). A single <main> or <header> doesn’t need a label; the role alone is enough for a screen reader to identify it.

Is it okay to have zero <h1> elements, or more than one? Zero leaves the page without the anchor heading a screen-reader user expects when arriving on it. More than one is a common pattern-library mistake (a page-title component and a hero-banner component both independently rendering an <h1>) — per WebAIM’s guidance above, a page should typically have exactly one.

Does a skip link need to be visible all the time? No — the common, WCAG-compliant pattern is a link that’s visually hidden until it receives keyboard focus, at which point it becomes visible. It just can’t be hidden in a way (like display: none) that also removes it from the keyboard tab order.

Get your page structure checked by a person, not just a parser

Quietramp’s $890 audits include a manual pass through your site’s landmark and heading structure with a keyboard and screen reader — not just a check that the elements exist, but whether they’re labeled and organized the way a real user navigating by them would need. See a real sample report or check pricing.

---

This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not constitute a legal compliance determination under the ADA or any other standard — consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.