Why Your PDFs Are a Compliance Risk (And What to Do About It)

If your organization has been working through its website accessibility checklist, you’ve probably focused on the obvious things: headings, color contrast, navigation, alt text on images. But there’s a good chance you’re overlooking the single largest source of accessibility barriers on your site.

Your PDFs.

Research from Allyant found that 94.75% of public-facing PDFs fail basic accessibility standards. A Carnegie Mellon study of academic PDFs found that fewer than 3.2% met minimum accessibility criteria, and 74.9% failed every single test. And 72% of users with disabilities say inaccessible documents directly hinder their ability to do their job or complete coursework.

These aren’t edge cases. If your website links to PDFs, and almost every organization’s does, you almost certainly have an accessibility problem hiding in plain sight.

Why PDFs Are Different From Web Pages

Web pages have structure built in. HTML uses semantic tags like <h1>, <p>, and <table> that screen readers understand automatically. When you build a web page, the structure and the content are the same thing.

PDFs don’t work that way.

A PDF has two layers: a visual layer (what you see on screen) and a structural layer (what screen readers actually read). The visual layer is just drawing instructions. It knows where to place text and images on the page, but it has no concept of paragraphs, headings, or reading order.

The structural layer, called the tag tree, is what makes a PDF accessible. It maps every piece of content to semantic tags so assistive technology can navigate the document the way a sighted reader would.

Here’s the problem: most PDFs don’t have a tag tree at all. They’re “untagged,” which means screen readers either fail completely or read the content in a meaningless jumble. And even tagged PDFs frequently have incorrect tags, broken reading order, missing alt text, or tables that screen readers can’t interpret.

What the Law Actually Says About PDFs

Two federal rules currently drive document accessibility requirements.

DOJ ADA Title II (updated April 2024) requires state and local governments, public school districts, public universities, and municipal agencies to ensure all web content and electronic documents conform to WCAG 2.1 Level AA. This explicitly includes PDFs, Word documents, Excel spreadsheets, and presentation files. Compliance deadlines are April 26, 2027 for entities serving populations over 50,000, and April 26, 2028 for smaller entities.

HHS Section 504 (updated May 2024) applies the same WCAG 2.1 AA standard to healthcare organizations receiving federal financial assistance. Deadlines are May 11, 2027 for organizations with 15 or more employees, and May 10, 2028 for smaller organizations.

The DOJ rule does include limited exceptions. Archived content maintained solely for historical reference doesn’t need remediation, but only if it’s stored in a designated archive section, created before your compliance date, and not used for current operations. In practice, this exception is narrow. If a PDF is linked from an active page on your site, it needs to be accessible.

The Triage Strategy: What to Fix, Convert, or Archive

Most organizations don’t have 10 PDFs. They have hundreds, sometimes thousands. Remediating every single one isn’t realistic, and it isn’t necessary. What you need is a triage strategy.

Step 1: Audit your document library.

Find every PDF linked from your website. Tools like Adobe Acrobat Pro’s accessibility checker or PAC 2024 (a free tool from the PDF Association) can scan files and flag which ones have no tag tree, which have incomplete tags, and which pass structural checks. This gives you a baseline.

Step 2: Sort into three buckets.

Bucket A: Convert to HTML. Short, simple documents like event announcements, single-page policies, or staff directories should become web pages. HTML is inherently more accessible than PDF, easier to maintain, and works better on mobile devices. If the content changes often, it shouldn’t be a PDF.

Bucket B: Archive or remove. Old meeting minutes from 2019, expired program guides, documents nobody actually downloads. Move them to an archive section that meets the DOJ exception criteria, or remove the links entirely. If nobody is reading it, nobody needs it to be accessible.

Bucket C: Remediate. These are your high-priority, actively used documents. Intake forms, program applications, annual reports, patient education materials, board meeting agendas, employee handbooks, accessibility statements. Anything your audience needs to interact with. These are the files worth investing in.

Why Automated Tools Aren’t Enough

This is where a lot of organizations make a costly mistake. They run an automated accessibility checker, see a “pass” result, and assume the document is compliant.

Automated tools can catch about 30-40% of accessibility issues. They can verify that a tag tree exists, that the document has a title, and that fonts are embedded. What they can’t do is verify that the alt text on a chart actually describes the chart, that a multi-column layout reads in the right order, or that a complex data table has correct header-to-cell relationships.

The Matterhorn Protocol, which defines PDF accessibility testing standards, identifies 136 specific failure conditions. 87 can be checked by software. The other 49 require human judgment.

This is why “born accessible” documents are always better than remediated ones. If you author a document in Word or InDesign using proper heading styles, alt text, and accessible table structures, exporting to PDF produces a tagged document that’s mostly compliant from the start. The cost is essentially zero because it’s built into your content creation workflow. Remediation after the fact, by contrast, runs $2 to $15 per page depending on complexity, and requires specialized expertise.

But for legacy documents, remediation is your only option. And it needs to be done by people who understand both the PDF specification and how screen reader users actually experience documents.

What to Ask a Document Remediation Partner

If you’re evaluating remediation vendors, here are the questions that matter:

• Is the work done manually or through automated software? Automated tools alone cannot produce compliant PDFs. You need human verification.
• What conformance guarantee do you provide? The vendor should stand behind their work with a documented conformance report, not just a “best effort” promise.
• Do you test with actual screen readers? PAC and Acrobat’s built-in checker are necessary but not sufficient. Real testing with NVDA or JAWS is how you know a document actually works.
• What’s your turnaround time? Industry standard is 3-10 business days depending on volume and complexity. Anything faster should raise questions about quality.
• Do you handle complex documents? Scanned PDFs requiring OCR, interactive forms, multi-column layouts, and data tables all require different expertise. Ask for examples.
• What happens when the source document changes? If your vendor remediates a PDF and you later update the original Word file, the remediation is lost. Ask how they handle re-export and version control.