If you’ve never used a screen reader, it’s easy to assume your site is fine because it looks fine. Screen readers don’t see your site the way you do, they hear the underlying structure of your HTML read aloud, in order, without the visual layout to lean on. A site that looks polished can still be genuinely unusable this way, and most site owners have no idea until someone tells them.

Here’s what screen reader compatibility actually tests, and how to check your own site without needing to be an accessibility expert.

What a screen reader is actually doing

A screen reader converts on-screen content into speech or braille output. It moves through a page based on the document’s structure, headings, landmarks, links, form labels, image alt text, not based on how things are visually arranged. If your HTML is a mess of divs with no semantic structure, a screen reader user gets a wall of unlabelled content with no way to navigate it efficiently.

This matters for a real slice of your visitors. Blind and low-vision users rely on screen readers daily, but so do some users with cognitive disabilities, temporary situational impairments, and increasingly, voice assistants and AI crawlers that parse pages the same structural way.

The core things screen reader compatibility checks

• Heading structure. Does the page have one H1, followed by a logical, non-skipping hierarchy of H2s, H3s, and so on? A screen reader user often navigates by jumping between headings, so a broken hierarchy makes the page feel disorganized even if it isn’t visually.
• Alt text on images. Every meaningful image needs a description of what it conveys. Purely decorative images should have empty alt attributes so the screen reader skips over them instead of announcing “image” for no reason.
• Form labels. Every input field needs a programmatically associated label, not just placeholder text, which disappears once you start typing and isn’t reliably read by all screen readers.
• Link text. Links that just say “click here” or “read more” are meaningless out of context. Screen reader users often pull up a list of all links on a page, and a page full of “click here” links tells them nothing about where those links go.
• Landmarks and ARIA roles. Elements like nav, main, header, and footer help a screen reader user jump straight to the section they need instead of tabbing through the entire page.
• Focus order and keyboard access. Many screen reader users also navigate by keyboard. If focus jumps around unpredictably, or something can only be activated with a mouse, it’s effectively locked away.

How to check your own site

You don’t need to buy expensive testing software to get a real sense of where you stand.

• Free browser extensions. Tools like WAVE or the axe DevTools extension will scan a page and flag missing alt text, label issues, and heading problems in seconds, and both have generous free tiers suitable for a DIY check.
• Turn on your device’s built-in screen reader. Every modern operating system ships with one for free, VoiceOver on Mac and iOS, TalkBack on Android, Narrator on Windows. Turn it on, close your eyes, and try to complete your site’s main goal, filling out a contact form, buying a product, reading an article, using only what you hear.
• Tab through your site with a keyboard. Unplug your mouse for five minutes and navigate using only Tab, Shift+Tab, and Enter. If you lose track of where you are on the page, a screen reader user will too.
• Check your heading outline. Most browser dev tools, or free extensions, can show you a page’s heading structure at a glance. Look for skipped levels or headings used purely for visual size rather than actual structure.

What to fix first

If you only have time for one pass, start with alt text and form labels. They’re usually the fastest fixes and the ones that cause the most immediate friction when they’re missing. Heading structure and link text come next, they take a bit more editorial thought but pay off across your whole site at once.

Screen reader compatibility isn’t a single checkbox you tick and forget. It’s closer to a habit you build into how you write and structure content going forward, so every new page you publish starts out accessible instead of needing a retrofit later.