PDF accessibility checkers compared: Acrobat Pro, PAC 2026 and veraPDF

A PDF accessibility checker reads the hidden structure of a file and reports what software can measure: whether it has tags (the hidden structure that tells a screen reader what each part of the page is), a title, a declared language, alt text on images and header cells in tables. The three checkers most public-sector teams meet are Adobe Acrobat Pro's Accessibility Checker, PAC 2026 from axes4, which is free for Windows, and veraPDF, a free, open-source validator. Each tests against its own rule list, so the same agenda packet can pass one and fail another. None can tell you whether the alt text is right or the reading order makes sense, so a clean report means only that the automated checks passed. This guide compares them as of October 2026 and ends with a free checking routine.

What a PDF accessibility checker can and can't tell you

Software is good at yes-or-no facts about a file. Is there a tag tree? Does every image have alternate text? Software is poor at meaning. The W3C's guidance on evaluation tools puts it plainly: "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so."

The clearest measure of the gap is the Matterhorn Protocol, the PDF Association's list of every way a file can fail PDF/UA-1, the ISO standard for accessible PDF files. Version 1.1 lists 31 checkpoints and 136 failure conditions. By its own count, 87 "can be determined by software alone," 47 "usually require human judgment," and two have no specific test. A figure with no alternative text is a machine check. "Tags are not in logical reading order" is a human one. Our guide to what software fixes and what needs a person maps each WCAG 2.1 AA check for PDFs to who resolves it.

Acrobat vs PAC vs veraPDF: what each checker tests

Adobe Acrobat Pro's Accessibility Checker

Adobe documents the checker as an Acrobat Pro feature. In current versions you open All tools, then Prepare for accessibility, then Check for accessibility. Older versions call it Full Check. Adobe says it "verifies whether the document conforms to accessibility standards, such as PDF/UA and WCAG 2.0."

Results fall into seven categories: Document, Page Content, Forms, Alternate Text, Tables, Lists and Headings. Each rule is marked Passed, Failed, Needs Manual Check or Skipped By User, and an accessibility report summarizes the results. Two rules always need a person. For Logical Reading Order, Adobe's instruction is "Verify this rule check manually." The other is Color Contrast: Acrobat's checker does not test color contrast, and it lists contrast as a manual check every time.

Acrobat is the only one of the three that fixes accessibility problems. For rules such as title, language, tab order and bookmarks, the Fix command repairs the item or opens a dialog for you to complete. Adobe adds that the checker "does not distinguish between essential and nonessential content types," so some reported issues may not affect readability. And as Clemson University's guide notes, it can flag missing alt text but cannot verify its accuracy. A pass on Figures Alternate Text means every figure has alt text, not that the alt text is right.

PAC 2026 from axes4

PAC (PDF Accessibility Checker) is made by axes4 with funding from the German Federal Ministry of Labor and Social Affairs. The current version, PAC 2026 (release 26.1, March 25, 2026), is free to download (opens an external site) and runs only on Windows. axes4 says a Mac version is in development. PAC works offline, and rolling it out across an organization needs axes4's approval under its General Terms.

PAC checks PDF/UA requirements, using the Matterhorn Protocol's test scheme, and WCAG requirements, each on its own tab, and it includes a color contrast check. For the human checks, its screen reader preview shows a sighted reviewer "what the screen reader will read, the structure and order." Quality checks and, in PAC 2026, AI-assisted checks that run on your computer flag likely problems, such as text that looks like a heading but isn't tagged as one. axes4 calls these hints, not official criteria, and says the AI does not check whether alt text or reading order is correct.

PAC gives a summary or a detailed report. It assesses documents rather than repairing them, has no command line for batch work, and handles PDF 2.0 files on a best-effort basis. axes4 is candid about what a clean result means: "If all the check marks are green on the PDF/UA and WCAG tabs, this only means that all automatically checkable requirements have been met."

veraPDF

veraPDF is a free, open-source validator from a consortium led by the Open Preservation Foundation and the PDF Association. Built for PDF/A, the archiving standard, it also validates the machine checks of PDF/UA-1 and PDF/UA-2, the newer part based on PDF 2.0. The current release, 1.30.2 (opens an external site), came out in June 2026. It runs on Windows, Mac and Linux, as a desktop app or from the command line, and accepts whole folders of PDFs, which suits IT staff or vendors validating hundreds of files.

Its built-in accessibility profiles contain only machine-checkable rules, with no list of human checks, no screen reader preview and no accessibility fixes. They contain no contrast-ratio rule, and the Matterhorn Protocol's only color-and-contrast condition is a human check about meaning conveyed by color. The project also publishes an experimental WCAG 2.2 profile, which includes a contrast rule and can be loaded as a custom profile.

Two more you may already have

Microsoft Word's Accessibility Checker (opens an external site) lists errors, warnings and tips in the source document, where problems are cheapest to fix. Allyant's CommonLook PDF Validator (opens an external site) is a free plugin for Acrobat Standard or Pro on Windows that walks you through manual tests.

Side by side

This comparison was written by Ockem. It reflects each tool's own documentation as of October 2026.

Why PDF accessibility checkers disagree

Run the same budget book through all three and expect different counts, for four main reasons.

• Different standards. The ADA Title II and HHS Section 504 rules name WCAG 2.1 Level AA. PDF/UA is a separate ISO standard about how an accessible PDF file is built. They overlap a great deal but are not the same list.
• Different rule lists. PDF/UA fails a file whose metadata lacks the PDF/UA identifier, which no screen reader user would notice. It also fails skipped heading levels, such as an H3 straight after an H1, while Adobe notes that heading order "is not required under WCAG, and is only an advisory technique."
• Different handling of artifacts. Artifacts are content marked as decoration, such as page numbers, so a screen reader skips them. Acrobat and the PDF/UA rules both flag content that is neither tagged nor marked as an artifact. Real content wrongly marked as an artifact is a human check in the Matterhorn Protocol, and PAC adds a quality check for likely cases.
• Presence versus quality. All three can tell whether a figure has alt text. None can tell whether "Chart 1" describes a revenue chart well enough.

Why a PDF passes the accessibility checker but still isn't accessible

A file can show green in every checker and still fall short of WCAG 2.1 AA, because the checks that decide whether people can use it are manual.

• Reading order. Screen reader users hear content in tag order, and a two-column newsletter whose tags run straight across both columns passes every machine check. See logical reading order.
• Alt text quality. A chart in a budget book needs its takeaway, not "chart." See alt text for charts, maps and diagrams.
• Contrast. Acrobat and the PDF/UA profiles do not measure it, and text over a photograph needs a design decision in any tool. Readers with low vision are affected. See PDF color contrast.
• Meaning. Whether a bold line is a heading, which cells are table headers, and whether "the box on the right" works without sight are judgments.

That is why axes4 says a PAC result "can therefore not be legally binding, but it is an indicator."

A free workflow for checking a PDF

1. If you have the source file, run Word's Accessibility Checker and fix what it finds before you export a tagged PDF.
2. Run PAC 2026 on Windows, or veraPDF on any computer, and fix every machine failure.
3. If you have Acrobat Pro, run Check for accessibility and work through its Failed items.
4. Check reading order page by page with PAC's screen reader preview or Acrobat's Tags panel.
5. Read each alt text beside its image and ask whether it says what the image is for.
6. Measure contrast on colored headings, shaded table rows and text over photos.
7. Listen to the first pages with a free screen reader such as NVDA (opens an external site) on Windows. Can you find the headings, follow a table and fill in the form?
8. Record what you checked, the tool and version, who made the manual calls and when. Our guide to proving your PDFs are accessible lists what to keep.

Steps 4 to 7 take judgment, so give them to someone who knows what the document is for.

How Ockem Proof checks a PDF

Ockem Proof, our product, starts where these checkers start and then does the work they leave to you. Every document is checked against a WCAG 2.1 AA rule profile built on veraPDF, the open-source PDF/UA validator, plus Ockem's own detectors for checks the veraPDF PDF/UA rules have no clause for, such as color contrast, reading-order comparison, images of text and language of parts. The check runs when a document is imported and again after every fix.

Three things differ from a checker report.

• A three-state verdict. A document is Compliant (nothing failed and nothing left to review), Needs review (manual checks are outstanding, but nothing has been confirmed to fail) or Failed (confirmed violations remain). A document waiting for a person is never called failed.
• Evidence on every finding. Findings come with a crop of the figure, the text recovered by OCR, per-page reading-order flags or the failing color pairs. Every check Proof asks a person to make points at the exact spot on the page.
• It fixes, then re-checks. One action runs every safe fixer that applies, re-verifies the result with the rule engine, and keeps the new version only if the verdict improves. In Ockem's measurements across 12,689 findings in three document libraries in August 2026, automatic passes cleared 63–74% of defects.

A person still makes the judgment calls. Reading order is confirmed by a person, color changes are never applied without a person's approval, and AI-drafted alt text, titles and form field names are approved by a person before they are written into the file. In Ockem's measurements of production documents in August 2026, the median document needs one manual check, and the 90th percentile needs two. The manual check we most often see left over is logical reading order. Unlike the free checkers, Proof is paid: importing and auditing are free, and you pay when a document is certified, from $59 for a single document down to $15 per document in the 1,000-document pack, where a document is a PDF of up to 50 pages. The WCAG coverage map shows every check and who resolves it.

See it on your own files

You can try one PDF (opens an external site) of up to 10 pages free, with no account, and compare the results with your PAC or Acrobat report. The free PDF inventory tool counts the PDFs on your site, and the WCAG coverage map lists every check Proof runs. For the manual checks, read logical reading order, PDF color contrast and what software fixes and what needs a person.

Questions

This guide explains the rules in plain language. It isn’t legal advice. Check how they apply to your organization with counsel.