A PDF that looks fine on screen can be unusable for a reader who uses assistive technology. A sighted reader sees headings, columns, and pictures. A screen reader sees only what the PDF's internal structure tells it: if the document is untagged, the reader gets a stream of text in an unpredictable order, with no headings to navigate by and no descriptions for images. If the reading order is wrong, a two-column article reads across the columns instead of down them. If images have no alt text, they are simply skipped or announced as meaningless objects. None of these problems is visible in a normal visual check, which is why accessibility needs its own check.
The PDF Accessibility Checker performs that check in your browser. You provide a PDF, and it reports on the structural features that make a document accessible: whether it is tagged, whether it has a logical reading order, whether images carry alt text, whether headings form a proper hierarchy, whether tables have header rows, and whether text has sufficient contrast. The check runs locally, so a document containing personal or unpublished content never needs to leave your device.
How the tool works
The central concept is tagging. A tagged PDF contains an invisible structure tree alongside the visible content: paragraphs, headings at their levels, lists, tables with header cells, figures with alt text, and links. A screen reader reads that tree, not the raw drawing commands, so the tree determines what the reader experiences. An untagged PDF has no tree, and the reader must guess the structure from the positions of text on the page — a guess that is often wrong for multi-column layouts, sidebars, and tables.
The checker examines that tree and the document's metadata. It checks whether the document is tagged at all, and whether the language is declared, because a screen reader needs to know which language's pronunciation rules to use. It checks the heading hierarchy: a document should start with a level-1 heading and proceed without skipping levels, so that a reader can navigate by headings the way a sighted reader scans them visually. It checks images for alt text, distinguishing decorative images — which should be marked as artefacts, meaning "skip this" — from informative images, which need a text description. It checks tables for header rows, so that a reader can hear the column heading announced for each cell rather than a bare value. It checks reading order by following the structure tree's sequence and comparing it with the visual layout. And it checks contrast by comparing text colour with background colour against established thresholds, because low-contrast text is hard to read for many people, not only screen reader users.
The result is a report, not a verdict. A checker can list the problems it found and their locations, but it cannot judge whether an alt text description is actually good — only that one exists — or whether the reading order feels natural to a human reader. Treat the report as a work list, and treat a clean report as "no machine-detectable problems found", not as a guarantee of accessibility.
A worked example
Imagine a 24-page report that you run through the checker. The report comes back with six issues: three images without alt text, two tables without header rows, and one heading hierarchy problem where a level-3 heading follows a level-1 heading with no level-2 heading between them. Add them up — 3 + 2 + 1 = 6 — and you have a concrete, fixable list rather than a vague feeling that the document might have problems.
Fix them in order of impact. The heading problem affects navigation through the whole document, so fix it first: either insert the missing level-2 heading or change the level-3 heading to level 2, depending on what the content actually means. Next, mark the tables' first rows as header rows, so that a screen reader announces the column heading for each cell. Then write alt text for the three images — or mark them as decorative if they carry no information, such as a purely ornamental divider. A decorative image marked as an artefact is correctly handled; an informative image marked as decorative is a lost piece of content, so the decision matters and only a human who understands the image can make it.
Re-run the checker after fixing. The count should fall from six to zero, and if it does not, the remaining issues are listed with their locations, so you can find them rather than search the whole document. That loop — check, fix, re-check — is the practical workflow, and it works best when it starts early: fixing accessibility in the source document, before it becomes a PDF, is far easier than repairing a finished PDF's structure tree afterwards.
A useful extra step is to test with an actual screen reader, even briefly. Open the PDF, navigate by headings, and listen to how a table reads. A checker can confirm that a table has a header row; only listening tells you whether the header text actually makes sense as a label for the cells beneath it. Machine checks catch the structural problems; human checks catch the sense problems.
Common mistakes
The most common mistake is assuming a PDF is accessible because it looks good. Visual quality and structural quality are unrelated: a beautifully typeset document from a scanned image has no text layer at all, and a plain document with proper tags can be fully accessible. Never judge accessibility by appearance; run the check.
The second mistake is writing alt text that repeats the caption or says nothing. Alt text such as "image" or "chart" tells a screen reader user nothing they did not already know, and alt text that duplicates a caption wastes their time by making them hear the same information twice. Good alt text conveys the information the image carries: for a chart, the trend and the key values; for a diagram, the relationships it shows; for a photograph, the content that matters to the document's argument. If the image carries no information, mark it decorative instead.
The third mistake is treating a clean checker report as proof of accessibility. Checkers test what machines can test: presence of tags, presence of alt text, heading order, contrast ratios. They cannot test whether alt text is accurate, whether reading order matches the author's intent in a complex layout, or whether the document is understandable. A clean report is a necessary condition, not a sufficient one, and for documents that will be widely distributed, a manual review with assistive technology remains the standard.
The fourth mistake is fixing the PDF instead of the source. Accessibility repairs made directly to a PDF are lost the next time the document is regenerated from its source. Fix the source — the Word document, the design file, the HTML — and regenerate, so that every future version carries the fixes. Reserve direct PDF repair for documents whose source no longer exists.
Honest limitations
A checker reports; it does not fix. It will not write alt text for you, repair a reading order, or restructure a document — those are authoring decisions that require understanding the content. It also cannot check scanned PDFs that have no text layer until they have been through OCR, and OCR introduces its own errors, which the checker cannot distinguish from the original text. Contrast checks depend on the colours as stored in the file, which may differ from how a particular viewer renders them. And some accessibility requirements, such as whether link text is descriptive ("read the full report" rather than "click here"), need human judgement that no automated check can supply reliably.
Closing
Check the structure, not just the appearance: tags, language, heading order, alt text, table headers, reading order, and contrast. Fix the source, re-check, and listen to the result with a screen reader for the problems no machine can judge. To check the quality of OCR in scanned documents, use the PDF OCR Quality Checker, and to recover structure from PDFs generally, use PDF to Markdown. For making scanned documents readable in the first place, see How to Make a Scanned PDF Searchable With OCR.