Testing Heading Structure on Product Pages Without Guessing

Screen reader users navigate by headings, and product pages are where heading order goes to die: marketing copy as H2s, specs as paragraphs, and the product name repeated at three levels.

Ask a screen reader user how they survey a page and the answer is headings. They pull up a list of them the way a sighted shopper skims, and they jump. If the list reads like a slogan wall, product name, a campaign line, another product name, the page has no map, and navigation becomes a slow read from the top.

Heading structure is WCAG 1.3.1 territory, info and relationships, with 2.4.6 asking that headings describe their topic. Neither criterion demands a perfect outline for its own sake. They demand that the structure a sighted reader sees is the structure the markup reports. Product pages fail that in predictable places.

One H1, and it is the product

The product name is the H1. Not the store name, not the campaign headline above it, not the name repeated again inside a sticky summary bar. Stores break this when a marketing block gets promoted visually and someone styles the promotion by promoting its heading level too. Headings chosen for their font size are the root failure here. Size is a style decision. Level is a structure decision, and CSS exists precisely so the two can be made separately.

Below the H1, the sections a shopper expects should appear as headings at a consistent level: description, details or specifications, sizing, delivery and returns, reviews. If delivery and returns is a paragraph with bold text, it will not appear in the heading list, and the shopper navigating by headings concludes the information is not on the page. Sometimes they conclude it in the middle of checkout, which is worse.

How to test it in ten minutes

Open the page with a headings list, through a screen reader's elements list or a browser headings tool, and read only that list. It should tell the story of the page: what the product is, what the sections cover, where reviews sit. Then check the order in the list against the order on screen. A reviews heading that appears before the description in the list while sitting below it visually means the DOM and the design disagree, and keyboard and screen reader users get the DOM version.

Test the template, not twenty products. Heading structure is generated by the product template and its app blocks, so one product per template, plus one with every optional block switched on, the video, the comparison table, the FAQ accordion, covers the realistic variation. FAQ accordions deserve a specific look: questions marked up as headings inside buttons is a sound pattern, questions as styled divs are invisible to heading navigation entirely.

The skips that are not failures

A missing H2 level, jumping from H1 to H3, is untidy and worth fixing in the template, but it does not strand a user the way a missing heading does. Rank your findings accordingly. No heading at all on a major section is a barrier. A skipped level is a consistency fix. Audits that report both with the same severity teach teams to ignore audits, and a team that ignores the report will miss the day it contains the barrier that matters.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Testing Accessible Names on Header Icon Buttons, ADA Risk on Campaign Microsites Built Outside the Main Theme, and Testing Target Size: The Small Buttons That Block Mobile Checkout.

Frequently asked questions

How many H1 headings should a product page have?

One: the product name. Store names, campaign lines, and sticky summary bars should not compete with it at H1 level.

Is skipping a heading level an accessibility failure?

It is a consistency problem rather than a hard barrier in most readings of WCAG. Missing headings on major sections, or headings that do not describe their content, are the more serious findings.

How do you test heading structure quickly?

Read the headings list on its own, as a screen reader presents it. It should map the page accurately and in visual order. Test one product per template, including one with all optional blocks enabled.

Should FAQ questions be headings?

Questions inside accordion buttons marked up as headings are a sound, navigable pattern. Questions built as styled divs are invisible to heading navigation, which is how many users scan for answers.