Acrobat's accessibility checker vs PAC: what each report means, and why a pass is not conformance

"It passed the checker" is the most common sentence in PDF accessibility and the least informative, because it depends entirely on which checker and what it was checking for. This guide compares the two tools most people use, Adobe Acrobat's built-in checker and the free PAC, explains why they disagree, and sets out how to read either report without over-claiming.

Acrobat's checker: Adobe's rules

Acrobat Pro's checker lives under Prepare for accessibility > Check for accessibility (older versions called it Full Check). Adobe's documentation describes it as looking "for common elements that need further action, such as scanned text, form fields, tables, and images", and its results come in three states: passed, failed, and Needs Manual Check, which Adobe defines as an item the checker "couldn't check automatically". The rules are Adobe's own. Some are document-level (Accessibility permission flag, Image-only PDF, Tagged PDF, Primary language, Title, Bookmarks, Tab order, Character encoding), some are tag-level (Figures alternate text, table headers, list structure, heading nesting), and two of the most important, Logical reading order and Color contrast, are always manual. Adobe's Bookmarks rule is a good example of a house rule: it fails a document of 21 or more pages with no bookmarks paralleling the structure, a threshold that appears in no standard.

PAC: the PDF/UA and WCAG checker

PAC, the PDF Accessibility Checker, is free and has been in use since 2010; it is funded by Germany's Federal Ministry of Labor and Social Affairs. Its own description is that it "can check many PDF/UA and WCAG requirements at the touch of a button" and "also supports the required visual check" through a screen reader preview and a structure preview that shows a sighted tester what a screen reader would read and in what order. Results come as a summary or a detailed report, and it needs no admin rights to install. The release history runs PAC 3, PAC 2021, PAC 2024, and now PAC 2026, which expands the existing tests with AI-assisted checks intended to reduce manual testing. PAC's PDF/UA tests are organised around the Matterhorn Protocol, which is why its findings carry checkpoint numbers such as 06-002 or 14-003.

Why they disagree

A third option: veraPDF

For teams that need validation in a pipeline rather than a desktop, the open-source veraPDF validator checks PDF/A and PDF/UA syntax from the command line and publishes validation profiles including PDF/UA-1, PDF/UA-2, and WTPDF. It reports rule-by-rule against the specification clauses and is well suited to continuous integration for generated documents; see tagged PDFs from HTML. Like the others, it validates syntax and cannot judge meaning.

How to read any report

1. Separate errors, warnings, and manual items. Errors are machine-decidable failures against the tool's rule set; warnings are usually possible problems; manual items are decisions the tool has explicitly handed to you.
2. Fix document-level items first. Title, language, permissions, and tagging at all are quick and unblock everything else; the document settings guide lists them.
3. Work the tag-level errors next. Missing alt text, untagged content, missing table headers, and list structure are the bulk of most reports.
4. Then do the human checks, every time. Reading order, heading logic, whether tables are really tables, whether alt text says the right thing, and a screen reader pass. The Matterhorn Protocol itself classifies 47 of its 136 conditions as usually requiring human judgement, and WCAG's outcome-based criteria go further. The PDF/UA versus WCAG guide explains the gap.
5. Record what was checked and by whom. A dated report plus a note of the manual checks is evidence; a screenshot of a green tick is not.

Watch for false positives and false comfort

Checkers can flag correct things: a running header properly marked as an artifact may appear as "untagged content" in an unsophisticated tool, and a Figure with empty alt text may be a deliberate decorative marking. They can also pass wrong things, as the table above shows. Neither tool certifies conformance, and no automated result should be described as compliance with WCAG, PDF/UA, the ADA, or Section 508. The free DocAccessible PDF checker follows the same principle: it reports machine-detectable structural and PDF/UA-oriented findings and keeps the items that still need a person visible in the same report.

Frequently asked questions

Sources

The statements above rest on the primary sources below. Where a source is a law or standard, the version and date named in the text are the ones checked on the review date. This guide is general information, not legal advice.

1. Adobe: Create and verify PDF accessibility (Acrobat Pro) . The checker's rules, the Needs Manual Check status, and the wording of the Bookmarks and Title rules.
2. PAC: PDF Accessibility Checker . Funding, history since 2010, PDF/UA and WCAG scope, screen reader preview, and the PAC 2026 release.
3. PDF Association: Matterhorn Protocol 1.1 (PDF) . 87 machine-decidable, 47 human-judgement, and 2 untested failure conditions.
4. veraPDF documentation: CLI validation
5. veraPDF validation profiles: PDF/UA Part 2 rules