PDF Accessibility: Making Documents Universal

PDFs are everywhere — contracts, invoices, reports, forms, manuals, government documents. They are also among the least accessible digital formats by default. An untagged PDF is opaque to screen readers, does not reflow for low-vision users, and traps content in a fixed layout that ignores every responsive design principle. Making PDFs accessible requires intentional structure from the start or remediation after the fact.

Why PDFs Are Inaccessible by Default

A PDF is fundamentally a page-description format. It tells a renderer where to place text and images on a page — but it does not inherently convey structure. Without explicit tagging, a PDF has no headings, no paragraphs, no lists, no table structure, and no reading order. A screen reader encounters a stream of unstructured text positioned on a coordinate grid.

The PDF/UA (Universal Accessibility) standard (ISO 14289) and WCAG 2.2 PDF techniques define what a properly accessible PDF looks like.

Core Requirements for Accessible PDFs

1. Document Tags (Structure)

Tags define the logical structure: headings (H1-H6), paragraphs (P), lists (L, LI), tables (Table, TR, TH, TD), figures (Figure), and links (Link). Tags serve the same function as semantic HTML — they build an accessibility tree that screen readers navigate.

Every piece of meaningful content must be tagged.
Tags must be in logical reading order (not visual layout order, which may differ in multi-column layouts).
Decorative elements (background images, borders, page numbers) must be marked as “artifacts” so screen readers skip them.

2. Reading Order

The order of tags in the tag tree defines the reading order for assistive technology. In a two-column layout, the reading order must flow through the left column first, then the right — not zigzagging between them.

Verify reading order in Acrobat Pro’s Reading Order tool or the Tags panel. In multi-column documents, this is the most common failure point.

3. Alternative Text for Images

Every meaningful image needs a text alternative in its Figure tag’s “Alt” property. Decorative images are artifacted (not tagged). This mirrors WCAG SC 1.1.1 for web content.

4. Table Structure

Data tables must use TH (table header) tags with scope attributes so screen readers announce column and row headers when navigating cells. Without proper headers, a screen reader user in the middle of a table has no context for what each cell value represents.

Complex tables with merged cells require ID and headers attributes — the same approach as accessible HTML tables.

5. Form Fields

Interactive PDF forms require:

Descriptive tooltips on every field (the tooltip serves as the accessible name).
Logical tab order matching the visual layout.
Required field indication.
Explicit form field types (text, checkbox, radio, dropdown).

6. Document Properties

Title: Set in Document Properties (not the filename). Screen readers announce the title on open.
Language: Set the document language so screen readers use the correct pronunciation engine. Same principle as WCAG SC 3.1.1 for web pages, covered in our internationalization guide.
Bookmarks: Long documents should include bookmarks that mirror the heading structure for navigation.

7. Color Contrast and Font

All the same contrast requirements that apply to web content apply to PDFs: 4.5:1 for normal text, 3:1 for large text. Text must be actual text (not images of text) so it can be selected, searched, and resized.

Creating Accessible PDFs From Source

Remediation is expensive and error-prone. The most efficient approach is building accessibility into the source document.

From Microsoft Word

Use heading styles (Heading 1, Heading 2), not manual formatting.
Use built-in list styles.
Add alt text to all images via the image properties panel.
Use the built-in table tools (not tabs or spaces to simulate columns).
Run the Word Accessibility Checker before exporting.
Export with “Create tagged PDF” enabled (default in modern Word versions).

From Adobe InDesign

Map paragraph styles to PDF tags via the Export Tagging panel.
Set reading order using the Articles panel.
Add alt text to images in Object Export Options.
Export as PDF/UA-compliant.

From Google Docs

Use heading styles and built-in list formatting.
Google Docs exports tagged PDFs, but the tagging quality is often inferior to Word. Manual remediation may be needed.

Remediating Existing PDFs

When the source document is unavailable or poorly structured:

Run a Full Accessibility Check in Acrobat Pro (Accessibility > Full Check). This identifies missing tags, reading order issues, missing alt text, and contrast failures.
Add tags using Acrobat’s Auto-tag feature as a starting point, then manually correct in the Tags panel.
Fix reading order in the Order panel or Tags panel.
Add alt text to all Figure tags.
Define table structure using the Table Editor.
Set document title and language in Document Properties.
Re-run the checker and verify with a screen reader (NVDA or JAWS).

When Not to Use PDF

Consider whether PDF is the right format at all:

For web content: HTML is inherently more accessible, responsive, and screen-reader-friendly than PDF. If the content lives online, publish it as a web page.
For forms: Web-based forms with proper form accessibility are more accessible than PDF forms.
For documents that need to be printed exactly: PDF is appropriate. Legal contracts, tax forms, and design proofs benefit from PDF’s fixed layout.

Provide HTML alternatives alongside PDFs whenever possible.

Key Takeaways

Untagged PDFs are inaccessible to screen readers — every meaningful element needs semantic tags.
Reading order, alt text, table headers, and form field labels are the core remediation targets.
Build accessibility into source documents (Word, InDesign) before exporting to PDF.
Consider whether HTML would serve the content better than PDF.
Remediation with Acrobat Pro is possible but time-consuming — prevention is cheaper.

Next Steps

Apply document structure principles from the WCAG 2.2 overview.
Ensure PDF colors meet contrast standards.
Consider email accessibility for documents distributed electronically.

Sources

WCAG 2.2 PDF Techniques — W3C techniques for meeting WCAG in PDF documents.
WebAIM: PDF Accessibility — Practical guide to creating and remediating accessible PDFs.
Deque University: PDF Accessibility — PDF accessibility checklist and remediation steps.
The A11Y Project: Accessible Documents — Community guidance on document accessibility.

PDF accessibility requirements referenced from PDF/UA (ISO 14289), WCAG 2.2 PDF Techniques, and WebAIM’s PDF Accessibility guide. Remediation guidance adapted from Deque’s PDF accessibility checklist.