How to Create Accessible PDFs: WCAG 2.1 Compliance Guide

Digital accessibility is both an ethical obligation and, in many jurisdictions, a legal requirement. Section 508 of the Rehabilitation Act (US), the European Accessibility Act (EU), and similar laws worldwide require public-facing documents to be accessible to people with disabilities. PDFs are covered by these regulations. An inaccessible PDF — one that cannot be read by a screen reader — may expose your organization to legal liability and excludes millions of users with visual impairments.

A WCAG 2.1 compliant PDF must meet four principles (POUR): Perceivable (content can be perceived through sight, hearing, or touch), Operable (navigation works via keyboard and assistive technology), Understandable (language, reading order, and structure are clear), and Robust (compatible with current and future assistive technologies). For PDFs, this primarily means: tagged content with correct reading order, alt text for all images, proper heading hierarchy, sufficient color contrast, and form fields with labels.

PDF tags are the foundation of accessibility. Tags describe the document structure to screen readers — headings (<H1>-<H6>), paragraphs (<P>), lists (<L>, <LI>), tables (<Table>, <TR>, <TH>, <TD>), and figures (<Figure> with alt text). A properly tagged PDF allows a screen reader user to navigate by heading, skip to the next paragraph, and understand the relationship between data cells and their row/column headers in a table.

The reading order — the sequence in which a screen reader reads the content — must match the visual reading order. A two-column layout where the screen reader jumps between columns instead of reading each column top-to-bottom, or a sidebar that is read before the main content, creates a confusing experience. Most PDF accessibility checkers include a reading order verification tool. Fix reading order issues by adjusting the tag tree in a PDF editor.

Alt text (alternative text) for images is mandatory. Every image, chart, diagram, and decorative element needs an alt text description that conveys the same information a sighted reader would get. For complex charts, provide both a short description (alt text) and a longer description (in the surrounding text or as an accessible appendix). Decorative images that convey no information should be marked as artifacts so screen readers skip them entirely.

Color contrast is often overlooked in PDF accessibility. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold). Many branded documents use light gray text on white backgrounds for a 'clean' look, but this fails contrast requirements and is difficult for low-vision users to read. Use a contrast checker tool on your document's color palette and adjust as needed.

Verifying PDF accessibility requires both automated and manual testing. Automated checkers (PAC 2024, Adobe Acrobat Pro's Accessibility Checker, axesPDF) catch technical issues: missing tags, missing alt text, incorrect heading nesting. But they cannot verify that alt text is meaningful ('chart' is technically valid alt text but useless to a screen reader user) or that the reading order is logical. Always do a manual pass with a screen reader (NVDA on Windows, VoiceOver on Mac) to experience the document as a non-visual user would.

For existing PDFs that are not accessible, remediation is possible. First, make the PDF searchable and tagged using OCR if it is a scanned document — https://www.iamuu.com/pdf/ocr-pdf/ creates a text layer that screen readers can access. Then add tags, alt text, and fix the reading order using a PDF editor. For new documents, build accessibility in from the start: use Word or Google Docs' built-in heading styles (not just bold text), add alt text to images before exporting, and use the accessibility checker before saving as PDF. An accessible source document produces a much more accessible PDF than trying to retrofit accessibility afterward.