← toolkit.bot

How to Test PDF Accessibility for WCAG 2.2 AA Compliance

Testing PDF accessibility is not straightforward. Unlike websites — where browser developer tools, extensions, and automated scanners give immediate feedback — PDFs require specialized tools and manual testing techniques that most compliance teams have never used.

This guide covers the complete testing workflow: automated checking, manual inspection in Acrobat, and screen reader validation. It also explains why many PDFs cannot be made fully WCAG 2.2 AA compliant regardless of how thoroughly you test and patch them.

Step 1 — Automated PDF Accessibility Checking

Start with automated tools to identify structural issues quickly before manual review.

Adobe Acrobat Pro: Built-in Accessibility Checker

In Acrobat Pro: Tools → Accessibility → Full Check. This runs Adobe's built-in checker against the PDF/UA and WCAG criteria it knows how to test. It flags:

Acrobat's checker produces a results panel with pass/fail/warning for each criterion. Each failure links to the offending element. Limitation: It does not test reading order or color contrast, and it misses structural errors in complex table tags.

PAC 2024 (PDF Accessibility Checker)

PAC 2024 is a free, standalone tool (Windows) from the PDF/UA Foundation. It provides more detailed tag structure analysis than Acrobat's built-in checker, with a visual preview that shows how assistive technology will interpret each element. Download from pdfua.foundation.

PAC checks against PDF/UA-1 (ISO 14289-1), which aligns with WCAG 2.2 AA requirements for document accessibility. It provides a tag tree view and a screen reader preview mode — useful for spotting reading order errors that the standard checker misses.

ACE by DAISY (for EPUB3 output)

If you convert your PDF to EPUB3 for remediation, ACE by DAISY (free, open source) is the most thorough automated accessibility checker available for any document format. It checks against EPUB Accessibility 1.1, WCAG 2.2 AA, and produces a detailed HTML report with pass/fail status for each criterion and element-level location of failures. This is the recommended validation step after converting with toolkit.bot.

Step 2 — Manual Testing in Adobe Acrobat

Automated checkers miss several critical failure types. Manual inspection in Acrobat is required for complete testing.

Check Reading Order

The most reliable way to test reading order: View → Read Out Loud → Activate Read Out Loud, then choose Read This Page Only. Listen carefully. Does the content read in logical order? In multi-column documents, does it complete column 1 before column 2, or does it alternate between columns?

Alternatively, use the Order panel (View → Show/Hide → Navigation Panes → Order) to see the visual reading sequence overlaid on the page.

What you'll find: Most multi-column PDFs read incorrectly. This cannot be easily fixed in PDF — the tag reading order can be manually reordered in Acrobat Pro's TouchUp Reading Order tool, but this is extremely time-consuming for long documents.

Inspect Tag Structure

Open the Tags panel (View → Show/Hide → Navigation Panes → Tags). Expand the tree. Confirm:

For documents without any tag structure, the entire tree will be empty or contain a single flat list of Span and Figure elements — this means the PDF was never tagged and requires complete remediation.

Test Table Accessibility

Use the Table Editor (Tools → Accessibility → Table Editor) to inspect table structure. Header cells should be identified as TH and have correct scope attributes (Row, Column, or Both). Simple tables with a single header row and no merged cells are the easiest to fix; complex tables with spanning headers often require manual reconstruction.

Step 3 — Screen Reader Testing

Automated and manual visual inspection cannot substitute for testing with actual assistive technology. The most important screen reader combinations for PDF testing:

What to test: Navigate to the first heading. Can you use heading navigation to jump through the document? Tab through all links — does each announce meaningful text? Navigate into each table and confirm row/column relationships are announced correctly.

Step 4 — Color Contrast Testing

No automated PDF checker tests color contrast reliably. Use the Colour Contrast Analyser (free, cross-platform) from TPGi:

  1. Use the eyedropper tool to sample the text color and background color for each text style
  2. Confirm normal text (under 18pt regular, or under 14pt bold) meets 4.5:1 contrast ratio
  3. Confirm large text meets 3:1 contrast ratio
  4. Check body text, caption text, table cell text, and any colored text blocks separately

Color contrast failures must be corrected in the source document — they cannot be patched in the PDF output without access to the original file.

Why Some PDFs Cannot Be Made WCAG 2.2 AA Compliant

WCAG 1.4.10 (Reflow) requires content to be readable at 400% zoom without horizontal scrolling. This criterion cannot be met by any PDF with fixed page dimensions. PDF pages are sized in points — zooming enlarges the page but does not reflow the content. Even a perfectly tagged, fully accessible PDF fails WCAG 1.4.10.

This is not a fixable PDF issue. It is a format limitation. The only compliant solutions are:

For organizations with large PDF inventories, converting to EPUB3 via toolkit.bot is the fastest path to WCAG 1.4.10 compliance — free, browser-based, no account required. Validate the output with ACE by DAISY for a formal conformance report.

Convert your PDF to accessible EPUB3 — free at toolkit.bot, validate with ACE by DAISY.

Convert a PDF Free →

Testing Checklist Summary

For accessibility teams managing EAA compliance workflows, see our dedicated guide at toolkit.bot/for/accessibility-teams →

Related guides