Accessible PDFs

PDFs are the most common accessibility failure in US government and nonprofit digital services. This guide explains the legal baseline, the best long-term strategy (replace with HTML), and what to do when a PDF truly cannot be avoided.

Note: Future updates to this page will add interactive working components — live examples, editors, and tools — directly in the browser.

Why this matters for neurodivergent users

PDFs are uniquely hostile to neurodivergent readers. A tagged PDF cannot reflow text on a small screen, cannot be restyled for dyslexia (font, spacing, color), and often jumps reading order when exported from complex layouts. Screen readers frequently mis-sequence columns, footnotes, and captions. For ADHD users, the inability to adjust visual density makes long PDFs cognitively overwhelming.

HTML — rendered in the user's browser with their preferred font and zoom level — solves all of these problems at once. The DOJ agrees: HTML is the preferred format.

The DOJ reality: separate is not equal

The ADA Title II regulations (28 CFR Part 35) classify PDFs and other electronic documents as web content. If a document is required to access a public service, it must meet WCAG 2.1 Level AA by the compliance deadline.

The DOJ strictly limits “conforming alternate versions” (providing a separate accessible copy next to an inaccessible one). Offering an accessible alternative is only legally permissible where technical or legal constraints make primary accessibility impossible. Posting an inaccessible PDF and expecting someone to call for an alternative is not compliant.

Best practice: replace with HTML

Instead of remediating a PDF, convert its content to accessible HTML. When documents function as interactive services — applications, forms, instructions, public notices — HTML is faster to build, cheaper to maintain, and fundamentally more accessible. If a user wants a PDF copy, they use their browser's built-in Print → Save as PDF.

  1. Extract content to Markdown or structured JSON. This separates content from presentation and makes future updates trivial.
  2. Render as a styled HTML page using your existing component library — headings, lists, tables, and figures all get native semantic structure.
  3. Add a print stylesheet so the browser-printed PDF inherits logical reading order, page titles, and link URLs.

When a PDF is unavoidable: PDF/UA + WCAG 2.2 AA

PDF/UA (ISO 14289) is the international standard for accessible PDFs. Combined with WCAG 2.2 AA, it covers all DOJ requirements. Key requirements:

  • Document structure tags — every element must be tagged: headings, paragraphs, lists, tables, figures, form fields.
  • Logical reading order — tags must reflect the visual reading sequence, not the drawing order.
  • Alternative text — every non-text element needs a meaningful description (or is marked as artifact if decorative).
  • Color contrast — 4.5:1 minimum for body text, 3:1 for large text (WCAG SC 1.4.3).
  • Form field labels — all interactive fields require visible and tagged labels (SC 1.3.5, 4.1.2).
  • Document language — set in Document Properties so screen readers choose the correct voice.
  • No security restrictions that block assistive technology from reading the content.

Accessible print output with PrinceXML

When you need a publication-quality PDF from HTML, PrinceXML produces tagged, accessible PDFs from HTML + CSS. Run it in a Podman container for reproducible CI builds:

# Containerfile
FROM debian:stable-slim
RUN apt-get update && apt-get install -y prince

# Build
podman build -t prince-pdf .

# Convert HTML to PDF
podman run --rm -v "$(pwd)":/docs prince-pdf \
  prince /docs/document.html \
  --tagged-pdf \
  --pdf-title="Your Document Title" \
  -o /docs/output.pdf

PrinceXML reads your HTML structure, applies CSS for print layout, and emits a fully tagged PDF/UA document. No manual Acrobat tagging needed.

Legal exceptions for archival documents

The DOJ rule provides limited exceptions — but the bar is high:

  • Preexisting archival documents — PDFs posted before the compliance deadline kept solely for reference or recordkeeping (e.g., a 2003 meeting agenda). You must still provide an accessible alternative on request.
  • Password-protected individual documents — documents about a specific person or property behind a secure portal (e.g., a personalized utility bill). Blank forms are not exempt.

Even when an exception applies, the broader ADA obligation remains: provide an accessible alternative when a disabled user requests one.

Audit by service, not volume

Agencies with thousands of PDFs should triage by service impact, not total count. Prioritize:

  1. Required forms and applications for current services
  2. Public notices and legal notices
  3. Meeting agendas and minutes (within the compliance window)
  4. Archival documents — defer unless requested

Remediating existing PDFs

When HTML conversion is not feasible, use Adobe Acrobat Pro or the free PAC 2024 (PDF Accessibility Checker) to identify failures. The fastest remediation path:

  1. Run PAC 2024 — fix all automatic failures first.
  2. Re-order tags in the Tags panel to match visual reading sequence.
  3. Add alt text to all figures (Right-click → Edit Alt Text).
  4. Set table headers using the Table Editor (Table → Table Properties).
  5. Verify with NVDA + Firefox and VoiceOver + Safari.

Screen reader compatibility

Test every PDF with at least two screen reader + browser combinations:

  • NVDA + Adobe Acrobat Reader (Windows — most common government user environment)
  • JAWS + Adobe Acrobat Reader (Windows — required for Section 508 ACR testing)
  • VoiceOver + Preview (macOS — required for Apple device users)