Test PDF accessibility: how to check if a PDF is accessible, and what checkers miss

To test whether a PDF is accessible, run it through a checker and then read it with your eyes and ears. PAC, the free PDF Accessibility Checker, tests a large set of PDF/UA and WCAG requirements in seconds and includes a screen reader preview. veraPDF is an open source validator covering PDF/UA parts 1 and 2 machine checks. Adobe Acrobat ships an accessibility checker of its own, and if you are choosing between them, our PDF accessibility checker comparison prices six tools and shows which ones formally validate PDF/UA. All of them will tell you a clean file is clean. None of them can tell you a clean file is usable.

That gap is the whole subject of this piece. Accessibility checkers verify structure, and structure is the part a machine can see. Whether the alternative text on a chart describes what the chart shows, whether your heading levels match the real hierarchy of the document, whether the reading order makes sense to a human being: those are judgments, and a passing report says nothing about them. Teams that ship on a green checkmark are the ones who get surprised in an audit.

What the free PDF accessibility checkers actually test

Three tools cover almost all practical testing, and they do different jobs.

PAC is the one most accessibility specialists reach for first. It is free, it has been maintained since 2010, and it is funded by the German Federal Ministry of Labor and Social Affairs rather than by a vendor selling remediation services. You drag a file onto it and get a result immediately. It checks against both PDF/UA and WCAG, which matters because those are the two standards a US contract is likely to name. The feature that earns its place is not the pass or fail list at all: it is the structure and screen reader preview, which lets a sighted person see the document the way assistive technology will encounter it. PAC calls this the visual check, and it treats it as a required step rather than an optional extra. That framing is correct and worth copying.

veraPDF is an open source, permissively licensed file format validator, built with funding from the European Union PREFORMA project. It covers every PDF/A part and conformance level, and it performs PDF/UA parts 1 and 2 machine checks. It is the right tool when you need a definitive, scriptable verdict on format conformance, and it is the one to reach for if you want validation inside a build pipeline rather than on a desk. Its output is a validation report describing conformance to specific flavours, which is the kind of artifact an auditor will actually accept.

Adobe Acrobat includes an accessibility checker that most organisations already have a license for, which is often the deciding factor. It is convenient and it catches the common structural failures. It is also the tool whose report gets over trusted most often, because it lives inside the application people use to look at the file, and a green result next to the document feels more conclusive than it is.

Use at least two. They disagree more often than you would expect, mostly at the edges of tag interpretation, and a file that satisfies both is in genuinely better shape than a file that satisfies one.

How do I know if a PDF is accessible?

Run a checker, then do four things by hand. First, tab through the document and confirm the focus order matches the visual order. Second, turn on a screen reader, or use the PAC preview, and listen to the first page: if a two column layout is read across the columns, the reading order is broken no matter what the report said. Third, read every alternative text string out loud and ask whether someone who cannot see the image would learn anything from it. Fourth, check that data tables announce their headers with each cell.

That takes about ten minutes per document and it catches the failures that matter most to an actual reader. If ten minutes per document sounds unaffordable at your volume, that is the correct signal to stop testing documents one at a time and start fixing the thing that generates them.

Why a passing checker report is not compliance

The clearest way to see the limit is to look at how the standard itself is organised. The PDF Association publishes the Matterhorn Protocol as the conformance testing model for PDF/UA. It lists every possible violation as 136 failure conditions grouped into 31 checkpoints. Most of those conditions can be identified by software. A meaningful number cannot, and require human judgment instead.

The split is not a shortcoming in any particular tool. It is a property of the problem. Consider what each type looks like in practice:

• A machine can see that an image has no alternative text at all, that a table has no header cells, that the document has no language set, that a heading level was skipped, or that the tag tree is missing entirely.
• A machine cannot see that the alternative text reads "chart.png", that a paragraph was tagged as a heading because it happened to be bold, that a decorative flourish was described in detail while a data visualisation was marked decorative, or that the reading order technically exists but sends the reader through a sidebar in the middle of a sentence.

Both categories fail a real user equally. Only one of them fails a checker. This is why an accessibility statement that cites a tool result and nothing else tends not to survive contact with a procurement reviewer who knows the field.

The failures that show up in generated PDFs specifically

Documents produced by a rendering pipeline fail differently from documents produced by a person in a design tool. If your PDFs come out of an HTML to PDF step, these five account for most of what a checker will flag, and every one of them is fixed upstream rather than in the file.

1. Tagging was never switched on. The single most common finding. Headless Chromium can emit a tagged PDF through the generateTaggedPDF parameter, and many wrappers leave it off by default. Teams often believe they are producing tagged output for months before anyone checks. One flag, entire class of failures.
2. The source markup has no structure to carry across. A template built from styled div elements sized to look like headings produces a tagged PDF with no headings in it. The renderer translates structure, it does not invent it. Fix the template, not the file.
3. Tables built for layout rather than data. A table with no th and no scope becomes a grid of unassociated cells, so a screen reader reads values with no idea which column or row they belong to. In a financial statement that is the difference between a usable document and a meaningless one.
4. CSS reordered the page and the tags did not follow. Flexbox order and grid placement change what the eye sees without changing the DOM, and the tag tree follows the DOM. The document looks right and is announced in an order nobody designed.
5. A later pipeline step stripped the tags. This is the one that wastes the most time, because the render was correct. Merging, compressing, watermarking, flattening or some signing steps can silently discard the structure tree. Always validate the file that actually ships, after the last step, not the file that came out of the renderer.

The pattern across all five is that generated documents have a single point of leverage. Fix the template and the render settings once and every future document is correct, which is a fundamentally better economic position than remediating files individually. Our guide to accessible PDF generation from HTML covers the render side in detail, including which engines target PDF/UA and which only emit tags.

What to do when a batch of documents fails

The realistic scenario is not one document. It is a checker run against an archive of four hundred statements, and a report saying most of them fail. At that point testing stops being a technical task and becomes a triage problem, and the useful move is to sort by cause rather than by file.

Group the failures by the template that produced them. In a generated archive, four hundred failing files will usually collapse into six or seven root causes, and fixing those regenerates most of the set correctly. Then separate what is left into documents that must be remediated by hand because they cannot be regenerated, and documents that can simply be reissued. Remediation work is slow, specialised and easy to lose track of, so it helps to treat the remaining list as a real queue with each file routed to a named owner and a due date attached, rather than as a spreadsheet someone updates when they remember. The regeneration path should be automated; only the genuinely manual remainder deserves human hours.

One caution on prioritisation. Under the Department of Justice ADA Title II rule, conventional electronic documents posted before a covered entity compliance date carry an exception, unless they are currently being used to apply for, access or participate in a service. Documents created after the date do not. So the archive is often the lower priority, and the pipeline producing new documents every day is the higher one. That is the opposite of how most remediation projects get scoped.

Is there a free PDF accessibility checker?

Yes, two good ones. PAC is free and is the tool most specialists use for PDF/UA and WCAG checking, including its screen reader preview. veraPDF is open source and free, and is the better choice for automated validation in a pipeline because it produces a machine readable conformance report. Between them you can validate to both standards at no cost, which removes the last excuse for shipping untested documents. Neither replaces the manual pass.

How often should you test?

Test the template whenever it changes, and test a sample of live output on a schedule. For a pipeline generating documents continuously, a weekly sample of a handful of real files catches regressions early, and it catches the pipeline problem that a template test never will: a downstream step quietly stripping tags after a deployment.

Keep the reports. If an accessibility question ever arrives from a customer or a regulator, a dated validation report against a specific file is worth considerably more than an assurance that the system produces accessible output. Those reports are also the evidence behind the document rows when you complete a VPAT and Accessibility Conformance Report, which is the form a public sector buyer will ask for by name. The same logic applies to the documents themselves: being able to show exactly what a given statement looked like on the day it was issued turns an argument into a record.

The short version

Checkers verify structure and they are essential, but structure is the floor rather than the ceiling. PAC and veraPDF are free, fast and worth running on everything, and they are the only two tools on a typical 508 compliance testing software shortlist that open a PDF at all. Then spend ten minutes with a screen reader on a representative document, because the failures that hurt real users are exactly the ones no machine can flag. And if the documents are generated, put the effort into the template and the render settings, where one fix corrects every file you will ever produce.