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:
- Missing document language
- Missing document title
- Images without alt text
- Untagged content
- Missing heading structure
- Form fields without labels (if present)
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:
- Heading tags (H1, H2, H3) are present and correctly nested
- Body text is tagged as
P(paragraph) - Lists are tagged as
LwithLIitems - Tables use
Table,TR,TH,TDcorrectly - Decorative images are tagged as
Artifact - Meaningful images have
Alttext set
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:
- NVDA + Adobe Acrobat: NVDA (free, Windows) is the most widely used screen reader for PDF testing. Open the PDF in Acrobat, activate NVDA, and navigate using heading keys (H key), link navigation (K key), and form navigation (F key). This reveals reading order errors and missing structural elements that automated tools miss.
- JAWS + Acrobat: JAWS is the most common screen reader in corporate environments. If your primary audience uses corporate Windows environments, JAWS testing is the most representative.
- VoiceOver + Preview (macOS): For PDFs distributed to Mac users, test with VoiceOver and the Preview app. PDF rendering differences between Acrobat and Preview can expose additional issues.
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:
- Use the eyedropper tool to sample the text color and background color for each text style
- Confirm normal text (under 18pt regular, or under 14pt bold) meets 4.5:1 contrast ratio
- Confirm large text meets 3:1 contrast ratio
- 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:
- Provide the content as accessible HTML (a web page)
- Convert to EPUB3, which is reflowable by design
- Provide both formats (PDF for print, EPUB3 or HTML for accessible digital distribution)
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
- ☐ Automated check with Acrobat Pro or PAC 2024
- ☐ Read Out Loud test for reading order (pay special attention to multi-column layouts)
- ☐ Tags panel inspection for heading hierarchy and semantic structure
- ☐ Table Editor check for TH cells and scope attributes
- ☐ Screen reader test with NVDA or JAWS (heading, link, and table navigation)
- ☐ Color contrast check with Colour Contrast Analyser
- ☐ Reflow test at 400% zoom (if the document must remain as PDF)
- ☐ ACE by DAISY validation on EPUB3 output (if converted)
For accessibility teams managing EAA compliance workflows, see our dedicated guide at toolkit.bot/for/accessibility-teams →