PDF Accessibility Checker and PDF Accessibility Testing Software for PDF/UA Validation

This is the most consequential thing on the page, so it goes first.

A reporting tool examines a document, applies a set of automated rules, and gives you a list of the problems it recognised. A formal validator tests a document against a published specification, ISO 14289, and returns a conformance decision with the specific clause each failure violates. The output looks similar. What it entitles you to say afterwards is not.

The practical consequence lands on people who assume a clean report is a compliance result. It is not, and the US federal government says so in plain language. The Department of Education job aid on the Acrobat checker states that "the automated checker only identifies a portion of potential issues. Manual testing and inspection are always required to ensure full accessibility compliance." The report even has a status for this, "Needs Manual Check", defined there as "the checker cannot automatically verify this item; manual inspection is required." A document can show zero red items and still fail, because a large share of the criteria were never evaluated by software at all.

None of that makes the Acrobat checker a bad tool. It is genuinely useful, it is already installed on the machines of the people doing this work, and for an author fixing one document it is often the fastest way in. The error is treating its green result as a conformance claim you can put in front of a federal buyer, because Adobe does not publish it as one and, on every page we could reach, does not describe Full Check as a PDF/UA validator.

So the shortlist question is not "which checker finds the most issues". It is: do I need a report that helps a person fix a file, or a conformance decision I have to defend? For the first, use whatever is already on the desktop. For the second, use a validator that names the standard it is testing and the clause it failed on.

A workable sequence, in the order that finds the most problems for the least effort.

Start with a formal validator, not a reporting tool. Run the file through PAC 2026 or veraPDF first. Both are free, both name PDF/UA as what they test, and both will tell you within seconds whether the document has a tag structure at all. If it does not, stop. Everything else on this list is irrelevant until the file is tagged, and the fix belongs upstream in whatever produced it.

Then read the structure, not the score. Open the tag tree and check that headings descend in order without skipping levels, that lists are real list structures rather than paragraphs starting with a bullet character, and that tables carry header cells with a defined scope. These are the conditions that decide whether a screen reader user can navigate the document instead of listening to it end to end.

Use PAC's screen reader preview. This is the single most underrated feature in the category. It renders the document the way assistive technology will encounter it, which exposes reading order problems that no pass or fail line can communicate. A two column report that reads across the columns instead of down them passes most automated checks and is unusable in practice. You will see it in about four seconds in the preview.

Check the things software cannot judge. Is the alternative text a description of what the image conveys, or is it the file name? Is the document title in the metadata a real title, or is it "Microsoft Word - final_v3_REVISED.docx"? Does colour alone carry any meaning? Is the document language declared, and is it right? A checker can tell you an alt attribute exists. Only a person can tell you it is useful.

Finally, test with an actual screen reader if the document matters. For a benefits letter, a permit, a tax notice or anything a member of the public is required to read, ten minutes with NVDA or VoiceOver will find things no rule set covers.

Three names get used interchangeably in this category and they are not interchangeable.

WCAG is the W3C standard that defines success criteria at Levels A, AA and AAA. It was written for web content, and US law leans on it: the Revised Section 508 Standards incorporate Levels A and AA as the federal technical baseline. Many WCAG criteria apply cleanly to a document, some do not apply at all, and a handful have no obvious document equivalent.

PDF/UA is ISO 14289, the standard written specifically for PDF. It says how a conforming file has to be constructed: tagged content, a defined logical structure, semantically correct tags, artifacts marked as artifacts, and so on. It is a file format specification, not a policy, which is exactly why it can be validated by software with far less ambiguity than WCAG.

PDF/UA-2 is the newer part, built against PDF 2.0 (ISO 32000-2). This matters when you choose a validator, because not every tool has caught up. veraPDF states that it validates "PDF/UA (parts 1 and 2)", which is the clearest published position of any tool we checked. If your organisation is moving to PDF 2.0 output, verify part 2 support before you standardise on anything.

The useful mental model: PDF/UA is how the file is built, WCAG is what the reader can do with it. You need both, and they fail differently. A file can conform to PDF/UA and still have useless alt text, which is a WCAG failure a validator will never catch. A file can satisfy every WCAG criterion a human can assess and still be untagged, which is a PDF/UA failure a human will never notice by reading it.

Every product in this category has a commercial reason to blur this boundary. It is worth stating precisely, because misunderstanding it is how a team fails an audit it believed it had passed.

The PDF Association's Matterhorn Protocol organises PDF/UA conformance into 31 checkpoints containing 136 failure conditions. Software can identify most of them. A substantial remainder cannot be decided by any machine, now or later, because they require judgment about meaning rather than structure.

The ones that bite hardest in practice:

Whether alternative text is any good. A checker confirms the attribute is present and not empty. It cannot tell you that "chart.png" describes nothing, or that a five word alt on a complex data visualisation has thrown away the entire point of the figure.

Whether the heading hierarchy reflects the document. Levels descending in order is checkable. Whether H2 is genuinely a subsection of the H1 above it is a reading comprehension task.

Whether reading order makes sense. A defined order is checkable. Whether that order is the one a human would follow through a multi column layout with pull quotes and a sidebar is not.

Whether colour alone carries meaning. Contrast ratios are arithmetic. "Rows highlighted in red require action" is a sentence a machine cannot evaluate against the design.

Whether a table's header associations are correct. Presence of header cells is checkable. Whether the right cells were marked as headers in a nested table with spanning cells is a structural judgment.

This is a property of accessibility itself, not a gap in any vendor's product, and it is why the honest tools ship a "needs manual check" status instead of pretending. Plan for a human pass on documents that carry real consequence, and use automation to make sure that human is never wasting time on problems a script could have caught.

Almost everything written about PDF accessibility checkers assumes a person authored a document and now wants to check it. If your PDFs are generated, by a reporting system, a billing run, a case management platform or a rendering API, that assumption is wrong in a way that changes the whole answer.

Consider a state agency that publishes 3,000 documents a month out of three internal systems. The desktop model says: someone opens each file in Acrobat or PAC, reads a report, fixes what is wrong, saves it. At two minutes a document that is 100 hours a month, forever, and it is 100 hours spent correcting the same three defects over and over because the defects live in the templates upstream, not in the files. Of the tools priced on this page, only veraPDF runs unattended over a batch instead of one file at a time, which is why it is the realistic replacement for the Acrobat checker once volume is the problem.

The alternative is a validation gate. veraPDF is the only tool on this page that supports one, because it has a command line interface and machine readable output. The pattern is short:

Validate every generated document automatically, as part of the job that produces it. A failure is a build failure, not a ticket someone opens next quarter.

Fail the template, not the file. When a document fails, the interesting output is not the document. It is which template produced it, because one template fix corrects every file that template will ever generate, including the ones that do not exist yet. Nothing else in an accessibility program has that leverage.

Keep the desktop tools for the exceptions. PAC's screen reader preview is still the fastest way to understand a reading order problem once the gate has told you which template has one. The two models are complements. Bulk validation finds where the problems are; a person with a good desktop checker works out why.

Sample with a human on a schedule. Automated conformance plus a monthly manual review of a handful of real documents catches the judgment failures the gate structurally cannot. If you are choosing the wider tooling around this, 508 compliance testing software prices nine of the platforms and separates the ones that read web pages from the two that read documents.

Documents that come out of an HTML to PDF step fail differently from documents a person built in a design tool. On generated output, five causes account for most of what PAC, veraPDF or Acrobat will flag, and every one is fixed upstream rather than in the file.

1. Tagging was never switched on. The most common finding by a distance. Headless Chromium emits a tagged PDF through its generateTaggedPDF option, many wrappers leave it off by default, and teams believe they ship tagged output for months before anyone checks.
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.
3. Tables built for layout rather than data. With no th and no scope, a statement becomes a grid of unassociated cells, and a screen reader reads amounts without saying which column they belong to.
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.
5. A later pipeline step stripped the tags. Merging, compressing, watermarking, flattening and some signing steps can silently drop the structure tree even though the render was correct. Validate the file that actually ships, after the last step.

That list changes how a failing batch should be handled. A checker run against 400 generated statements that reports most of them failing is rarely 400 problems. Group the failures by the template that produced each file and they usually collapse into six or seven root causes. Fix those, regenerate, and most of the set comes back clean. What remains splits into files you can simply reissue and files that cannot be regenerated, and only the second group belongs with a PDF remediation service. Under the ADA Title II rule, archived documents posted before your compliance date are often exempt while new output never is, so the pipeline usually deserves the attention before the archive does.

Two habits stop it from happening again. Re-test the template whenever it changes, and validate a small sample of live output every week, because a weekly sample catches the failure a template test never will: a deployment that quietly adds a compression step after the render. Then keep the dated validation reports. If a customer or a regulator asks, a report against a specific file from a specific day is worth far more than an assurance that the system produces accessible output, and the same reports are the evidence behind the document rows of a VPAT and Accessibility Conformance Report.

We sell an HTML rendering API, so read this section knowing what we sell. The argument holds even if you buy nothing from us.

Nearly every problem a PDF accessibility checker reports on a generated document was decided before the PDF existed. Untagged output is a render setting. A missing document title is a metadata field. An undeclared language is one attribute on the html element. Headings out of order, fake lists and tables without header cells are all properties of the HTML template, faithfully carried into the PDF by a renderer doing exactly what it was told.

That is genuinely good news, because it means the work is finite. A remediation team fixing existing files works file by file and never finishes. A team fixing templates fixes each defect once. If you generate documents from HTML, the sequence that removes most of your checker findings is: put real semantic structure in the template, switch tagging on at render time (it is one parameter, and off by default in a surprising number of wrappers), set a document title, declare the language, and then validate what actually came out rather than what you intended. Our comparison of accessible PDF generation covers which HTML to PDF engines emit tagged output and which genuinely target PDF/UA, which is a distinction most of the category collapses.

Two honest caveats. Tagged is not conformant: emitting tags is necessary and not sufficient, and anyone selling you a flag that produces compliance is selling you a future audit finding. And if you have a backlog of documents already published, template work does nothing for it. That backlog is a remediation project with a per page cost, and if you are sizing one, the rates four vendors publish are on our PDF remediation services page. If instead you have to report on all of this to a federal buyer, the rows your generated documents get judged on are set out in our guide to the VPAT and Accessibility Conformance Report.