PDF accessibility
Tagged structure, sensible reading order, and meaningful alternatives for images help people use long documents with screen readers, keyboard navigation, and zoom. This page is a practical field guide—not a replacement for PDF tooling or manual review.
Why this matters
Inaccessible PDFs block students, employees, and customers who rely on assistive technology or need reflow and search. Teams ship PDFs for forms, reports, and policy; when those files are untagged or image-only, support tickets and compliance risk follow—even when the marketing site looks fine.
What PDF accessibility means
An accessible PDF exposes structure (not only pixels): a tag tree, logical reading order, document title and language, text alternatives for meaningful visuals, and tables with header relationships. Users should navigate by headings and lists the same way they would on a well-built HTML page.
Common PDF accessibility failures
Missing or shallow tags
Everything looks fine visually but the tag tree is empty, flat, or wrong—screen readers get little context.
Incorrect reading order
Multi-column layouts and sidebars read in the wrong sequence because order was not fixed after export.
Missing title or language
Assistive tech cannot announce the document name or pronounce content predictably.
Images without alternatives
Charts and diagrams export as figures without alt text or replacement text.
Tables without structure
Header cells are not marked; complex tables lack scope or IDs needed for orientation.
Image-only or scanned PDFs
No reliable text layer—search, selection, and assistive access break unless OCR and cleanup are excellent.
Weak heading structure
Visual bold lines substitute for real heading tags, so navigation by heading fails.
Poor link text
“Click here” and bare URLs in PDFs cause the same confusion they do on web pages.
HTML/SVG reference
The same lesson applies in PDF tag trees: logical sequence must match meaning, not only left-to-right layout.
Pair with your PDF tool’s reading-order panel; fix tags before cosmetic tweaks.
Examples and visuals
Placeholder diagrams below summarize patterns; swap in branded artwork later without changing page structure.
Supporting visual
Structure tree vs visual-only export
Remediation tools show the tag tree; untagged PDFs force assistive tech to guess.
Supporting visual
Layout order is not always logical order
Supporting visual
Headings, lists, and tables should be real objects in the tag tree
Supporting visual
Scans and flattened exports lose selectable text
Prefer source authoring and structured export; OCR is a last resort with QA.
Comparison: Harder to use versus More accessible
Harder to use
- Flattened artwork or scans with no text layer.
- Bold styling pretending to be headings.
- Tables drawn as plain text grids.
More accessible
- Tagged headings match the outline you would use on the web.
- Figures that need explanation carry alt or visible captions.
- Links describe their destination.
How to test PDF accessibility
Combine automated PDF checks with manual passes. Acrobat’s accessibility checker is a common starting point; also validate reading order, tags for complex layouts, and real screen reader behavior on Windows and macOS.
Tooling and document checks
- Run your PDF app’s accessibility checker; fix errors in the tag tree.
- Confirm document title and default language in file properties.
- Review reading order panel against the intended narrative.
- Inspect tags for lists, tables, and headings—not only visual styles.
Keyboard and assistive tech
- Tab through links and form fields; ensure focus order makes sense.
- Navigate by headings with a screen reader if headings exist.
- Zoom and reflow (where supported) to catch clipped text.
- Spot-check complex figures and tables with a human reader.
How to improve PDF accessibility
Author the source document well
Use real heading styles in Word or InDesign, write descriptive link text, and caption meaningful images before export. Garbage in tends to mean expensive remediation later.
Export with structure
Choose export settings that preserve tags. Re-open in your PDF tool and verify the tag tree matches the document outline.
Post-export remediation
Fix reading order, add alt text to figures, mark table headers, and set artifacts for purely decorative visuals. Re-run checks after each batch of fixes.
When HTML pages beat PDF
Prefer HTML for frequently updated policies, interactive forms, and content that users read on phones. HTML is easier to scan with TestAccessibility, version in Git, and test responsively. Keep PDFs for print fidelity or archival needs when you commit to remediation.
Scan your website for related accessibility issues
The same teams often own both the site and the PDF library. A page scan surfaces heading, contrast, link text, and form problems that mirror what you should enforce in exports.
Also see Mobile accessibility guide for touch targets, motion, and mobile web overlap.
FAQ
- Can TestAccessibility scan my PDF?
- No. The scanner loads public web pages in a browser and runs DOM rules. Use Acrobat, PAC, or similar PDF workflows for file-based checks. This page explains what to look for so your PDF program and your website stay aligned.
- What is a tagged PDF?
- A tagged PDF has a logical structure tree (headings, paragraphs, lists, tables) that assistive technology can navigate. Visual styling alone is not enough.
- Why are scanned PDFs a problem?
- They are often a single image with no real text layer, or poor OCR. Users cannot select text, search reliably, or get a consistent screen-reader experience.
- Should I always use PDF?
- For content that changes often, forms people must complete, or deep linking, HTML is usually easier to keep accessible. PDFs still make sense for print-perfect layouts or archival copies when remediated.
- How does this relate to WCAG?
- PDF/UA and WCAG overlap in spirit: perceivable structure, operable navigation, understandable language, and robust tagging. Your web pages and downloads should not contradict each other.
- What should I fix first in a PDF?
- Document title and language, real headings instead of only bold text, reading order, meaningful alt for informative figures, and proper table header cells.