How screen readers read a website and why structure matters

A common assumption is that a blind visitor starts at the top of your page and listens patiently to everything. Almost nobody does that, any more than a sighted visitor reads every word before deciding where to click. Experienced screen reader users skim, and they skim using the structures in your HTML. Understanding how screen readers read a website explains why headings, landmarks and link text matter so much more than most teams realise, and why a visually tidy page can still be impossible to navigate.

The page becomes a list of things to jump between

Screen reading software builds its own model of the page from the markup. From there the user can call up lists: every heading, every link, every form control, every landmark region. It is the audio equivalent of scanning a page with your eyes for something interesting.

Typical navigation looks like this. Open the page, pull up the heading list, hear the main sections, jump into the one that sounds relevant, then read from there. If the headings are meaningful, that takes seconds. If the page has one heading called "Welcome" and everything else is styled text, the only option left is listening to the entire page in order.

Different tools use different keys. In NVDA and JAWS, pressing H moves to the next heading and numbers move between heading levels; VoiceOver uses the rotor; TalkBack uses swipe gestures with a reading control. The idea is identical across all of them.

Headings are the table of contents

Because headings drive navigation, they need to describe content and follow a sensible order.

• One H1 per page, naming what the page is about.
• H2 for main sections, H3 for sub-points inside them, without skipping levels on the way down.
• Headings chosen for meaning, not for the size they happen to render at. Adjust size with CSS instead.
• Descriptive wording: "Delivery charges for bulk orders" tells a listener more than "More information".
• No fake headings, meaning bold paragraph text that looks like a heading but is not marked as one. Those are invisible to the heading list.

Read your heading list aloud on its own. If it reads like a coherent outline of the page, the structure is doing its job.

Landmarks let people skip the furniture

Landmarks are the regions of a page: header, navigation, main content, sidebar, footer. Using the semantic elements header, nav, main, aside and footer creates them automatically, and screen reader users can jump straight to main content instead of listening to thirty menu items on every page.

Two practical rules. Use exactly one main element, containing the unique content of that page. And if you have several navigation regions, such as a primary menu and a footer menu, give each an accessible name so the listener hears "primary navigation" rather than two identical entries.

A skip link at the very top of the page, pointing to the main content, helps keyboard users who are not using a screen reader at all. It can be visually hidden until focused, but it must become visible when it receives focus.

Link text has to work out of context

When someone opens the list of links on your page, they hear the link text alone, without the sentence around it. A page full of "click here", "read more" and "learn more" produces a list that is completely useless.

Write links that describe their destination: "download the price list", "see our hosting plans", "read the refund policy". If a design requires repeated "Read more" buttons on cards, add visually hidden text so the accessible name includes the article title.

Two more details worth fixing. A link whose text is a bare URL gets read character by character in some setups, which is painful; use words instead. And a link that opens a PDF or a new tab should say so, so nobody is surprised by what happens next.

Reading order follows the code, not the layout

This catches teams out regularly. Screen readers follow the order of elements in the HTML. CSS can place a block anywhere on screen, but it does not change that order.

So a sidebar that appears to the right of the content but sits before it in the markup gets read first. A grid where CSS reorders columns for mobile can produce an announcement sequence that makes no sense. A modal dialog appended at the end of the document is read after everything else unless focus is moved into it deliberately.

The test is simple: disable CSS in your browser, or view the page in reader mode, and check that the content still flows logically. The order you see then is the order a listener hears.

What commonly confuses screen readers

• Divs acting as buttons. Without the right role and keyboard handling, they are announced as plain text and cannot be activated.
• Content that appears without announcement. A search result count or an error message updated by JavaScript passes silently unless it sits in a live region.
• Focus that goes nowhere. Opening a menu or dialog without moving focus into it leaves the listener reading the page behind it.
• Focus traps. A dialog that cannot be closed with Escape or exited with Tab strands the user.
• Auto-playing carousels. Content that changes on a timer while being read is disorienting.
• Layout tables. Tables used for positioning are announced as data tables with rows and columns nobody asked about.
• Missing language attributes. Without a language set on the html element, the wrong pronunciation rules may be used, which matters for sites mixing English with Indian language content.
• Over-applied ARIA. Roles added on top of correct HTML often override what already worked.

Checking your own structure this week

You do not need to learn a screen reader to start. Open a browser extension or the accessibility panel in Chrome DevTools, look at the heading tree and the landmark list for your home page, and see whether they match what a visitor would expect. Then view the page with CSS disabled to confirm the reading order.

Fix the structure first, because it is template-level work that improves every page at once, and it also makes your pages easier for search engines to interpret. Our team can review the markup behind an existing site as part of a technical audit; the services page shows where that sits.

Frequently asked questions

Do screen reader users browse differently on phones?

The tools differ, with swipe gestures replacing keys, but the reliance on headings, landmarks and link text is the same. Mobile layouts that hide structure behind icons can be harder to work with.

Does good structure help SEO as well?

Yes, indirectly. Clear headings, semantic regions and descriptive link text help search engines understand a page, though accessibility should be the reason you do it.

How many headings should a page have?

As many as it has real sections. A long service page might have eight; a short contact page might have two. What matters is that each one names actual content.

Is it a problem if my page has no H1?

It is not a failure of a specific WCAG success criterion, but it removes the clearest signal of what the page is about. Give every page a single descriptive H1.