Accessibility
Headings run in order
a11y.heading-order
Why this matters
Screen reader users navigate by jumping between headings. When levels are skipped, that outline stops matching the page and becomes confusing to move through.
Who fixes it
You can, usually
Roughly how long
Minutes
Care needed
Low risk to change
How to fix it
Use heading levels in order — h1, then h2, then h3. Choose the level for structure and style it with CSS, rather than picking a level for its size.
On your platform
WordPress
Nearly always a page builder, where the heading level is a dropdown next to the text and people pick it for the size they want. In the block editor it is the H1–H6 control on the heading block; in Elementor and Divi it is the HTML Tag setting. Pick the level for the structure and change the size in the block's own typography settings.
Shopify
Section headings in the theme use fixed levels, so a skipped level usually comes from headings typed into a page's rich-text content. Editing those in the page editor is the fix; changing the theme's levels affects every page that uses the section.
Drupal
Content typed into a body field is one source; the other is a view or block whose template prints a heading at a level chosen for its appearance. The template is the durable fix.
Joomla
Module titles are the usual cause — each module's Advanced tab has a Header Tag setting, and modules default to h3 regardless of what sits above them on the page.
How we score it
Failing this check takes up to 6 points off your accessibility score. It is a fact about your site rather than a measurement, so it reads the same on every scan until you change something.
Does your site pass this one?
This check runs on every scan, along with the other 106. Free, no account, and you see the evidence for each result.
Check my siteOther accessibility checks
- Accessibility check completedThe accessibility pass runs inside a real browser, and a few things can stop it: a content security policy that blocks our script, or a page that never finishes loading. When that happens the accessibility section is marked unchecked rather than passed, because finding no problems and being unable to look are not the same result.
- Buttons have readable labelsA button with no readable label is announced to a screen reader as nothing more than 'button'. This usually happens when the button contains only an icon. If the unlabelled one is a menu toggle or an Add to Basket, the site becomes unusable rather than merely awkward.
- Form fields are labelledA form field without a label gives a screen reader user no indication of what to type into it. Placeholder text is not a substitute — it vanishes the moment somebody starts typing. On a contact or checkout form this is the difference between an enquiry and a visitor who leaves.
- Images have descriptions for screen readersSomeone using a screen reader hears nothing where these images are. If any of them are product photos, logos or buttons, that part of the page simply does not exist for them.
- Links have readable textA screen reader announces these as just "link", with nothing to say where they go. Icon-only links, such as social media buttons, are the usual cause.
- Page declares its languageScreen readers pick their pronunciation from this. Without it, English can be read aloud with the wrong accent and rhythm, which is hard to follow.