PDF Accessibility: How to Make PDFs WCAG Compliant (2026)

According to the World Health Organization, over 1 billion people — 15% of the global population — live with some form of disability. Of these, approximately 250 million have moderate-to-severe vision impairment. When PDFs aren't accessible, these users are locked out of essential information.

Legal requirements are tightening: • Section 508 (US) — requires federal agencies to make electronic documents accessible • ADA (Americans with Disabilities Act) — courts increasingly interpret ADA to cover digital documents • European Accessibility Act (2025) — mandates accessibility for digital services across the EU • AODA (Ontario, Canada) — requires large organizations to make documents accessible

In 2024, digital accessibility lawsuits in the US exceeded 4,600 — a 300% increase since 2018 (UsableNet 2024 report). PDF accessibility is no longer optional for organizations.

WCAG 2.1 (Web Content Accessibility Guidelines): Developed by W3C, WCAG provides the foundation for digital accessibility. While designed for web content, its principles apply directly to PDFs: • Perceivable — content must be presentable in ways users can perceive (alt text, color contrast) • Operable — interactive elements must be keyboard-navigable • Understandable — content and interface must be clear • Robust — content must work with assistive technologies

PDF/UA (ISO 14289): The PDF-specific accessibility standard. PDF/UA specifies: • All content must be tagged with semantic structure (headings, paragraphs, lists, tables) • Images must have alternative text • Reading order must be logical • Form fields must have labels • Language must be specified

Section 508 (US): US federal standard referencing WCAG 2.0 Level AA. Applies to federal agencies and contractors.

Use this checklist to evaluate and fix PDF accessibility:

1. Tagged PDF structure: Every PDF must have a tag tree defining the document structure (headings, paragraphs, lists, tables, figures). Without tags, screen readers read content in stream order — which may not match visual reading order.

2. Heading hierarchy: Use H1-H6 tags in logical order. Don't skip levels (H1 → H3 without H2). Screen reader users navigate by headings.

3. Alternative text for images: Every informative image needs descriptive alt text. Decorative images should be marked as artifacts (hidden from screen readers).

4. Table structure: Data tables need header rows/columns tagged as TH (Table Header). Complex tables need scope attributes.

5. Reading order: The tag tree must reflect the logical reading order. Multi-column layouts can confuse screen readers if not tagged correctly.

6. Color contrast: Text must have a minimum 4.5:1 contrast ratio with its background (WCAG AA). Large text (18pt+) requires 3:1.

7. Document language: Set the primary language in document properties. Mixed-language content should be tagged at the element level.

8. Link text: Links must be descriptive. 'Click here' is insufficient — use 'Download the annual report' instead.

9. Form field labels: Every form field must have an associated label that screen readers can announce.

10. Bookmarks: Documents over 20 pages should include bookmarks for navigation.

The easiest path to accessible PDFs starts in Microsoft Word:

1. Use Styles for structure: Use Word's built-in Heading 1, Heading 2, Body Text styles — not manual formatting. These map directly to PDF tags.

2. Add alt text to images: Right-click image → Edit Alt Text → write a meaningful description.

3. Use built-in table features: Insert → Table. Mark header rows: Table Properties → Row → 'Repeat as header row at top of each page.'

4. Run Accessibility Checker: Review tab → Check Accessibility. Fix all errors before exporting to PDF.

5. Export as tagged PDF: File → Save As → PDF → Options → check 'Document structure tags for accessibility.'

Common mistake: Manually formatting text to look like headings (making text bold and large) without using Word's Heading styles. This creates PDFs that look correct but have no structural tags — invisible to screen readers.

Free testing tools:

• PAC (PDF Accessibility Checker) — free Windows tool by the Swiss Foundation for Accessible ICT. Tests against PDF/UA standard and generates detailed reports.

• Adobe Acrobat Pro Accessibility Check: Tools → Accessibility → Full Check. Tests 32 rules covering structure, content, and navigation.

• NVDA (NonVisual Desktop Access): Free Windows screen reader. The definitive test — if NVDA can read your PDF correctly, it's accessible.

• VoiceOver (macOS/iOS): Built-in Apple screen reader. Activate with Cmd+F5 on Mac.

Testing workflow: 1. Run PAC or Acrobat's accessibility checker 2. Fix all reported errors 3. Test with NVDA or VoiceOver manually 4. Have a user with a disability review if possible 5. Recheck after any document updates

Mistake 1: Scanned PDFs without OCR Scanned documents are images — screen readers can't read them. Fix: Run OCR to add a text layer, then tag the document.

Mistake 2: 'Flat' PDFs without tags PDFs exported without structure tags look fine but are inaccessible. Fix: Re-export from source with 'Document structure tags' option enabled.

Mistake 3: Decorative images without artifact marking Decorative images (borders, backgrounds) announced by screen readers create noise. Fix: Mark decorative images as artifacts in the tag tree.

Mistake 4: Tables used for layout Using tables for visual layout (not data) confuses screen readers. Fix: Use positioned text or layout regions instead.

Mistake 5: Missing document title When PDF title is missing, screen readers announce the filename (e.g., 'doc_final_v3_FINAL.pdf'). Fix: Set a descriptive title in Document Properties.