Most people picture a screen reader as a robot voice reading a web page from the top-left corner straight through to the bottom. That’s not how it works, and the gap between that picture and the reality is the whole reason some websites are perfectly usable without sight and others are a locked door.
I want to show you the real version. Not the standards, not the acronyms — just what actually happens when someone lands on your site and can’t see it.
First, the thing nobody tells you
A screen reader turns what’s on the screen into speech or braille. It’s software, not hardware. If you own a Mac or an iPhone, you already have one installed — it’s called VoiceOver. On Windows the two common ones are JAWS and NVDA.
Here’s the part that surprises people: almost nobody listens to a whole page. That would be like reading a newspaper by starting in the top corner and refusing to skip anything. Instead, people skim — exactly like you do, just by different means.
WebAIM, a research group at Utah State, surveys screen reader users every couple of years. Their most recent results, published in September 2026 from 1,780 respondents, asked what people do first when they hit a long page. Two-thirds — 67.8% — jump straight between the headings. The next most common answer, the browser’s Find feature, was a distant 12.5%. Reading the page from the start came in at under 10%.
So when someone arrives on your site with a screen reader, the first thing they hear is, in effect, your table of contents.
Which means your headings aren’t decoration. They’re the navigation, the summary, and the skim-read all at once. If your page has one real heading and then six paragraphs of bold text that look like headings but aren’t marked up as any, that table of contents is nearly empty — and the person is left scrolling through everything, one line at a time, looking for the bit they came for.
(WebAIM is careful to say their sample isn’t controlled and may not represent every screen reader user. I’d pass that caveat along rather than present it as gospel. But the direction of it matches everything I’ve seen.)
What I actually see go wrong
These are the things that come up again and again in real audits. None of them are exotic.
Headings that aren’t headings. Text styled to look like a heading — bigger, bold, a different colour — but marked up as an ordinary paragraph. It looks right and navigates like nothing. This is the single most common one, and given what the survey says about how people navigate, it’s also the most costly.
Buttons that aren’t buttons. A clickable box built out of a generic container rather than an actual button. A sighted visitor sees something obviously clickable. A screen reader announces… nothing in particular, and often can’t reach it by keyboard at all.
Images carrying information, with nothing to describe them. If your hours are in a graphic, or your menu is a photo of a menu, that content simply doesn’t exist for a screen reader. “Image” is all anyone hears.
Links that say “click here” or “read more.” People often pull up a list of just the links on a page to find their way around. A list of eleven identical “read more” entries is useless. Link text should say where it goes.
Forms where the grey placeholder text is the only label. Once you start typing, the hint disappears — for everyone. For a screen reader user it may never have been announced at all. So they’re filling in a box with no idea what it wants.
What I can and can’t tell you
Here’s where I should be straight with you, because it matters.
I test websites with screen readers. I don’t depend on one. Those are genuinely different things, and anyone who blurs them is overselling what they know.
Someone who uses a screen reader daily is fast at it — far faster than I am — and has worked out ways around a great deal of bad design, because they’ve had to. The failures I listed above aren’t things that merely inconvenience an expert user. They’re the ones that stop even an expert, because no amount of skill gets you past a button that was never announced.
So treat what follows as an engineer’s view of the machinery, not a report from lived experience. For the latter, the WebAIM survey is a better source than I am.
Try it yourself — about ten minutes
This is the part I’d genuinely like you to do, because reading about it does nothing and five minutes of doing it tends to stick for years.
On a Mac: press Cmd + F5. That’s it — VoiceOver is already there. On an iPhone: Settings → Accessibility → VoiceOver. On Windows: download NVDA from nvaccess.org. It’s free, and it’s what a large share of users actually use.
Then turn it on, look away from the screen, and try to do one real thing on your own website. Find your phone number. Get to your contact form. Check your hours.
Two honest warnings. First, it will feel clumsy and overwhelming, and that’s you being a beginner, not a simulation of disability — don’t mistake your fumbling for their experience. Second, you may find it genuinely hard to get through a task on your own site. That’s the useful part. Sit with it rather than closing the laptop.
Where to start, if that went badly
If the ten minutes left you uneasy, there’s a free accessibility checker on this site that looks for several of the problems above — missing alt text, unlabelled form fields, vague link text, heading structure that skips levels.
Be clear-eyed about what it is, though. Automated checks catch a real but limited slice of accessibility problems — the machine-checkable ones. They cannot tell you whether your page makes sense when heard, or whether someone can actually complete the thing they came to do. No scanner can. That part takes a person.
And if you get offered an “accessibility overlay” — a widget you paste in that promises instant compliance for a monthly fee — don’t. Screen reader users report they frequently make things worse, and businesses that installed them have still been sued. The only thing that fixes an inaccessible site is fixing the site.
Why bother
Not because of a lawsuit, though that’s real. Because roughly one in four adults has a disability, because the fixes above are the same fixes that make your site work better on a phone and read more clearly to Google, and because none of this is exotic work. Most of it is using the right HTML element for the thing you already built.
A website that can’t be used by someone who can’t see it isn’t broken in some abstract, standards-committee way. It’s a shop with a step at the door and no ramp — not malice, just something nobody thought about.
If you’d like someone to go through your site properly and tell you plainly what’s wrong and what’s worth fixing first, that’s exactly what I do. But run the ten-minute test yourself before you call anyone, including me — you’ll learn more from that than from any report.
← All writing