PDF Accessibility: How to Make PDFs ADA/WCAG Compliant

Why Most PDFs Are Inaccessible

PDF was designed to preserve exact visual layout across devices and printers, not to communicate structure. That print-first design goal is the root of almost every PDF accessibility problem you will encounter:

• Scanned images with no text layer. A huge share of "inaccessible PDFs" are not really documents at all from a screen reader's point of view — they are a picture of a page saved with a .pdf extension. There is no underlying text to read, select, or search.
• No tag structure. Even PDFs that contain real, selectable text are often "untagged" — they have no hidden structural map telling assistive technology what is a heading, what is a paragraph, what is a list, and what is a table. Visually the document looks fine; to a screen reader it is an undifferentiated stream of characters.
• Missing or wrong reading order. Multi-column layouts, sidebars, and pull quotes are common in print-style documents. Without an explicit reading order defined in the tags, a screen reader may read straight across a page — jumping from column one into column two mid-sentence — rather than following the visual flow a sighted reader would use.
• Missing alternative text on images. Charts, diagrams, scanned signatures, and photos frequently ship with no alt text, so a screen reader either skips them silently or announces something unhelpful like "Image."
• Unlabeled form fields. Fillable PDF forms often lack accessible names, descriptions, or a sensible tab order, making them unusable for someone navigating by keyboard or screen reader alone.

Each of these is fixable, but none of them fixes itself. A PDF exported from a source document without deliberate accessibility settings will typically have all five problems at once.

What "Tagged PDF" Actually Means

The foundation of PDF accessibility is the tag tree — a hierarchical structure layered underneath the visible page that tells assistive technology what each piece of content is and how it relates to the rest. It plays roughly the same role the DOM plays for an HTML page.

Common tags include:

• <H1> through <H6> for headings, in proper hierarchical order
• <P> for body paragraphs
• <L> and <LI> for lists
• <Table>, <TR>, <TH>, and <TD> for tables, with header cells marked as such
• <Figure> for images, carrying the alt text
• <Link> for hyperlinks

A "tagged PDF" is simply a PDF where this structure exists and is accurate — headings are actually marked as headings, tables have real header cells, and the reading order follows the logical flow of the content rather than the raw order elements happen to sit in the underlying file. Purely decorative images (background flourishes, dividers) should be marked as artifacts rather than figures, so a screen reader skips over them instead of announcing meaningless images.

The PDF/UA Standard

PDF/UA (Universal Accessibility), published as ISO 14289, is the formal technical standard for accessible PDF documents. It builds directly on the PDF tag architecture described above and sets specific, checkable rules for how tagging must be done — covering reading order, table structure, alternative text, form field labeling, document metadata, and more.

Separately, the W3C maintains WCAG techniques for PDF — a set of informative techniques that map WCAG success criteria (like 1.1.1 Non-text Content or 1.3.1 Info and Relationships) onto specific PDF authoring practices. WCAG itself is technology-agnostic; the PDF techniques exist to explain what satisfying WCAG actually looks like when your content happens to be a PDF rather than an HTML page.

In practice, the two standards point in the same direction and reinforce each other: a PDF built to PDF/UA's tagging rules will generally also satisfy the relevant WCAG success criteria, and vice versa. Neither replaces the other — PDF/UA is more prescriptive about PDF-specific mechanics, while WCAG covers the broader content and design requirements (contrast, language, consistent navigation) that apply regardless of format.

For the shorter definitional version of accessible PDF, see our Accessible PDF glossary entry. This guide is the deeper, practical companion covering how to actually get there.

How to Check Whether a PDF Is Accessible

A few checks, roughly in order of effort:

1. Try to select the text. Open the PDF and attempt to click-and-drag select a sentence. If nothing highlights, you are looking at a scanned image with no text layer — and no amount of tagging will fix it until it is run through OCR.
2. Run Adobe Acrobat Pro's Accessibility Checker (Full Check). This automated tool flags missing tags, missing alt text, missing document title and language, untagged tables, and several other structural issues in seconds. It is a strong first pass and the most widely used tool for this specific job.
3. Open the Tags panel in Acrobat Pro to inspect the actual tag tree — confirm headings are tagged as headings (not just styled to look like one), tables have header cells, and the reading order matches the visual flow.
4. Check with a PDF/UA validator such as PAC (PDF Accessibility Checker), a free tool maintained specifically to validate conformance against the PDF/UA standard, for a more rigorous structural check than Acrobat's built-in checker alone provides.
5. Test with an actual screen reader — NVDA or JAWS on Windows, VoiceOver on macOS — reading through the document from top to bottom. This is the only step that reveals how the document actually sounds to the people it needs to work for, and it routinely surfaces problems the automated checkers miss.

No single step in this list is sufficient on its own. Automated checkers are fast but structural only; a screen reader pass is slow but tells you the truth.

A Practical Remediation Workflow

Start with the source document whenever you can. It is far cheaper to build accessibility in than to remediate it out. In Microsoft Word, apply real heading styles (not just bold, larger text), add alt text to images through Word's alt text pane, use Word's built-in list and table tools instead of manually spacing text into columns, and export with the "Document structure tags for accessibility" option enabled. Adobe InDesign supports a similar accessibility-tagging workflow for design-heavy documents.

For existing PDFs, especially scanned ones, remediation looks like this:

1. Run OCR first if the document is a scanned image. Acrobat Pro's "Recognize Text" feature (or equivalent OCR software) converts the flat image into selectable, searchable text. Proofread the result — OCR accuracy drops with poor scan quality, unusual fonts, or handwriting.
2. Run Acrobat's "Make Accessible" wizard (or "Prepare for Accessibility" in current versions) as a starting pass. It auto-tags much of the document and flags what it could not handle automatically.
3. Open the Tags panel and correct the structure by hand. Fix heading levels that got flattened, mark decorative images as artifacts, add or correct alt text on meaningful images, and rebuild table header associations for anything complex.
4. Set the reading order explicitly, especially for multi-column layouts, sidebars, and pull quotes, using Acrobat's Reading Order tool or the Order panel.
5. Add document metadata: a real document title (not the filename), the correct primary language, and bookmarks for any document longer than a few pages.
6. Label every form field with an accessible name and, where needed, a description, and set a logical tab order through the form.
7. Re-run the Accessibility Checker, then do a manual screen reader pass on the finished document before publishing.
8. Re-verify after every substantive edit. A PDF that was accessible last year is not guaranteed to still be accessible after a content update — tags do not automatically follow new content dropped into the file.

PDF Accessibility and ADA / Section 508 Compliance

Government context. Section 508 requires federal agencies to ensure their electronic content, including PDFs, is accessible — this covers everything from internal forms to public-facing publications. The DOJ's 2024 Title II final rule extends a parallel obligation to state and local government websites, requiring conformance to WCAG 2.1 Level AA for web content — and a PDF linked from a government website is squarely within that scope. A city that posts an inaccessible scanned PDF of a public notice has the same practical exposure as one with an inaccessible HTML page.

Business context. Under ADA Title III, private businesses that are places of public accommodation carry the same underlying obligation to make their goods, services, and information accessible — and PDFs (menus, financial disclosures, terms of service, downloadable forms) are routinely part of what a business publishes on its site. An accessibility review that only checks HTML pages and skips the linked PDFs is checking an incomplete site. Our guide to the ADA audit process covers how a thorough audit accounts for document assets like PDFs alongside page-level HTML issues, and our 7-step guide to making a website ADA compliant walks through prioritizing that remediation work.

Common Mistakes to Avoid

• Assuming a Word-exported PDF is automatically tagged correctly. Export settings matter; a default export without the accessibility option enabled produces an untagged file even from a well-structured Word document.
• Tagging over a scanned image without running OCR first. Tags cannot substitute for a missing text layer — there has to be real text underneath before tagging means anything.
• Relying solely on an automated checker. It catches structural gaps quickly but cannot judge whether alt text is actually descriptive or whether the reading order makes sense out loud.
• Forgetting form fields, charts, and infographics during remediation because attention goes to headings and body text first.
• Treating remediation as a one-time project. Every substantive edit to a PDF needs a re-check; tags do not regenerate themselves when content changes.

Ready to take the next step? Grow Wild Agency offers a free preliminary WCAG 2.1 AA scan that looks beyond your HTML pages to the documents linked from your site, so you know where your real exposure sits before a demand letter tells you.