A screen reader is assistive technology that turns what’s on a screen into speech or Braille so people who are blind or have low vision can use a website. Instead of a mouse, the user navigates by keyboard — jumping between headings, links, and form fields — while the software reads each element aloud based on your HTML.
The major screen readers
You don’t need to learn dozens of tools. A handful dominate real-world usage, and testing with them covers the vast majority of your audience. According to long-running surveys by WebAIM, these are the screen readers people actually rely on:
| Screen reader | Platform | Cost | Notes |
|---|---|---|---|
| NVDA | Windows | Free / open-source | The most widely used screen reader; great for testing because anyone can install it. |
| JAWS | Windows | Paid (commercial) | Long-established in workplaces and government; feature-rich and scriptable. |
| VoiceOver | macOS, iOS, iPadOS | Free (built in) | Apple’s screen reader; the default for blind iPhone users. |
| TalkBack | Android | Free (built in) | Google’s mobile screen reader. |
| Narrator | Windows | Free (built in) | Microsoft’s built-in option; less common than NVDA or JAWS. |
A practical takeaway for small businesses: you can test your own site for free today. Install NVDA on a Windows PC or turn on VoiceOver on a Mac or iPhone and try to complete a real task — find a product, fill out a contact form, check out. If you can’t do it by listening and using the keyboard, neither can your customers.
How a screen reader reads a page
A screen reader doesn’t “see” your visual layout. It builds a model of the page from the accessibility tree — a structure the browser derives from your HTML and any ARIA you’ve added. Then it reads in source order and lets the user move around quickly using keyboard shortcuts.
Most navigation happens by jumping between element types rather than reading top to bottom:
- Headings — Users press a key to skip from one heading to the next, the way a sighted person scans a page. Logical, nested heading levels (from the page title down to sub-points) act as a table of contents. Skipped levels or fake headings (bold text that isn’t a real heading) break this. See our guide to heading structure and landmarks.
- Landmarks — Regions like
<header>,<nav>,<main>, and<footer>let users jump straight to the navigation or main content, or skip past repeated menus. - Links and buttons — Screen readers can list every link on a page. That’s why “click here” and “read more” are useless out of context; the link text has to describe its destination on its own.
- Images — The reader announces an image’s alt text. No alt means it may read a filename like
IMG_4821.jpg; an emptyalt=""correctly tells it to skip a decorative image. - Forms — Each field’s accessible name comes from its
<label>. An input with no associated label gets announced as just “edit, blank,” leaving the user guessing what to type. Our accessible forms guide covers this in depth. - Tables — Properly marked-up
<th>headers let the reader announce “Row 3, Price, $19” so data tables stay understandable.
Why semantic HTML matters most
Here’s the core principle: a screen reader can only convey what your code actually means. A <button> announces itself as a button and works with the Enter and Space keys for free. A <div> styled to look like a button announces nothing useful and may not be operable at all. The single highest-leverage thing you can do for screen-reader users is use native, semantic HTML — real headings, real lists, real buttons, real form labels — before reaching for anything else.
This maps directly onto the POUR principles behind WCAG: content must be Perceivable, Operable, Understandable, and Robust. Semantic HTML satisfies all four almost by default.
Where ARIA fits in
ARIA (Accessible Rich Internet Applications) is a set of attributes that adds roles, states, and properties to elements the browser can’t describe on its own — useful for custom widgets like tabs, modals, and menus. It’s powerful, but it comes with a catch the W3C states plainly: No ARIA is better than bad ARIA.
ARIA only changes how something is announced; it does not add behavior. Slapping role="button" on a <div> makes a screen reader say “button,” but you still have to wire up keyboard handling yourself. That’s why the right move is native HTML first, ARIA only to fill genuine gaps. For the details, see our guide to ARIA labels and roles, and the official WAI-ARIA Authoring Practices.
Screen readers run on the keyboard
Screen readers are operated entirely by keyboard — there’s no mouse pointer to chase. That means everything a screen-reader user needs must be reachable and operable with Tab, Enter, Space, and arrow keys, in a sensible order, with a visible focus indicator for anyone who has partial sight. If a feature works only on hover or click, it’s effectively invisible to these users. We cover this fully in keyboard navigation and accessibility, which goes hand in hand with screen-reader support.
Why this is a legal issue, not just a nice-to-have
Under ADA Title III, U.S. courts have repeatedly treated business websites as places of public accommodation, with WCAG 2.1 AA as the practical benchmark. The same standard underpins Section 508 for federal agencies and their vendors — the framework documented at Section508.gov — and is reflected in a vendor’s VPAT (Voluntary Product Accessibility Template).
Screen-reader failures — missing alt text, unlabeled forms, no headings, keyboard traps — are among the most common allegations in the thousands of ADA web accessibility lawsuits and demand letters filed in the U.S. each year. The Department of Justice has affirmed that the ADA applies to web content. (This is general information, not legal advice; if you’ve received a demand letter, talk to an attorney and see our demand-letter guide.)
Overlays don’t solve this
A common shortcut is an accessibility overlay — a script you paste in that promises instant compliance. It won’t make your site genuinely screen-reader friendly. Overlays can’t invent meaning that isn’t in your HTML, they frequently conflict with the user’s own screen reader, and many blind users disable them on sight. Plenty of sites running overlays have still faced lawsuits. The durable fix is to correct the underlying code. We explain the evidence in overlay vs manual remediation.
How to make your site work for screen readers
The path is straightforward, even if the work is detailed:
- Test with a real screen reader. Use free NVDA or VoiceOver and try to complete a key task by keyboard and ear.
- Run an audit. Combine automated scanning with hands-on checks — automated tools catch only part of the picture. A proper accessibility audit finds what scanners miss.
- Remediate the code. Fix headings, labels, alt text, landmarks, focus order, and ARIA by hand.
- Re-test and document. Confirm with screen readers and record conformance.
Curbcut does this work manually — no overlays, no shortcuts. If you’d like to know where your site stands with NVDA, JAWS, and VoiceOver, start with a free accessibility scan, or have our team remediate the issues for you.