What Are Screen Readers and How Do They Work?

A screen reader is software that turns what is on a screen into synthesised speech or refreshable braille, so that a person who is blind or has low vision can use a computer, phone or website without seeing the display. It reads out text, announces images by their alt text, names links and buttons, and — crucially — lets the user navigate by jumping between headings, landmarks and form fields rather than wading through everything top to bottom. Because the screen reader builds that experience entirely from a page's underlying code, semantic HTML is what makes a site usable with one. This guide explains what screen readers are, how they actually read a page, which ones people use, and how to test your own site with one in a few minutes.

It is a practical companion to what web accessibility is and why it matters and to how to make a website keyboard accessible, since screen-reader users navigate almost entirely by keyboard.

What a screen reader is

A screen reader is a type of assistive technology — software that mediates between the user and the interface. Instead of relying on sight, the user relies on sound (synthesised speech read aloud) or touch (a refreshable braille display, a row of pins that rise and fall to form braille characters under the fingertips). The screen reader tracks what the operating system and applications expose about the screen, and it narrates that to the user while accepting keyboard commands or touch gestures to move around and interact.

It is important to understand that a screen reader does not "look at" pixels. It reads a structured representation of the interface that the software exposes — on the web, that is the rendered HTML and the accessibility tree the browser builds from it. This is the single most important fact for anyone building websites: the screen-reader experience is determined by your code, not your visual design. Two pages that look identical can be a joy or a nightmare with a screen reader depending entirely on the markup underneath.

Screen readers are not a niche tool used only for testing. They are the daily, primary means by which millions of blind and low-vision people read email, bank, shop, work and browse. Treating them as a real audience rather than a compliance checkbox is the right mindset.

The major screen readers

A handful of screen readers dominate, spread across platforms. This table maps the main ones to where they run and how people get them:

Screen reader	Platform	Cost / availability	Notes
NVDA (NonVisual Desktop Access)	Windows	Free, open source	Extremely popular; the usual choice for free testing on Windows
JAWS (Job Access With Speech)	Windows	Commercial (paid)	Long-established, powerful, common in enterprise and assistive settings
VoiceOver	macOS, iOS, iPadOS	Free, built in	On Mac press Command-F5; every Apple device already has it
TalkBack	Android	Free, built in	The standard screen reader on Android phones and tablets
Narrator	Windows	Free, built in	Microsoft's built-in option, improving steadily
Orca	Linux	Free, open source	The common screen reader on Linux desktops

WebAIM's periodic Screen Reader User Survey has consistently shown NVDA, JAWS and VoiceOver as the most-used tools, with mobile screen-reader usage (VoiceOver on iOS and TalkBack on Android) now a large and growing share. For practical testing the takeaway is simple: most people can reach for NVDA (free, Windows) or VoiceOver (built into every Mac and iPhone) without spending anything.

How a screen reader reads a page

The biggest misconception among sighted developers is that a screen reader just reads the page from the top to the bottom, and that as long as everything is "in there somewhere" it is fine. Real users do not work that way, any more than a sighted person reads every word of a long article from the first to the last. Screen-reader users skim and jump, and they have powerful tools to do it.

Linear reading

The most basic mode is reading continuously — the screen reader starts at the top and reads through the content in order. A user might do this for a short passage, but on a full web page it would be hopelessly slow. Linear order still matters enormously, though, because it determines the sequence in which content is announced when read straight through, and it must match the logical reading order. If your CSS visually rearranges content so that the source order no longer makes sense, the linear reading becomes scrambled.

Navigating by headings

The single most important navigation tool is moving by heading. Screen readers let users press a key (in NVDA, the letter H; via the VoiceOver rotor on a Mac or iPhone) to jump from one heading to the next, and to pull up a list of all headings on the page. This is exactly how a sighted person scans a page — eyes darting to the bold section titles — translated into audio. It means a logical, properly nested heading structure (a single h1, then h2s for sections, h3s for subsections, never skipping levels arbitrarily) is not a nicety; it is the primary map a screen-reader user uses to understand and move around your page. Headings that are faked with big bold text instead of real h1–h6 elements are invisible to this navigation, which is one of the most common and damaging mistakes.

Navigating by landmarks

HTML's semantic regions — header, nav, main, aside, footer (and their ARIA-role equivalents) — are exposed to screen readers as landmarks. Users can jump directly to the main content, the navigation, or the footer, skipping the rest. This is why wrapping your page in meaningful landmark elements matters: it gives screen-reader users a high-level table of contents for the whole layout.

Navigating by links, buttons and form fields

Screen readers also let users list and jump between all the links on a page, all the buttons, all the form fields, and other element types. This has direct design consequences. Because a user may pull up a list of links out of context, link text like "click here" or "read more" repeated ten times is useless — each link needs to make sense on its own (a point we make in how to make a website keyboard accessible too). Likewise, every form field must have a real, associated label, or the user navigating by field hears only "edit text" with no idea what to type.

Forms mode and focus mode

Here is a subtlety that surprises people. In their default "browse" or "reading" mode, screen readers intercept many keystrokes to use as navigation shortcuts (pressing H moves to the next heading, for example). But when the user needs to type into a text field, those single letters must go into the field, not trigger navigation. So screen readers switch into a forms mode (NVDA/JAWS) or, with VoiceOver, an interaction model where focus is on the control. Well-built, semantic forms trigger this switch automatically when focus lands on an input. Custom widgets that are not marked up correctly can fail to switch, leaving the user unable to type — another reason semantic markup and correct ARIA matter.

Why semantic HTML is everything

Pulling the threads together: a screen reader announces not just the text of an element but its role (is this a button, a heading, a list, a checkbox, a link?), its name (what is it called?), its state (is it expanded, checked, selected, disabled?), and its value. It gets all of that from the markup.

• A real <button> is announced as "button", is reachable and operable from the keyboard, and triggers forms behaviour correctly. A <div> painted to look like a button is announced as nothing meaningful and may be entirely unusable.
• A real <h2> is announced as a level-2 heading and appears in heading navigation. Bold text in a <p> is just text.
• A real <ul> is announced as "list, 5 items", giving the user structure and count. A stack of <div>s is just a wall of content.
• A real <label> tied to an <input> is announced when the field is focused, so the user knows what to type. An unlabelled field announces only "edit text".
• A real <nav> becomes a landmark the user can jump to. A <div class="nav"> does not.

This is the deepest reason accessibility and clean engineering are the same discipline. Use the right element for the job and most of the screen-reader experience comes for free. Reach for generic <div>s and <span>s and you must laboriously rebuild — with ARIA and JavaScript — the meaning the browser would have given you automatically, and you will usually get some of it wrong. The first rule of ARIA, from the W3C, captures it: do not use ARIA if a native HTML element will do the job.

How to test your site with a screen reader

You do not need to be a daily screen-reader user to learn a great deal from a basic pass — and it is the only way to experience what your code actually produces. Here is a beginner-friendly approach.

1. Turn one on. On Windows, download and start NVDA (free). On a Mac, press Command-F5 to toggle VoiceOver; on an iPhone, enable VoiceOver in Accessibility settings (or triple-click the side button if you have set that shortcut). On Android, enable TalkBack.
2. Learn a few commands. You only need a handful to start. With NVDA, use H to move to the next heading, K for the next link, F for the next form field, and the arrow keys to read line by line; NVDA+F7 lists elements. With VoiceOver on a Mac, use the rotor (VO-U) to choose headings, links or form controls and then navigate among them; on iOS, swipe up or down to change the rotor setting and flick left/right to move.
3. Turn off the screen — or close your eyes. This is the key step. The point is to experience the page through sound, the way your users do. Looking at the screen while the audio plays defeats the purpose.
4. Navigate, do not just listen straight through. Jump by heading first: does the outline make sense and cover the page? Then list the links: do they make sense out of context? Then tab through a form: is every field labelled, and are errors announced?
5. Try a real task. Complete a sign-up, a search, or an add-to-cart using only the keyboard and the audio. If you cannot, neither can your users.

This kind of pass is exactly the manual step we recommend in how to check if a website is accessible and require in how to run an accessibility audit, because it catches the things automated tools cannot judge — whether alt text is meaningful, whether the heading structure reflects the content, whether the experience actually holds together.

Common things that break the screen-reader experience

A short catalogue of the failures you will hear most often, and what causes them:

• Unlabelled form fields announced as bare "edit text" — fix with real <label> elements (see what is ARIA and when to use it for the cases where a native label is not enough).
• Images with no alt text, where the screen reader falls back to reading a meaningless file name like "I-M-G underscore 4821 dot jpg".
• Fake buttons and links (div/span with click handlers) that are not announced as controls and cannot be operated by keyboard.
• No heading structure, or headings used for visual size rather than meaning, leaving the user with no map of the page.
• "Click here" links that are meaningless when listed out of context.
• Unannounced dynamic updates — content that changes (a filter applies, an error appears, a cart count updates) without telling the screen reader, so the user never knows it happened. This is where ARIA live regions earn their place.
• Keyboard traps in modals and widgets, which strand the screen-reader user because they navigate by keyboard.
• Reading order that does not match the visual order, caused by CSS rearranging content away from the source order.

Each of these is audible the moment you do a screen-reader pass, and most trace back to either missing semantic HTML or missing labels — which is why the fix is so often "use the right element and name it properly".

The bottom line

A screen reader converts a page into speech or braille and lets blind and low-vision users navigate it by jumping between headings, landmarks, links and form fields — switching into a forms mode to type. The major tools are NVDA and JAWS on Windows, VoiceOver on Apple devices, and TalkBack on Android, several of them free or built in. Because the entire experience is generated from your code, semantic HTML — real headings, buttons, lists, labels and landmarks — is the foundation that makes a site usable, and non-semantic markup is the most common thing that breaks it. The best way to understand all of this is to turn on a screen reader, close your eyes, and try to use your own site. For the bigger picture, see what web accessibility is and why it matters; to act on what you find, how to run an accessibility audit.

Want to see whether your pages pass a WCAG accessibility check alongside SEO and performance? Analyse any URL with StackOptic — one report, free, no sign-up.