Why doesn't a screen reader read the headings on my page correctly?

Headings are missing or in the wrong order

A screen reader usually cannot find headings on a page correctly because they are formatted visually as headings — larger, bold, a different colour — but are not coded as headings. A screen reader reads the underlying structure of the page, not how something looks. If a word is in large bold letters but there is no heading element in the code (such as h1, h2 or h3) behind it, a screen reader simply reads a line of plain text and does not indicate a heading. A user who presses Tab to jump from heading to heading to navigate quickly will miss that text entirely in their overview.

An incorrect order of headings is also a common cause. A page that jumps from an h1 directly to an h4, or in which an h3 sits above an h2, gives a screen reader a distorted picture of how the content is structured — some users expect a logical hierarchy to determine whether they want to open or skip a section. This problem is not separate from other structural errors on a page: similar problems occur with form fields that are not read correctly and with focus jumping during keyboard navigation. In all cases, it is about the same core issue: the visual display is correct, but the underlying code that a screen reader uses is not.

Where this appears in WCAG: Information and relationships

That structure must be programmatically recognisable — that is, in the code, not only visually — follows from the success criterion on information and relationships in WCAG 2.1, the guideline on which EN 301 549 is based in practice. Whether headings are actually coded as headings and are in a logical order is something that an automated check can largely detect; what an automated scan can and cannot find is a relevant distinction here, because a scan sees the presence of heading elements but cannot always assess whether the layout chosen is also logical for a user.