What does a page need to survive being read aloud?

What does a page need to survive being read aloud?

Headings that say what the section is about, link text that makes sense without the sentence around it, images with real alternative text, and instructions that do not depend on where something sits on screen. Strip the layout away and the page should still make sense in order.

I started thinking about this because of accessibility, and I kept thinking about it because of answer engines. Both consume a page as a sequence of text rather than as a picture, so a page built only for the eye tends to fail both at once.

This is a design post, but almost none of the work is visual. It is about whether your structure survives being linearised.

Who is actually reading your page without seeing it?

More readers than most teams assume. People using screen readers, people listening while doing something else, anyone with a small screen and a reflowed layout, and every machine that parses your page into text. The same structure serves all of them.

The useful mental model is that your page has two versions. The one your designer approved, and the one that exists when you read the source top to bottom. Most teams only ever review the first, which is why problems in the second survive for years.

You can check the second version in about a minute. Turn on your operating system's read aloud feature on a page you own and listen to the first screen. The parts that make you wince are your list of fixes.

What do the published standards actually require?

Less than people fear and more than most sites do. The Web Content Accessibility Guidelines are explicit about the basics. Success Criterion 1.1.1 Non-text Content states that all non-text content presented to the user has a text alternative that serves the equivalent purpose, with defined exceptions.

Two more matter specifically for reading order. Success Criterion 1.3.2 Meaningful Sequence says that when the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. Success Criterion 2.4.6 Headings and Labels, at level AA, says simply that headings and labels describe topic or purpose.

The link rule is the one I quote most often. Success Criterion 2.4.4 Link Purpose (In Context) says the purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose would be ambiguous to users in general. That single sentence retires every click here on your site.

Why do headings decide so much?

Because headings are how a listener navigates. Someone using a screen reader can jump between headings the way you skim with your eyes, so a page whose headings say Features, Benefits, and More is a page with no navigation at all for that reader.

This is why I write headings as questions on almost everything I publish. A question heading cannot avoid describing its topic, which satisfies the standard and also gives a listener a real decision about whether to keep going or skip ahead.

Visual hierarchy is not the same thing as structural hierarchy, and that is where design systems cause trouble. Text styled to look like a heading but marked up as a paragraph is invisible to a listener. The fix is boring, which is to use real heading elements in the right order and let styling follow.

What breaks when instructions rely on the layout?

Anything phrased as a position. The button on the right, the box below, the sidebar. Success Criterion 1.3.3 Sensory Characteristics addresses this directly, saying instructions for understanding and operating content do not rely solely on sensory characteristics such as shape, colour, size, visual location, orientation, or sound.

In practice the rewrite is easy and it improves the copy for everyone. Name the thing instead of pointing at it. Choose a plan in the pricing section, rather than click the button on the right, works whether the reader sees the page, hears it, or is reading a reflowed single column version on a phone.

The same rule quietly protects you from your own redesigns. Copy that refers to positions becomes wrong the moment the layout changes, and nobody thinks to search the content for stale directions.

How should you write alternative text so it earns its place?

Write what the image contributes, not what it contains. If the image carries information, the alternative text should carry the same information. If it is decorative, it should be marked as decorative rather than described, because a listener does not want to hear about your background texture.

The hard cases are charts and screenshots, which most sites get wrong in the same way. A chart's alternative text should state the finding, not the shape. A screenshot's should say what it demonstrates. If the point of the image cannot be summarised in a sentence, the point probably belongs in the body text as well.

I treat this as an editorial task rather than a technical one, because a developer cannot know what an image was supposed to prove. If you write the alternative text while writing the section, it takes seconds and it is right.

Does this help with AI answers too?

Structurally, yes, and I want to be careful about how I say that. A system reading your page as text benefits from the same things a listener benefits from, which are descriptive headings, self contained link text, and content whose order carries its meaning. That is a similarity in how the page is consumed.

What I will not claim is that accessibility improves citation rates or rankings, because I have no primary source for that and it is the kind of confident sentence that circulates without evidence. The honest version is narrower and still useful. A page that only makes sense visually gives any text consumer less to work with.

The overlap is clearest with tables and complex layouts, where visual arrangement carries meaning that the underlying markup may not. That problem shows up for machines too, which I looked at in whether AI engines read tables on your page.

What does this mean for how you build components?

Build once, correctly, and the whole site inherits it. Headings with real levels, links whose text stands alone, form fields tied to visible labels, and images with an alternative text field in the CMS rather than an afterthought. Components are where accessibility either happens or does not.

The CMS part is the one teams skip. If your collection has no alternative text field, nobody will add alternative text, because there is nowhere to put it. Adding the field costs minutes and changes the default behaviour of everyone who publishes afterwards.

Forms deserve their own pass, since they are where a listener is most likely to get stuck and give up. Labels, error messages tied to the field they describe, and a clear statement of what is required all matter more than any visual treatment, which is the argument in what an accessible form needs beyond labels.

What is the fastest way to find the problems on your own site?

Read the page in order with the styles off, then listen to it. Both take minutes and both surface different failures. Styles off shows you the real structure and reading order. Listening shows you the link text, the alternative text, and the sentences that only work visually.

I do this on every template rather than every page, because failures live in templates. Fix a heading level in one component and every page using it improves, which is the cheapest accessibility work available on a large site.

Automated checkers are useful and partial. They will find a missing label and they cannot tell you that a heading is uninformative or that alternative text describes the wrong thing. Those need a person, which is also true of the related question of whether a page is legible to someone who is only skimming, covered in designing for the skim reader.

What should you do next?

Pick your most important page, turn on read aloud, and listen to the first two minutes. Write down every moment you could not tell where you were or what a link would do. Fix those in the component rather than on the page, and the rest of the site improves with it.

If you want someone to run that pass across your templates and tell you what to change first, that is a short and genuinely useful piece of work. Reach out if you want a second opinion on how your site sounds.