Guide
Which screen reader to test PDFs with
NVDA, JAWS and VoiceOver disagree about PDFs in specific, documented ways. Which to use, what each one hides, and what a disagreement between them means.
About 11 minutes · moderate
The short answer
Test with NVDA and Acrobat Reader on Windows. Free, strict, and the combination most likely to surface a real problem.
Then, if you can, VoiceOver on macOS and a browser’s built-in viewer, because a meaningful share of readers never open Acrobat at all.
What each one does differently
NVDA — free, Windows
The reference for testing. Open source, updated frequently, and used by a large share of the people who file document accessibility complaints.
Strict about structure. If the tree is wrong, NVDA reads it wrong. It does not silently repair anything, which is exactly what makes it useful — you hear the document as it actually is.
Announces tags precisely. Headings by level, lists with item counts, tables with row and column position, links as links. If your structure is right, you can hear that it is right.
Its blind spot is that it is Windows-only and its behaviour in browsers’ built-in PDF viewers is noticeably weaker than in Acrobat Reader, so a browser test with NVDA can look worse than users experience elsewhere.
Essential keys: H next heading, 1–6 by level, T next table, K next link, G next graphic, Ins+F7 the elements list, Ins+↓ read all.
JAWS — commercial, Windows
The most-used reader in corporate and government environments, which makes it the one your document is most likely to be judged by in a procurement context.
More forgiving than NVDA. JAWS has decades of PDF-specific handling, including heuristics that reconstruct a reading order when the tags are poor. Useful for users, dangerous for testing: a document JAWS handles gracefully may be unusable in NVDA.
Better with tables and forms than either of the others. If your document is a complex form, JAWS is the one that will tell you whether it is workable in practice.
Its blind spot for testing is precisely its strength for users — it hides structural problems by working around them.
VoiceOver — free, macOS and iOS
Built in, so every Mac user has it, and the only realistic option for testing on iOS.
Different model. VoiceOver in Preview reads PDFs in a way that leans more on layout than on structure, so a badly tagged document can sound better than it is. In Safari’s PDF viewer the behaviour differs again.
Very good at what it does well — reading order in a clean document, language switching, and Hebrew and Arabic pronunciation, which matters if that is your content.
Its blind spot: it will not reliably tell you that your tags are wrong, because it does not depend on them as heavily.
Essential keys: VO+A read all, VO+U the rotor, VO+→/← move. VO is Ctrl+Option.
Narrator — free, Windows
Improved substantially in recent Windows releases and worth knowing exists, but its PDF handling is behind the other three. Not a primary test tool.
What a disagreement tells you
This is the most useful thing in this guide, so it is worth stating on its own.
When two readers describe your document differently, the difference is not a reader bug. It is a place where your structure does not determine a reading, and each reader has resolved the ambiguity its own way.
Common cases:
Reading order differs. Some elements are unreachable through the tree, so one reader is falling back to layout order. Usually untagged content — condition 01-005.
One reader announces a heading and another does not. The element is probably tagged with a role that maps to a heading through a /RoleMap that one reader honours and another does not. Use the standard tags.
A table reads as a table in one and as prose in another. The table structure is incomplete — rows without cells, or cells outside rows. One reader is repairing it, the other is giving up.
The language changes in one reader only. /Lang is set somewhere unexpected, or the XMP and catalog disagree.
In each case, fixing the underlying ambiguity is the answer. Picking whichever reader gives the nicest result and declaring victory means shipping a document that fails for everyone using the other one.
A realistic testing setup
If you do this occasionally: NVDA in a Windows VM, plus VoiceOver on the Mac you already have. Total cost: nothing.
If you do this professionally: NVDA and JAWS on Windows, VoiceOver on macOS, and one mobile pass with VoiceOver on iOS or TalkBack on Android. JAWS has a 40-minute demo mode that restarts on reboot — legitimate for testing, and enough for most documents.
What to test in: Acrobat Reader first, then whatever your readers actually use. For a document published on a website, that is very often a browser’s built-in viewer, and the built-in viewers are consistently worse than Acrobat Reader. Knowing how much worse for your document is worth ten minutes.
Using it well
Do not read the whole document. Use the testing script — a fixed sequence of about ten minutes that hits the things checkers cannot decide.
And listen for the specific thing rather than a general impression. “It sounded fine” is not a test result; “the second column of page 4 is read before the first” is.
Frequently asked questions
If I can only test with one, which?
NVDA with Acrobat Reader on Windows. It is free, it is the most widely used screen reader among people who report document problems, and it is the least forgiving of the three — which is what you want in a test tool. A document that reads correctly in NVDA reads correctly nearly everywhere.
Is VoiceOver enough on a Mac?
For a first pass, and it is better than not testing. But VoiceOver's PDF support in Preview differs substantially from Acrobat's on Windows, and it is more forgiving of structural problems — it falls back to layout order more readily, which can make a document with no usable structure sound acceptable. Treat a VoiceOver pass as necessary, not sufficient.
The three readers disagree about my document. Which is right?
The disagreement is the finding. Readers diverge when the structure is ambiguous, so a document that reads three different ways has structure that does not determine a reading — and every one of those readers is a user. Fix the ambiguity rather than picking a winner.
Does the PDF viewer matter as much as the screen reader?
More, in some cases. The same NVDA reading the same file gives different results in Acrobat Reader, Edge's built-in viewer and Chrome's, because each viewer exposes the structure tree differently. Test in the viewer your readers actually use, and if you do not know, test in Acrobat Reader and one browser.
Related failure conditions
- 09-001 Tags are not in logical reading order The order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
- 11-001 Natural language for text in page content cannot be determined No /Lang is in effect for some text: neither on the catalog, nor on an enclosing structure element, nor on a marked-content sequence.
- 13-004 Figure tag alternative or replacement text missing A Figure element has neither /Alt nor /ActualText. Every Figure must have one or the other; if the image is decorative it should be an artifact instead of a Figure.
- TG-RTL-002 A right-to-left run has no language declaration The document declares en-US at the catalog and never overrides it, so Hebrew paragraphs inherit English.
Check your own file. Taggart's validator is free and unlimited — no page cap, no watermark, and no account at all up to 60 pages.
Last updated .