How to verify PDF accessibility remediation at scale

Checking one remediated PDF is an afternoon’s skill: load it into a screen reader, put it through a validator, form a view. Forty thousand pages defeat that habit, and not for the arithmetic reason most teams reach for first. Time is the obvious constraint. The real one is that what the habit yields — a private conviction that the file is fine — does not survive contact with an auditor.

So here is the shift worth making before you build anything: verification is not a quality check, it is an evidence-production process. The question it has to answer is not whether the remediation worked. It is whether you can demonstrate, months from now, to someone with no reason to believe you, that it did. Those are different questions, and they build different programmes. The first ends at a number. The second treats the number as the least interesting thing it produces.

Most compliance offices over-invest in the score and under-invest in reproducibility. They can tell you their backlog averages 96%. They cannot tell you which checker produced that, on what date, against which sample, or whether anyone outside the vendor has opened one of the files. The seven steps below build the second kind of programme, in the order the evidence accumulates.

Table of contents

• Step 1: Run a named checker against every processed file
• Step 2: Open the tag tree and check reading order by hand
• Step 3: Test with a screen reader, not just a checker
• Step 4: Verify form fields and tab order separately
• Step 5: Replace full manual review with a defensible sampling plan
• Step 6: Build the audit trail auditors actually ask for
• Step 7: Automate verification once volume outgrows sampling
• FAQ
• Conclusion

Step 1: Run a named checker against every processed file

Start with PAC 2026, the free desktop checker maintained under the PDF/UA Foundation and hosted by axes4. It tests the machine-verifiable WCAG A/AA and PDF/UA (Matterhorn) conditions and returns a score computed as checks passed divided by checks run, per standard. Not an assessment. A ratio.

The word doing the work here is named. A score from "our compliance engine" is unfalsifiable, which makes it worthless as evidence however high it is. A score from PAC 2026 is a claim an auditor can walk to their own machine and re-run. Reproducibility, not magnitude, makes a number admissible.

Run veraPDF alongside it on at least a subset. The two validators can disagree on how to read the same checkpoint, and that disagreement is information rather than a defect. Where they agree, you have a finding. Where they diverge, you have found the checkpoint that deserves a human in step 3.

The operator detail nobody leads with: PAC 2026 checks one file at a time, on Windows. Fine for a hundred files, unworkable for a hundred thousand. That gap is why step 7 exists — but do not jump to it. A checker you have run yourself against your own documents is the only way to learn whether a vendor's dashboard number and PAC's number measure the same thing at all.

Verification rarely runs in isolation from an organisation's other compliance work, and the same teams usually keep a parallel audit trail for data privacy. This roundup of GDPR compliance software covers that adjacent side of the governance function, useful context if you are mapping accessibility verification onto a broader programme.

Step 2: Open the tag tree and check reading order by hand

A passing score confirms structure exists. It does not confirm the structure is right, and reading order is where that gap opens widest. Open the tag tree in Acrobat or a PDF/UA-aware viewer and read the document in tag order rather than visual order. A two-column layout that reads column one top to bottom, then column two, is correct. One that reads across both columns line by line is not — and no automated checker catches that reliably, because catching it means understanding what the page is supposed to say.

Check heading levels while you are in there. A jump from H1 straight to H3 with no H2 between fails WCAG 2.1 SC 1.3.1, and it is a routine byproduct of automated tagging, including cloud auto-tag features that otherwise produce solid structure. A tagged PDF is not automatically a WCAG-compliant one, and heading-level gaps are the cleanest proof of the distinction.

The limit is shape, not quality: this step does not scale to every document, and it is not meant to. It scales to your sample. Choose documents with the layouts your backlog actually contains — multi-column reports, embedded tables, scanned forms. A clean single-column memo tells you almost nothing about whether your hard documents pass, and a sample of easy documents is how a programme convinces itself it is fine.

Step 3: Test with a screen reader, not just a checker

NVDA is free and runs on Windows. JAWS is the enterprise and government standard. VoiceOver ships with macOS. Use whichever your organisation's assistive-technology users actually run, and read the document the way they would: move through the headings first, then tab through anything interactive, then listen to how images and charts get announced.

This is the check nothing else replaces. A compliance score is the floor, not the proof — it confirms the machine-testable structure is present, not that a person moving through the document hears something coherent. Alt text reading "image1.png" is technically present, passes a structural check, and fails the real test every time.

Budget honest time for it. A remediation expert who knows the Matterhorn Protocol can work through a complex document in a few minutes; someone doing it for the first time should expect closer to fifteen. Either way the cost is measured in minutes per document, which is exactly why it belongs on a sample and not on a backlog.

Step 4: Verify form fields and tab order separately

Fillable forms are still the hardest PDF type to remediate, and they earn their own verification pass rather than being folded into the general reading-order check. Tab through every field in the order a keyboard-only user meets it. Confirm each field carries a label describing its purpose — not merely a visual position beside text a sighted user would infer from layout.

SC 4.1.2 sets the requirement for name, role, and value on every form field, and it repays one careful read even if you are not the person implementing it, because it draws the line between what a checker can confirm and what it cannot. Automated checks settle whether a name exists. Whether that name carries meaning for someone who cannot see the field’s position on the page is a judgment, and judgments are what samples are for.

Worth knowing before you buy: claims about automated form remediation vary widely across this market, and the honest way to settle one is to run a vendor's pipeline on one of your own worst forms and then tab through the result yourself. That is a twenty-minute test that replaces an argument. Radio-button groups and checkbox sets are where the disagreements usually surface, so bring a form that has them.

Step 5: Replace full manual review with a defensible sampling plan

Past a few hundred pages, steps 2 through 4 cannot run on every file, and pretending otherwise is how verification programmes quietly stop happening. Build a sampling plan instead. Pull a fixed count from each document type in your backlog — scanned reports, native PDFs, forms, multi-column layouts — run the manual checks on that sample, and record the pass rate by type rather than as one blended figure.

A blended pass rate hides the type that is failing. If your sample reads 96% overall while the forms subset fails at twice the rate of everything else, the single number will never tell you, and the forms subset is usually where the legal exposure lives. Designing for outcomes instead of chasing a single score covers the reasoning in more depth, including why a near-perfect blended average can still leave a meaningful slice of a backlog unusable.

Sample size matters less than whether the sample is drawn the same way every time. A rotating, type-stratified sample run every quarter beats a one-time audit of a thousand random files, because remediation quality on a newly introduced document type drifts before anyone notices unless somebody is checking on a schedule. Consistency is what turns a sample into a trend, and a trend is evidence in a way a snapshot is not.

Step 6: Build the audit trail auditors actually ask for

This is the step the whole article has been walking toward, and the one most programmes treat as paperwork. A verification result nobody wrote down is, as far as an auditor is concerned, a verification that did not happen.

For every batch, keep four things: the checker and its version (PAC 2026 specifically, or veraPDF), the date it ran, the score, and the sample results from steps 2 through 4 including which documents a person actually opened. What happens when your compliance score meets an auditor is worth reading before deciding your recordkeeping is good enough, because the gap tends to reveal itself at the worst available moment.

The record does double duty. Under the ADA Title II web rule, state and local entities serving populations of 50,000 or more have a compliance date of April 26, 2027, and smaller entities and special district governments have April 26, 2028 — context for why a defensible record matters, not a clock to react to. A compliance office that can produce a dated checker score plus a documented sample on request sits in a materially different position from one that can produce a vendor's certificate.

Legal teams outside accessibility hit the identical evidence problem whenever a document review has to hold up later. This comparison of legal document review services walks through workflow, security, and cost for teams handling large volumes under a compliance obligation, and the underlying question — can you reproduce this finding on demand — is the one your PDF audit trail has to answer too.

Store the record somewhere durable and separate from the remediation tool. If the vendor relationship ends, the evidence should not end with it. That single decision is the difference between owning your compliance position and renting it.

Step 7: Automate verification once volume outgrows sampling

Full disclosure first: Accessibility On Demand™ is our platform, and this is the only place in this guide we mention it. Everything in steps 1 through 6 works whether or not you ever use it. Automation changes the volume the method can cover. It does not change the method.

Sampling exists because a person cannot open forty thousand files. AoD scores every document it processes through the Axes4 PAC Checker API — the same engine behind the checker you ran by hand in step 1 — so the automated score and your manual spot-check read the same instrument rather than two different ones. That matters more than the score itself: a number you can reproduce on your own desktop is evidence, and a number only we can produce is marketing. We are benchmarking 97%+ average compliance scores across production volume, verified through the Axes4 PAC Checker API, and every document carries a Compliance Score Certificate, which turns step 6's record into a byproduct instead of homework.

Deterministic processing handles the structural work — tag hierarchy, reading order, table markup — and behaves identically on page 4 and on page 400,000. Generative AI only drafts alt text, and that output stays checkable by a person in the Review Modal before anything ships. Quality therefore stays flat at volume instead of drifting, which is why the category claim is automation rather than AI.

The honest tradeoff: a compliance score, automated or not, is still the floor rather than the proof. Remediation is not redesign — it adds semantic structure without touching contrast, fonts, or layout, which is the honest reason real scores sit in the high 90s rather than a round 100. And if your backlog runs a few hundred pages a year, a desktop checker and a trained person working steps 1 through 6 costs less than any platform, ours included. Step 7 is a volume answer, not a better one.

One figure to hold against your own backlog before deciding whether any of this applies: 600,000 pages processed in May 2026, including a 50,000-page single-day run for one customer. That is the only volume number we publish.

FAQ

How do I verify a PDF remediation vendor's compliance score is real?

Run PAC 2026 or veraPDF yourself, by hand, on a handful of the vendor's remediated files, and compare your number to the one on their certificate. Both checkers are free. If the two disagree by a wide margin, ask which checks the vendor's number includes. A vendor scoring through the Axes4 PAC Checker API — the same engine behind PAC — should produce a result that matches what you get running PAC directly.

What sample size is enough to verify a large PDF backlog?

There is no universal percentage. What matters is stratifying by document type — scanned forms, native reports, multi-column layouts — and sampling each type separately rather than pulling one blended random draw. A hundred documents split across five types, refreshed quarterly, catches drift that a one-time audit of a thousand random files will miss.

Does a passing PAC score prove a PDF works for a screen-reader user?

No, and the arithmetic explains why. A PAC score is computed rather than asserted: checks passed divided by checks run against WCAG and PDF/UA. It settles whether the machine-testable structure is correct. Whether a person reading with a screen reader follows the document is a separate question the score never reaches, which is why a manual reading-order and screen-reader pass belongs in every verification plan however small the sample.

Can automated PDF remediation replace manual verification entirely?

No, and the reason is structural rather than temporary. A score from any engine remains the floor rather than the proof, and judgment calls such as alt-text quality still want a person's eye — which is what the Review Modal is for. What automation changes is coverage — how much of a backlog a programme can honestly speak for. A human check stays in the loop somewhere regardless of the volume.

What is the difference between PAC and veraPDF for verification?

Both check PDF/UA conformance. PAC is a free Windows desktop tool hosted by axes4 under the PDF/UA Foundation; veraPDF is an open-source, cross-platform validator often run inside CI/CD pipelines. The two can disagree on how to interpret the same checkpoint, which is why running both on a sample is safer production practice than trusting either alone.

How often should a remediated PDF backlog be re-verified?

Quarterly sampling catches most drift. Re-verify whenever you change remediation vendors, tools, or internal processes, and run a fresh sample before trusting the new baseline. Evidence is process-specific. A pass recorded a year ago speaks only for the pipeline that produced it, not for whatever your current one is turning out.

Conclusion

Verification at scale is not one method scaled up. It is a named, reproducible checker on every file, a stratified sample opened by a person, and a written record joining the two — with automation added only once the sample stops covering enough of the backlog to mean anything.

Without the sample, a clean dashboard figure says nothing about the forms buried in your backlog. Without the record, today’s passing audit carries no weight in six months’ time. The score is the cheapest part of this to obtain and the least persuasive thing you will own.

If you want to see what steps 1 through 6 look like against your own hardest documents before deciding whether step 7 applies to you, run your first 100 pages through the free trial and check the output with PAC yourself.