How Screen Readers Work (And Why Sites Fail Them)

A screen reader doesn't read your HTML directly, and it definitely doesn't read your CSS. The browser builds a parallel structure called the accessibility tree— a stripped-down version of your page where every element is reduced to three things a screen reader announces:

• Role — what the element is. Button, link, heading, checkbox, list item, image. This comes free from semantic HTML: a <button> has the role “button” automatically. A <div onclick> styled to look like a button has no role at all.
• Name — what the element is called. The visible text of a link, the alt text of an image, the label of a form field. No name means the screen reader announces just “button” with no idea what it does.
• State — what's happening right now. Checked, expanded, disabled, selected, “current page.” This is what tells a user their menu opened or their box got ticked.

Almost every screen-reader failure is one of these three going missing or wrong. Write plain, semantic HTML and the browser fills in role, name, and state for you for free. Reach for <div> soup plus JavaScript and you're now hand-building the accessibility tree yourself — which is exactly where things break. That's also why bolting ARIA attributes onto broken markup usually makes things worse, not better; we cover that trap in common ARIA mistakes.

You don't need to memorize all of WCAG to dramatically improve the screen-reader experience. The same handful of issues account for the overwhelming majority of real barriers:

• Images with no alt text. The screen reader either says nothing or reads the filename — “D S C underscore 0 4 8 2 dot jpg.” If the image carries meaning, it needs a description; if it's decorative, it needs an empty alt so it's skipped. Our guide to writing alt text walks through the judgment calls.
• Unlabeled controls. Icon-only buttons (cart, search, hamburger, close) and form fields with placeholder text instead of a real label announce as bare “button” or “edit text” with no purpose. The user is guessing.
• Fake buttons and links. A clickable <div> or <span> isn't in the accessibility tree as an interactive element, so it's invisible to keyboard and screen-reader users even though it works fine with a mouse.
• Meaningless heading structure. Screen-reader users navigate by pulling up a list of headings the way sighted users skim. Skip from an h1 to an h4 because it looked right, or fake headings with bold text, and that map falls apart.
• Silent changes. A cart count updates, a form error appears, a “copied!” toast pops — and the screen reader says nothing because the change was never announced. Sighted users see it; everyone else doesn't know it happened.

You already own a screen reader, and an hour with it will teach you more than a month of reading guidelines. You don't need to become an expert user — you need to hear your own site the way a real user does. Start small:

1. Turn one on. On a Mac, press Cmd + F5 for VoiceOver. On Windows, download NVDA for free. On your phone, VoiceOver and TalkBack are both a settings toggle away.
2. Close your eyes and use the keyboard. Put the mouse away. Tab through your homepage and your most important flow — sign-up, checkout, contact. Can you reach everything? Does each stop announce what it is and what it's for?
3. Pull up the headings and links list. Every screen reader can list a page's headings and links. If that list is gibberish — five “click here” links, no headings, or headings in the wrong order — your structure needs work.
4. Do the thing your users do. Actually complete a purchase or submit the form with your eyes shut. This is where you discover the silent errors, the focus traps, and the unlabeled fields that no scanner surfaced.

Pair that manual pass with a scan and a checklist and you have a genuinely reliable process. Run your pages through the ADA compliance checker first to clear the machine-detectable issues, then work down the WCAG checklist for the human ones.