How to audit your PDF library for accessibility: A practical guide

A PDF accessibility audit is a diagnostic, and like any diagnostic, its value depends entirely on what you do with the results. Most organizations audit once, close the ticket, and rebuild the same backlog within a year because the audit was never connected to a governance program.

Most teams treat it like a project: Find the broken files, fix them before the compliance deadline, and move on. A year later, the backlog is back. The authoring and publishing workflows that kept producing inaccessible PDFs just kept running, untouched, while the remediation team worked the queue. Auditing without governance creates this loop, and breaking it is what this guide is about.

This guide will explain how to:

• Map the governing standards so you know exactly what you're auditing against.
• Run a phased audit from inventory through severity scoring and prioritized remediation.
• Match tools to your library's scale.
• Build the compliance infrastructure that turns a one-time audit into an ongoing program.

Let's start with the standards. Using the wrong ones or conflating them are expensive mistakes an audit can identify.

Understand accessibility standards and guidelines

Getting the governing standard wrong on a PDF audit is its own compliance risk, and one that tends to surface during legal review, which is a worse time to find it, rather than internal testing.

I've watched teams spend months remediating PDFs against WCAG 2.1 Level AA, then get blindsided during a legal review because PDF/UA requirements were never on their radar. WCAG defines the accessibility outcomes a document needs to achieve. PDF/UA (ISO 14289) defines the structural implementation inside the PDF itself — tagging, reading order, navigation — as normative file-format requirements. WCAG addresses the same issue in its PDF Techniques, but those are informative examples of how to meet a success criterion rather than requirements. Both WCAG and PDF/UA matter, and for some organizations, so does a third standard.

The full picture of PDF accessibility compliance:

The laws that reference those standards:

What conformance looks like in a PDF: tagged document structure, logical reading order, alt text on meaningful images, decorative images marked as artifacts, accessible form fields, correct language declaration, and sufficient color contrast. The standard you're auditing against determines which criteria apply, but most of these requirements show up across all of them.

Under Section 508, non-web documents such as PDFs are excepted from four WCAG success criteria (2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification) because those criteria describe navigation across a set of web pages rather than within a single document.

Step-by-step process for conducting a PDF accessibility audit

A PDF accessibility audit produces a prioritized remediation queue that can be assigned, tracked, and acted on only when it is run as a phased process rather than a grab-bag spot-check of whatever files surface first.

I've seen teams kick off audits by pulling the 10 most-visited PDFs and calling it scope. That's not an audit; it's a sample with a false sense of coverage. The phases below are what separate a defensible, documented audit from a well-intentioned, but ultimately patchwork, review.

Phase 1: Inventory and scope definition

Before anything gets scanned, you need a complete count of what you're dealing with. Pull every published PDF from your CMS, intranet, and any third-party-hosted document libraries. Flag each PDF by use type (public-facing, program access, legal notices) because a document currently used to apply for, gain access to, or participate in your services carries obligations that an incidental publication does not. For organizations managing ADA Title II document accessibility, this inventory is what lets you apply the rule's exceptions defensibly rather than guessing at them.

Public entities should note that the Title II rule excepts five categories from the technical standard in 28 CFR 35.201. Two of the five apply directly to documents: archived web content meeting the four-part definition, and preexisting conventional electronic documents such as PDFs, word processor, presentation, and spreadsheet files already published before the compliance date unless they are currently used to apply for, gain access to, or participate in the entity's services, programs, or activities.

Inventory everything; the exceptions determine what enters the remediation queue, not what enters the inventory.

Phase 2: Automated scanning

Automated tools run through large document sets quickly, catching structural failures such as missing tags, absent alt text, and incorrect language declarations across hundreds of files at once. Running an accessibility check at this stage tells you what is broken at scale; it can't tell you how bad the experience is for someone using a screen reader. Reading order problems, table logic, and form field usability require human judgment, which is where the next phase comes in.

Phase 3: Manual verification

Complex elements need eyes on them. Multi-column layouts, data tables with merged cells, PDF forms, and documents with visual-only information all require manual testing (ideally with a screen reader like NVDA or JAWS) to identify the failures that automated tools score as passing.

Phase 4: Severity scoring and prioritization

Once findings are in, rank them by two factors: compliance risk and user impact. A missing document language declaration on a legal notice for program applicants ranks higher than a decorative image missing alt text in a staff newsletter. This scoring step is what turns an audit into a workable remediation queue.

Scale is where manual-only audits collapse. An organization with 2,000 PDFs can't perform screen reader testing on every file. The phased approach above is what makes large libraries manageable, with automation handling breadth and manual review handling depth on the highest-risk documents.

Tools and software for PDF auditing and remediation

The right PDF accessibility tool is the one that matches the scale of what you're dealing with. A free file-level checker is genuinely useful for a 20-document library, but it won't tell you anything meaningful about a collection of 2,000.

I've watched procurement teams default to free tools for large document libraries simply because "it's free." The reporting looks thorough until you realize it can only tell you about the file you uploaded, one at a time, with no way to see patterns across the collection or rank what to fix first. That's not an audit methodology; it's a very slow queue.

Here's how the tool categories stack up:

Two things are worth knowing about free tools before you write them off entirely. PAC 2026 is genuinely excellent for what it does: It checks the machine-testable requirements of PDF/UA and WCAG 2.1 Level A and AA, offers a screen reader preview so you can see what assistive technology users will encounter, and costs nothing. For individual document review or spot-checking high-priority files during a manual verification phase, it belongs in your tool kit.

Where free tools hit their ceiling is scope. They can't categorize failures across a library, identify which document types fail most often, or generate the prioritized remediation queue that makes large-scale fixing manageable. For that, you need a platform that treats your document library as a whole rather than as a series of individual files.

PDF remediation capability matters as much as auditing capability. A tool that identifies every failure but offers no pathways (guided workflows, auto-tagging, or integration with document management systems) to fix them just creates a longer list of problems.

Common accessibility issues in PDFs and solutions

The failures that show up most often in PDF audits aren't random errors. They come from the same handful of structural problems produced over and over by the same authoring habits, which means the fix is upstream in how documents get created, not in how they get remediated after the fact.

Personally, I've audited document libraries where 80 percent of the failures were traced back to two issues: untagged content and absent alt text. Both are completely preventable at the authoring stage. The table below covers types of highest-frequency failures and the workflow change that stops them from recurring.

The pattern across all of these is the same: The issues are created at authoring time and caught (expensively) at audit time. For sectors with high document volume, such as  government website accessibility and higher education PDF compliance, the cost of remediating preventable failures compounds fast.

Proactive measures change the math. Accessible authoring templates produce an accessible PDF by default, with tagged structure and correct heading hierarchy built in. Pre-publish checklists catch missing alt text and language declarations before a document goes live. Creator training means the person writing the report understands why a merged table cell creates a screen reader failure. None of this is complicated. It's just infrastructure that most teams skip because remediation feels like a later problem … until it isn't.

Ensure ongoing compliance and accessibility

A PDF audit run as a one-time project produces a one-time result. The backlog gets cleared, new inaccessible documents start accumulating, and the same audit is run again 18 months later.

An audit's real purpose is building the infrastructure that breaks the cycle. That infrastructure has three components.

Automated monitoring. Publishing workflows need ongoing scanning of your PDF library, not just periodic manual reviews. Track failure rate on new publications and documents remediated per quarter. These are the KPIs that make progress visible to leadership. An ADA Title II compliance checklist maps neatly onto this monitoring cadence for public entities.

Ownership assignment. Every content-producing team needs someone accountable for accessibility standards, with escalation paths that stop noncompliant documents from getting published. Distributed ownership without clear accountability is how remediation backlogs rebuild themselves.

Adaptive governance. WCAG 2.2 is already published and is the current W3C Recommendation. WCAG 3.0, renamed W3C Accessibility Guidelines, is still a Working Draft. A Candidate Recommendation is anticipated in late 2027, but a final recommendation is unlikely before 2028.

On the EU side, EN 301 549 v4.1.1 was published in September 2026 and moved the web, document, and software clauses to WCAG 2.2 Level AA. However, it does not become the reference for presumed conformity until the Commission cites it in the official journal, which has not yet happened, at the time of writing this article. Static compliance programs built against last year's requirements will need rebuilding, but governance structures designed to absorb standard updates don't.

Stop remediating the same PDFs twice

PDF accessibility is a governance problem wearing a technical disguise. The requirements (tagging, alt text, reading order, accessible tables) are all learnable and fixable. What most organizations lack are the systems to audit at scale, prioritize what gets fixed first, assign ownership, and stop new inaccessible documents from entering the library.

If you've built governance infrastructure for web accessibility, you already have the foundation. The audit is where you start because you can't prioritize what you haven't measured. Begin by establishing the full scope of your document library. Everything else follows from that.