Almost every accessibility programme we audit reports the same number: ninety-something percent of frontend developers say they “test with a screen reader.” Ask them to demonstrate, and the demo is usually the same three keystrokes — turn it on, tab through the page, turn it off. That is not testing. That is checking a box.

The reason this happens is structural, not lazy. A screen reader is not a tool you can pick up the way you pick up a new linter. It is a different interaction model with its own modal state, its own shortcut grammar, and a set of conventions that make sense only after you have used it for several hours of real work. Until you cross that threshold, the tool tells you almost nothing — and worse, it tells you things that are wrong, because the announcements you hear depend on the reader’s mode, the browser’s accessibility tree, and the platform’s IME layer in ways that are not obvious from outside.

Fluency, for our purposes, is the point at which you can hand a colleague a broken component, take their keyboard, and reproduce the bug with the screen reader running — without looking at the screen, without referring to a cheat sheet, and without making the announcement worse than it would be in real use. Familiarity is the point at which you have heard a screen reader. The gap between the two is roughly thirty to thirty-five hours of deliberate practice.

The market has three screen readers that matter for desktop web work: NVDA on Windows, VoiceOver on macOS and iOS, and JAWS on Windows. Each one has a body of users large enough that ignoring it would be a real bet, and each one announces the same markup slightly differently. A fluent developer can drive at least two of them.

Our recommendation, after watching dozens of developers cross the threshold, is unambiguous: start with NVDA on Windows and VoiceOver on macOS. Both are free. Both are pre-installed (VoiceOver) or installable in under five minutes (NVDA). Both are used by enough real users — NVDA holds approx. 65% of Windows screen-reader market share in the most recent WebAIM survey, VoiceOver dominates mobile and a meaningful share of macOS — that what you learn transfers immediately to bugs you can ship a fix for. JAWS is the third tool, not the first, even though it is still the screen reader with the largest enterprise install base. Three reasons.

The three reasons to skip JAWS at the start are pedagogical, not political. First, JAWS and NVDA share a mental model — Windows browse mode versus focus mode, the same Insert-based command prefix, the same virtual buffer — so once you can drive NVDA, ninety percent of the JAWS commands you actually need are a glossary lookup away. Second, JAWS has accumulated decades of “smart” inference: it tries to fix bad markup before the user hears it, which means a bug that JAWS papers over will still ship to NVDA users. NVDA’s deliberately conservative behaviour makes it the better reference reader when you are trying to learn what is broken. Third, JAWS’s licensing friction — activation, the forty-minute trial mode that nags every reboot — is a learning-tax you do not need to pay until you are confident enough to spend it.

VoiceOver pairs with NVDA rather than competes with it because the two readers represent the two dominant interaction models. NVDA (and JAWS) use the “PC cursor” model: a virtual buffer that lays out the page as a linear document and a separate focus that follows tab order. VoiceOver uses a single VoiceOver cursor that lives on top of the focus, navigated by the rotor and by VO+arrow keys. A developer fluent in only one model will write code that announces well in their reader and badly in the other. Learning both at once is the only reliable way to feel the difference.

The week-one programme has one rule: turn the monitor off. Not dimmed, not minimised, not “I’ll close my eyes” — physically off, or covered with a piece of card if your display is the only one in the room. The point is to remove the option of cheating. A sighted developer’s instinct, the moment a screen reader says something confusing, is to glance at the screen and resolve the ambiguity visually. That instinct is the single largest reason “I tested with a screen reader” does not catch real bugs.

Plan for three sessions of about ninety minutes each in week one, with at least a day between sessions so the muscle memory has time to consolidate. Each session has one job. The first builds the basic command grammar. The second forces a real interaction. The third tests retention under a small amount of stress.

The second through fourth weeks of practice should add up to roughly twenty hours of work — two ninety-minute sessions a week, plus a small amount of incidental use while you do your day job. The goal in this stretch is to internalise the two things that confuse new screen-reader users more than anything else: the distinction between browse mode and focus mode, and the difference between what the rotor sees and what tab order sees.

The single most common confusion in week two is the moment a developer presses an arrow key in NVDA, expects the virtual buffer to move, and instead hears the focused combobox open its options list. That is browse mode switching to focus mode automatically because the focus landed on an element that NVDA classifies as an “application” widget. New developers experience this as the reader misbehaving. It is not — it is the reader doing exactly what the spec asks. Once you have heard it ten or fifteen times you stop being surprised; until then, plan to be surprised approximately every other session.

The week-three pattern is forms. Build a private testing page with eight or ten controls: a required text input with an inline error, a date picker, a multi-select, a custom-styled checkbox, a disabled button that becomes enabled, a “show password” toggle, a phone-number field with a country-code selector, and a submit button that triggers a server-side validation summary. Monitor off, navigate through it five times — first with NVDA in browse mode, then NVDA in focus mode, then NVDA again with the verbose announcement setting turned up (Insert+Z, more on that in section five), then VoiceOver with the rotor, then VoiceOver without the rotor. The same form will sound different five times. That is what fluency feels like from the inside: noticing that the same markup tells five different stories, and being able to predict in advance which one will play.

Week four is navigation. Take a real, complex site — a documentation portal, a workplace dashboard, an e-commerce category page — and try to find a specific piece of information using only screen-reader shortcuts. Use H to jump headings. Use D (NVDA) or VO+U then “Landmarks” (VoiceOver) to jump landmarks. Use 1 through 6 to jump to a particular heading level. By the end of week four, the navigation shortcuts should be reflexes rather than choices, the way tab and shift-tab already are.

Once the user-mode commands are reflexes, the next jump is into the developer-facing surfaces of each reader. These are the modes and shortcuts the manuals bury — partly because they are aimed at developers, partly because they are noisy enough that a daily user would not want them on. Three are worth knowing immediately.

Two further habits will save more time than any single shortcut. First, leave NVDA’s speech viewer pinned on a second monitor (or in a corner of your one monitor) while you develop. The verbatim log of every announcement is to screen-reader work what the dev-tools console is to JavaScript: the difference between guessing and knowing. Second, learn to read the accessibility tree in your browser’s dev tools — Chrome’s Accessibility pane, Firefox’s Accessibility Inspector, Safari’s Audit tab. The reader announces what the accessibility tree contains, not what the DOM contains, and the two diverge often enough that you cannot debug live regions, ARIA, or shadow DOM without reading the tree directly.

A confusion to flag now, because it eats hours in weeks two and three: reading mode versus focus mode is not the same axis as “the page is interactive” versus “the page is a document.” NVDA switches into focus mode automatically when the focus lands on a control with role=“application”, or on a contenteditable, or on certain custom widgets that the reader heuristically classifies as interactive — regardless of whether the page is mostly static. Conversely, a richly interactive single-page app whose root element is a main landmark and whose widgets are well-marked-up native buttons will stay in browse mode for almost all of a user’s session. The mode is a property of the focused element, not a property of the page.

The numbers below come from informal tracking of about eighty developers — frontend engineers, QA leads, accessibility specialists in training — across three years of corporate workshops and one-on-one mentoring. They are not a research study. They are good enough to plan against. Two assumptions: deliberate practice (monitor off, real tasks, not “I left NVDA running in the background while I coded”), and a fixed reader pairing (NVDA on Windows and VoiceOver on macOS).

”Semi-fluent” is the realistic destination for most sighted developers and is, in practical terms, all you need to be a good contributor to an accessible product. Genuine fluency — the level at which you could plausibly substitute for a daily screen-reader user during a usability review — is more like one hundred and fifty hours and a year of incidental practice, and most working developers do not need it. Aim for semi-fluent, schedule the forty hours, and accept that anything beyond that comes from doing the day job with a reader running and a willingness to slow down.

One last benchmark to set expectations honestly: the developers who plateau, in our experience, plateau between the ten-hour and twenty-hour mark. The cause is almost always the same — they stop turning the monitor off. They tell themselves that they are now “good enough” to test with the screen on, the screen reader running in the background, and visual confirmation available whenever the audio is ambiguous. They are not. The sixteen hours between “useful” and “comfortable” require the monitor off because that is the stretch where the reader’s announcements become information rather than noise. Without that pressure, the brain reverts to vision and the reader’s voice fades into wallpaper. If you find yourself slowing down, it is almost always the monitor.

The reason “test with a screen reader” produces such weak results across the industry is not that the tool is hard to learn — forty hours is genuinely not a lot of time — but that the learning is uncomfortable in a specific way. Turning the monitor off makes a sighted developer feel inept in a way that is unusual in our profession. We are accustomed to being the people who figure things out; the screen reader makes us, for a few hours at a stretch, beginners again. That discomfort, and not the keystrokes, is the actual obstacle.

The path through is the one above: NVDA and VoiceOver, three sessions in the first week with the monitor off, forms and modes in weeks two through four, developer-mode shortcuts as soon as the user-mode shortcuts are reflexes, forty hours total before you can be trusted with a serious pre-release sweep. None of it is novel. The work the industry has not done is treating it as work — scheduling the hours, defending them from other commitments, accepting that the first ten of those hours will feel useless until they suddenly do not.

If you ship a frontend, the version of you on the far side of those forty hours is a substantially better engineer than the version that started, in ways that will show up not only in your accessibility work but in your understanding of focus order, of progressive enhancement, of what the browser is actually doing under the hood. The screen reader is the cheapest distributed-systems lesson available to anyone who writes for the web. The price is the monitor off and a few weekends.