Standards 9 min read 14 October 2026

How to Audit a PDF for Accessibility: Tools, Checks, and Remediation

A PDF accessibility audit identifies barriers that prevent users with disabilities from accessing document content. This guide walks through manual and automated audit methods using PAC, veraPDF, and Acrobat Pro, explains the most common failures, and provides a practical remediation workflow.

A PDF accessibility audit evaluates whether a document can be fully used by people with disabilities — including users of screen readers, braille displays, keyboard-only navigation, and text-to-speech software. In regulated contexts (US federal agencies under Section 508, EU public bodies under the Web Accessibility Directive, organisations subject to ADA or EAA), audit results translate directly to legal compliance status. An audit is not a one-time checkbox. It combines automated tool analysis (which catches structural failures quickly and at scale) with manual human review (which is required for reading order, heading logic, alternative text quality, and table structure — things no tool can fully automate). Understanding both layers — and knowing which failures are most common, most serious, and most fixable — is the key to an efficient accessibility remediation programme. This guide walks through the complete audit process: what tools to use, what checks to run, what the most common failures are, and how to remediate them.

Automated audit tools

Automated tools perform a rapid structural analysis of a PDF, identifying failures that can be detected by code: missing tags, empty alternative text, incorrect colour contrast, missing document language, and structural anomalies. **PAC (PDF Accessibility Checker)** — PAC 2024 (free, Windows) is the primary automated PDF/UA validator. It implements the Matterhorn Protocol — the PDF Association's testing framework that classifies all PDF/UA failure conditions as machine-testable or human-testable. PAC 3's screen reader preview lets you hear how a screen reader would navigate the document. **veraPDF** — veraPDF (free, cross-platform) is the reference PDF/A and PDF/UA validator. Command-line batch mode makes it ideal for pipeline integration. The `-f ua1` or `-f ua2` flag validates against PDF/UA-1 or PDF/UA-2. **Acrobat Pro Accessibility Checker** — Tools > Accessibility > Accessibility Check. Runs a set of checks based on WCAG 2.x and PDF/UA. Provides a categorised results panel with "Fix" buttons for some failures. Less comprehensive than PAC for structural failures; more integrated for visual inspection. **axesCheck** — axesCheck is a free online PDF accessibility checker. Upload the PDF and receive a report with WCAG 2.1 criterion mapping. **Automated checks cover approximately 40–60% of PDF/UA requirements.** The remaining requirements are human-testable — they require reading the document and understanding its logical structure.

Manual audit checks: what tools cannot detect

Several critical accessibility requirements cannot be detected by automated tools and require human review: **Reading order** — Is the order in which a screen reader encounters content (determined by the structure tree and marked content sequence) the correct logical reading order for the document? Multi-column layouts, sidebars, pull quotes, and captions are the most common sources of reading order errors. Automated tools can detect technically invalid reading order; they cannot determine whether the order is semantically correct. **Alternative text quality** — Alt text presence can be detected automatically; alt text quality cannot. An image with alt text "image.png" passes the automated check but fails the meaningful accessibility test. Audit requires reading each image's alt text and assessing whether it conveys the image's purpose and content in context. **Heading hierarchy logic** — Are headings in the correct hierarchical order (H1 → H2 → H3 without skipping levels)? Does each heading accurately describe the content that follows it? Automated tools check structural heading levels; they cannot assess semantic accuracy. **Table header association** — Are table header cells (TH elements) correctly associated with their data cells? Complex tables with merged cells, nested headers, or irregular structures require manual verification that the association is logical. **Link text descriptiveness** — Are link destinations describable from the link text alone? "Click here" and "read more" are inaccessible; "Download the 2024 Annual Report (PDF, 2 MB)" is accessible. Automated tools check link presence; humans must assess whether the text is meaningful without context. **Language changes** — When a section switches to a different language (e.g., a French quotation in an English document), is the `/Lang` attribute on that structure element set correctly? Automated tools verify the document-level language; in-document language changes require manual checking.

Most common PDF accessibility failures

Based on accessibility audit experience across government, enterprise, and education sectors, these are the most frequently encountered failures: **1. Untagged document** — No structure tree at all. The entire document is a flat image of text to a screen reader. Fix: add tags in Acrobat Pro (Tools > Accessibility > Autotag Document) then manually correct reading order and heading structure. **2. Missing document language** — The `/Lang` entry is absent from the document catalogue. Screen readers cannot determine the document language and default to the system language. Fix: in Acrobat Pro, File > Properties > Advanced > Language. **3. Images without alternative text** — Figure structure elements have no `/Alt` attribute. Screen readers announce "Figure" with no description. Fix: right-click images in Acrobat's Touch Up Reading Order panel > Edit Alternate Text. **4. Incorrect reading order** — Structure tree sequence does not match visual reading order. Common in multi-column layouts. Fix: reorder using Acrobat's Reading Order panel or use an authoring tool that produces correct column reading order. **5. Non-descriptive link text** — Links labelled "here", "click", or a raw URL. Fix: update link text in source document or in Acrobat's link properties. **6. Form fields without accessible names** — Widget annotations have no tooltip (/TU entry). Screen readers cannot identify what the field is for. Fix: add tooltips to all fields in Acrobat's form field properties. **7. Tables without header markup** — Table cells are tagged TD but header rows are not marked as TH with scope attributes. Fix: use Acrobat's Touch Up Reading Order or Table Editor to promote header row cells to TH.

Remediation workflow and tools

After identifying failures, remediation depends on whether you have the source document or only the PDF: **With source document (preferred):** Fix accessibility issues at the source — in Word, InDesign, or LibreOffice — then re-export to PDF. This is always faster and more accurate than remediating in Acrobat. For Word: use Styles for headings, add alt text to images via Format Picture, mark decorative images as "Mark as decorative", use built-in table structure, run the built-in Accessibility Checker (Review > Check Accessibility) before exporting. **PDF-only remediation:** Adobe Acrobat Pro — The primary remediation tool. Touch Up Reading Order panel, Tags panel, Form Fields, and Alt Text editor cover all common repairs. Labour-intensive for complex documents. CommonLook PDF — Specialised PDF accessibility remediation tool. Provides a guided wizard that walks through each failure with context, making high-volume remediation faster than Acrobat. axaio MadeToTag (InDesign plugin) — Fixes accessibility directly in InDesign before PDF export, which is significantly more efficient than remediating the exported PDF. **Batch remediation priorities:** Focus on high-traffic documents first. Add automatic tagging to the PDF production workflow as a minimum baseline. Identify document templates and fix accessibility at the template level — one fix propagates to all documents generated from that template.

A PDF accessibility audit is not a single event — it is a programme. Automated tools provide fast initial screening and ongoing pipeline quality gates; manual review ensures that the accessibility is genuinely meaningful and not just structurally compliant. The highest return investment is fixing accessibility at the source (authoring tool level) and building validation into document production workflows, rather than continuously remediating exported PDFs after the fact.

Frequently asked questions

What is the difference between PDF/UA conformance and WCAG compliance for PDFs?

PDF/UA (ISO 14289) is a technical standard for accessible PDFs — it specifies structural requirements in terms of the PDF specification (tags, reading order, alt text, language). WCAG (Web Content Accessibility Guidelines) is a broader web accessibility standard. For PDFs, WCAG compliance is typically achieved by conforming to PDF/UA. The EU Web Accessibility Directive and US Section 508 refresh both reference WCAG 2.x as the technical standard; PDF/UA is the mechanism for achieving WCAG compliance in PDF documents.

Can automated tools fully audit PDF accessibility?

No — automated tools cover approximately 40–60% of PDF/UA requirements. They can detect structural failures (missing tags, absent alt text, no document language, malformed tables) but cannot evaluate reading order logic, alt text quality, heading semantic hierarchy, or in-document language changes. A complete audit requires automated tools plus human review, typically following the Matterhorn Protocol's checkpoint list.

How long does a PDF accessibility audit take?

It depends heavily on document complexity. A simple 10-page brochure with basic content may take 30–60 minutes for automated scan plus manual review. A 100-page technical report with complex tables, multi-column layouts, and many figures may take a full day. A form-heavy document (50+ fields) requires additional time for field accessibility verification. Batch audit of a large archive uses automated tools for initial triage; human review is then focused on high-priority documents that failed automated checks.

What is the Matterhorn Protocol?

The Matterhorn Protocol is a PDF accessibility testing framework published by the PDF Association. It lists 136 failure conditions derived from PDF/UA requirements, each classified as either machine-testable (detectable by automated tools like PAC) or human-testable (requiring manual review). Using the Matterhorn Protocol as an audit checklist ensures systematic, reproducible testing that covers both automated and manual aspects of PDF/UA conformance.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Annotate PDF Edit PDF text Fill PDF form Open editor