How to test PDF accessibility: a step-by-step guide

Open a two-column meeting agenda that just cleared an automated accessibility check. Start a screen reader and arrow down through the page. If the first line of the left column is followed by the first line of the right column, you are holding a document with a clean report and an unreadable structure.

Nothing is broken about the checker. Reading order is not a condition software can settle, because settling it means inferring the sequence a person would choose on a page the software has never seen. Every serious PDF checker declines that guess and hands the question back. Acrobat's own accessibility checker does the same thing with logical reading order and with color contrast, and it does it on every run, however many times you have already looked.

Which means testing a PDF is really two jobs wearing one name. Whether a heading carries a heading tag is a fact, and a machine settles it in milliseconds. Whether the tag sequence matches the way the page is meant to be read is a judgment, and it stays a judgment. A passing automated check is not a passing document. The test worth running is not the percentage at the top of the report. It is the list of questions the tool refused to answer, next to a record of who answered them instead.

Some orientation before you start. For a few documents a month with trained staff, a desktop editor such as Adobe Acrobat Pro handles testing and repair in one place. For validation alone, PAC 2026 is free. For thousands of pages against a fixed date, batch remediation with published pricing and a named verification engine is the only shape that holds. The scale behind all of this is documented: more than 90% of PDFs are not fully accessible, per Adobe research (Adobe, 2023). Each step below names the tool, the keystroke, and the part that stays human.

What an automated pass actually proves

A compliance score is a ratio. Checks passed divided by checks run, per standard. It is computed rather than asserted, which is what makes it useful, and also what makes its edges visible: the denominator is a finite set of machine-testable conditions, and everything outside that set is simply unscored. Unscored is not the same as fine.

An automated pass is a spell-check for structure. It confirms that nothing is misspelled. It holds no opinion about whether the sentences mean anything in the order they arrive, and that distance between spelling and meaning is the distance between a report and a document.

Here is how the labour actually divides. Keep this beside you while you test, because it tells you where a tool's silence is a statement about scope rather than a green light.

One more boundary before you start filing results. A checker score is not a legal verdict. It evidences the machine-testable work you did, which is a different thing from a determination of ADA or Section 508 compliance, and no score is a legal defense on its own.

Step 1: Know the standard you are testing against

Two standards carry the weight in practice, and they answer different questions. PDF/UA (ISO 14289) is the file-format standard: it specifies how a PDF must be structured so assistive technology can parse it reliably, and the Matterhorn Protocol sets out its machine-checkable failure conditions. WCAG 2.1 AA is the outcome standard, the version the ADA Title II rule references, and the one most compliance frameworks name. Conforming to the first does not settle every question raised by the second, particularly around color and contrast, which is why a document that matters gets measured against both.

The dates are for planning rather than panic. Under the ADA Title II web rule, compliance dates are April 26, 2027 for state and local entities serving populations of 50,000 or more, and April 26, 2028 for smaller entities and special district governments; the Department of Justice extended both dates by one year in April 2026. Treat that as context, not a countdown. The reason to test a document this week is that somebody is trying to read it this week.

Before any checker runs, open File and then Properties. Three fields decide whether the rest of your test means anything. The document has to be tagged. Content copying for accessibility has to be allowed. A primary language has to be set. A file that fails one of the three is not accessible whatever a checker reports afterwards, because the checker is describing a document that assistive technology cannot get inside.

If the pages look photographed rather than typeset, run one more pre-check: drag your cursor across a line. Nothing highlights, and you have an image of a document rather than a document, which needs OCR before any other result carries meaning. A checker will report cheerfully on a picture.

The full inventory of what you are looking for, layered in the order the layers depend on each other:

• Real, selectable text rather than a scan of text
• A complete tag tree whose heading levels descend without skipping
• Alt text on every image that carries information, and none on decoration
• A reading order in the tag tree that matches the order the page is meant to be read in
• Tables built with real row and column headers
• Links that resolve and are also tagged as link elements
• A document language set in properties
• A document title a screen reader announces instead of a filename
• Text and background colors that clear the contrast ratios
• Form fields with tooltips, correct roles, and a tab order following the visual sequence

Step 2: Run PAC 2026 and read the report properly

The most thorough free checker is PAC 2026, maintained under the PDF/UA Foundation and hosted by axes4. It tests against both PDF/UA and WCAG criteria, and unlike the checker built into Acrobat it points at the exact element in the tag tree where a condition failed. That difference is the whole reason to reach for it. A list of failures you can navigate to is a work plan; a list of categories is a summary.

PAC runs on Windows 10 and 11 only. Install it, launch it, drag the PDF onto the window, and you get pass, fail, and warning states across the PDF/UA and WCAG groupings. Read the output in this order:

1. Open Element Results in Detail and work down the failures. Each one resolves to a position in the tag tree, which is where the repair will happen.
2. Generate the PDF report for PDF/UA or for WCAG. It saves next to your source file, and it is the artifact a compliance office asks for months later, so name it properly and keep it somewhere findable.
3. Sort what remains into two piles. Structural failures the tool is certain about (missing tags, wrong heading levels, untagged tables) go in one. Checkpoints flagged for human review go in the other, and logical reading order and color contrast will land there every single time. That is the design of the tool, not a defect in it.

The 2026 release adds AI-assisted checks covering some checkpoints that previously required human judgment. They genuinely reduce the volume of manual testing, which matters on a long queue, and they are useful for triage rather than a replacement for human review. A confident prediction about a semantic decision is still a prediction.

Working on macOS or Linux, or handling a document important enough to want a second opinion, reach for veraPDF, the open-source PDF/UA and PDF/A validator. Two validators can read the same specification and disagree about how to interpret it, so running both over the same file is sound practice rather than duplicated effort. Where they disagree, you have found the place that needs a person to decide which reading is right.

Step 3: Listen to the document in a screen reader

Automated checks find structural failures. A screen reader finds usability failures. Those are overlapping but different populations, which is why a PDF can clear PAC and still be close to unusable, either because the reading order crosses a two-column layout mid-sentence or because three separate headings arrive as one run of speech.

Use NVDA on Windows; it costs nothing. On macOS use VoiceOver, built in and toggled with Command+F5. If your organization licenses JAWS, test there as well, since assistive technologies differ in how forgiving they are about a damaged tag tree. Then work through four passes.

Headings. Press H in NVDA, or VO+Command+H in VoiceOver, to move between headings. You should hear one H1, then H2s for the major sections, then H3s beneath them. Two headings arriving as a single announcement means the tag structure has merged them. Levels that jump mean the hierarchy is wrong even though every heading is technically tagged.

Reading order. Arrow down through a full page, line by line. In a two-column layout you should hear all of column one before column two begins. A voice that alternates between columns tells you the tag order does not match the visual order, and this is both the most common failure in multi-column PDFs and the one an automated report is least equipped to describe. For the mechanics underneath it, the relationship between PDF reading order and tag structure is where the problem is either created or solved.

Images. Press G to jump between graphics. A filename read aloud, or a graphic the screen reader cannot find at all, means the image either has no alt text or is not tagged as a figure. Alt text that exists is not automatically alt text that works. The question is whether it carries the same information a sighted reader takes from the picture, in roughly as many words.

Tables. Press T to reach a table, then move through the cells. Column and row headers should be announced alongside the values. A cell value with no label attached to it means the header cells were never marked as TH elements, and every number in that table has come loose from its meaning.

Step 4: Check reading order, contrast, and links by hand

Three things get flagged by tools and decided by people. Give them their own slot in the schedule, because this is where a document either becomes readable or stays broken behind a passing score.

Reading order is confirmed in the Tags panel in Acrobat Pro. Open the panel, select the first tag, then arrow down. The matching content should highlight in sequence. When a footer surfaces before body text, or a pull quote interrupts a paragraph mid-thought, the tag tree needs rearranging until it follows the path a reader takes. This is the same question as the screen-reader pass in step 3, approached from the structure side instead of the output side. Doing both is how you tell a tagging error apart from a rendering quirk.

Color contrast has to reach 4.5:1 for normal text and 3:1 for large text under WCAG 2.1 AA. Checkers flag the criterion and decline to measure it, for a defensible reason: text sitting over a photograph, a gradient, or a chart fill has no single background color to compare against. Sample the real foreground and background values with a contrast tool. Light gray body copy and colored text on colored panels are where branded documents fail, and no amount of tag work will move either, because contrast belongs to the design layer rather than the structure layer.

Links need two separate things to be true. The destination has to resolve, and the link has to be tagged as a Link element with its text inside. Conversion out of Word or InDesign routinely delivers one without the other. Click each link, then check its tag. In Acrobat, Find and then Unmarked Annotations will locate the ones that look like links on the page and do not exist in the structure at all.

Write the result up with the qualifier attached: the score is the floor, not the proof. A document that clears the automated layer still needs this layer before a person can use it.

Step 5: Tab through every field in a fillable form

Fillable forms are the hardest PDF type to remediate and the hardest to test, because a form is not a document that reads. It is a document that answers back. The governing requirement is WCAG 2.1 SC 4.1.2 (Name, Role, Value): every field needs a programmatic name, an identified role, and a state or value assistive technology can read. A label printed next to the box does not satisfy it. The association has to live in the field's Tooltip property, where a screen reader can actually find it.

Save the file, close it, reopen it, then Tab from the first field to the last with the screen reader running. Confirm all of this:

• Each field announces its own label rather than "text field" or nothing at all
• Required fields are announced as required, not signalled only by a red asterisk
• Radio groups announce the group's question and then each option
• Tab order follows the visual sequence, without jumping sections or skipping a box
• Dropdowns open and move under the arrow keys

The caveat that catches most teams: placing form fields in Acrobat does not create the tags that expose them. The tag structure has to be repaired separately after the fields exist, or the fields stay invisible to a screen reader while looking perfectly ordinary on screen. That is documented Acrobat behaviour rather than an edge case, and it is how a form passes a visual review and fails every user who needs it.

At volume the arithmetic turns hostile, and manual forms work is where specialist rates reach $100+ per page. For the field-level specifics auditors ask about first, the breakdown of fillable form accessibility under SC 4.1.2 covers what to check in high-volume document environments.

Step 6: Scale the test when the backlog outgrows the method

Steps 1 through 5 work well for a handful of documents. They do not work for a backlog of thousands, and the method does not degrade gracefully. It breaks at the point where the queue grows faster than the person clearing it, and after that every month adds to the pile regardless of how skilled the operator is.

The cost curve is the real constraint. Manual remediation runs $5–$25+ per page from specialist firms — $100+ per page for complex fillable forms — and that cost scales linearly with volume. Manual remediation of a complex page commonly runs 15–30+ minutes, which is the same constraint stated in hours instead of dollars.

This is the problem we built Accessibility On Demand™ to solve, so read what follows as a disclosed interest. AoD splits the work along the line this article has been drawing all along. Deterministic processing handles structural work that has a correct answer, meaning tags, reading order, and tables, and it behaves identically on page 4 and page 400,000. Generative AI is used only where judgment is required, such as alt text. Every output is checkable in the Review Modal, which puts reading-order visualization, the tag tree, and alt-text editing in one interface so that a person confirms a document actually reads correctly rather than merely scoring correctly.

Pricing is published openly, with no quote gate: $0.30/page (Standard, Level 1), $1.80/page (Enhanced, Level 2), $12/page (Expert Review, Level 3). Level 2 (Enhanced) targets a 95%+ WCAG 2.1 AA Compliance Score, verified by the PAC (Axes4) checker, and if a document doesn't clear 95%, you're not charged for it (rare source-document exceptions apply). Refinements happen in the Review Modal. Expert Review (Level 3) targets a 99% Compliance Score; full WCAG 2.1 AA + PDF/UA, human-verified. API access is available for high-volume integrations. The standard we work to is WCAG 2.1 AA, the version ADA Title II references, tested to 2.2 AA.

On measurement, we're benchmarking 97%+ average compliance scores across production volume, verified through the Axes4 PAC Checker API, which is the same validation engine behind the free desktop checker from step 2. That matters more than the number does: it means the figure reproduces on your machine rather than only on ours. On volume, 600,000 pages processed in May 2026, including a 50,000-page single-day run for one customer.

Then the limits, which are the part that decides whether any of this applies to you. AoD is not the right buy for a handful of documents a year, because at that volume a trained operator with a desktop license costs less. Fillable forms are handled through the Review Modal today, where a person confirms field labels and tab order, with a fully automated forms pipeline expected in Q3 2026. And remediation is not redesign: AoD adds semantic structure and does not change contrast, fonts, or layout. That scope boundary is the honest reason real scores sit in the high 90s rather than a round 100.

Whichever tool clears your queue, the evidence problem outlives the remediation. Keep the validator report for every document, dated, with the standard it was run against, because the question arrives later and in somebody else's words. What happens when your compliance score meets an auditor covers what that conversation looks like from the other side of the table.

Frequently asked questions

Is PAC 2026 really free, and does it work on Mac?

PAC 2026 is free, and it is the most thorough standards-based checker available for PDFs. The limitation is real: it runs on Windows 10 and 11 only. On macOS or Linux, use veraPDF, the open-source validator covering PDF/UA and PDF/A conformance. Neither tool repairs anything; both tell you what to repair, which then happens in Acrobat or a remediation platform. Running both over an important document is worth the extra few minutes, because validators can disagree about interpretation and the disagreement is informative.

What's the difference between PDF/UA and WCAG for PDFs?

PDF/UA (ISO 14289) is the structural standard specific to the file format. It defines how tags, reading order, and document properties have to be set so assistive technology can parse the file at all. WCAG is the broader standard describing outcomes: whether alt text is meaningful, whether contrast is sufficient, whether the content can be operated by keyboard. A document that matters should be measured against both, since clearing PDF/UA leaves several WCAG questions open, the color and contrast ones especially. Most compliance frameworks, ADA Title II included, name WCAG as the benchmark.

Can automated tools handle fillable PDF forms?

Partly, and forms are the hardest type to automate. Structure is tractable. Form accessibility means confirming that every field carries a correct tooltip label, a role set programmatically, and a tab order matching the visual sequence, and those are judgments about intent rather than conditions to detect. At Accessibility On Demand™, forms are handled through the Review Modal today, where a person confirms field labels and tab order, with a fully automated forms pipeline expected in Q3 2026. That is also the work that pushes specialist rates to their ceiling: complex fillable forms are where manual remediation reaches $100+ per page.

Does a tagged PDF automatically mean it's WCAG compliant?

No. Tagged means the document has a structure tree. It does not mean the tags are the right tags, in the right order, at the right levels. A tagged PDF still fails WCAG 2.1 AA when heading levels skip, images carry no useful alternative, table headers were never marked as TH elements, or the reading order contradicts the visual layout. Tagging is where the work starts. The reasons a tagged PDF does not mean a WCAG-compliant PDF are worth reading before you accept a tagged deliverable as finished.

How much does PDF accessibility remediation cost per page?

Manual remediation from a specialist firm runs $5–$25+ per page, and $100+ per page for complex fillable forms. Automated platforms cost substantially less per page: AoD publishes $0.30 (Standard, Level 1), $1.80 (Enhanced, Level 2), and $12 (Expert Review, Level 3, human-verified). The figure that decides a budget is not the unit rate, though. It is the unit rate multiplied by a page count nobody has finished counting, plus every document published between today and the date you are working towards.

What does Section 508 require for PDF accessibility testing?

Section 508 requires PDFs to be usable by people using assistive technology, with WCAG as the referenced technical standard; its own reference point is WCAG 2.0 AA, which WCAG 2.1 AA fully includes. A test should confirm real selectable text, a correct tag structure, useful alternatives for images, a reading order matching the layout, accessible tables and forms, and correct document properties. For a record you can defend, keep the validator output beside a note of what a person reviewed and decided. Automated results do not describe the judgments, and a checker score is not a determination of legal compliance.

What to do with the report you just made

Go back to the agenda in the first paragraph. Nothing about that file changed when the checker passed it. What changed is that you now know which of its questions were answered by a machine and which are still open, and an open question inside a document gets answered by whoever opens it next.

The working order, once more: properties first, then PAC 2026 for a standards-based report, then a screen reader for the parts no report covers, then the Tags panel and a contrast tool for the two checks every tool hands back, then Tab through the forms. Keep the validator output. Write down what you decided by hand and why you decided it. That pairing is the closest thing to a defensible record that anybody has, and assembling it costs less time than arguing about it later.

When the queue grows past the method, the arithmetic makes the decision for you. Run your first 100 pages free and find out what your documents actually score, starting with the ugliest ones you own.