The Audit Everyone Passes, Then the Folder Nobody Checks
A SaaS company spends the better part of a year getting its marketing site to WCAG 2.1 AA. Alt text gets added. Contrast gets fixed. Keyboard traps get untangled. The homepage, the pricing page, the blog — all of it gets tested, remediated, and signed off.
Then someone opens the resources page.
Forty whitepapers. Product spec sheets going back three years. An annual report. A dozen gated ebooks sitting behind lead-capture forms, each one exported straight out of InDesign with the default settings, each one a PDF that a screen reader can barely make sense of.
Nobody thought of these as "the website." They're just documents. Files people download. But to a screen reader user — and to a plaintiff's attorney building a case — they're indistinguishable from any other piece of content the company chose to publish. A PDF isn't a legal loophole around accessibility obligations just because it isn't a webpage in the traditional sense. If it's used to convey information or transact business, it's covered by the same standards as the page that links to it.
And gated lead magnets are, ironically, the worst offenders. They're the documents a company is proudest of — the ones built to capture the most leads — and also the ones nobody accessibility-tests, because everyone's attention was on the site that sits around them.
Why "It Opens Fine" Isn't the Same as "It's Accessible"
Open an untagged PDF visually and it looks completely normal. Two columns, a logo, a chart, body copy in a clean sans-serif. Nothing about it looks broken.
Run a screen reader over that same file and the experience can fall apart immediately. Without an underlying tag structure, there's no reliable reading order at all. A two-column layout that a sighted reader scans top-to-bottom, column by column, gets read by assistive technology straight across both columns — sentence fragments from column one interleaved with sentence fragments from column two, in an order that makes no sense.
This is the core distinction to understand: a PDF has a visual layer and, separately, a structural layer. The visual layer is what prints and what displays on screen. The structural layer — the tag tree — is what a screen reader actually reads from, the same way it reads DOM structure on a webpage. A "print to PDF" export or a hurried InDesign export with tagging skipped produces a file with a rich visual layer and effectively no structural layer underneath it. It looks finished. It isn't.
The Standard Built Specifically for This: PDF/UA
WCAG covers a huge range of content types, but PDFs also have a dedicated technical standard written specifically for them: PDF/UA, formally ISO 14289. It works alongside WCAG rather than replacing it.
In practice, a PDF gets evaluated on two tracks at once:
- Against relevant WCAG success criteria — alt text for images, logical reading order, sufficient color contrast, properly labeled form fields.
- Against PDF/UA's structural requirements — a complete, correct tag tree that maps the document's headings, paragraphs, lists, tables, and figures the way HTML maps a webpage's structure.
A document can partially satisfy one track and completely fail the other. A whitepaper might have decent contrast and clear language — solid on the WCAG side — while still having zero tags, which fails PDF/UA outright and leaves a screen reader with nothing usable to read from. Both tracks matter, and neither substitutes for the other.
Where These Files Actually Break
The failures aren't exotic. They're the same handful of problems, repeated across thousands of documents that all trace back to the same rushed export settings.
Missing or wrong alt text. Images inside a PDF need real, descriptive alt text — the direct equivalent of WCAG's 1.1.1 Non-text Content requirement on the web. A chart showing quarterly revenue growth needs alt text describing what the chart actually communicates, not "image1.png" or nothing at all. Just as important on the flip side: purely decorative elements — a background flourish, a repeated logo watermark — should be marked as "artifacts" in the tag tree so a screen reader skips them entirely instead of announcing meaningless visual noise on every page.
Unlabeled form fields. Fillable PDF forms — think government intake forms, contracts, or applications distributed as PDFs — need labeled fields, mirroring the same requirements that apply to web forms (1.3.1, 4.1.2, 3.3.2). An unlabeled field in a PDF form is announced by a screen reader exactly the way an unlabeled HTML input is: "edit, blank." No field name, no idea what's being asked for, field after field.
Reading order that doesn't match the visual layout. A document whose tag order doesn't line up with its visual columns fails the same way an HTML page with disordered DOM structure fails — content gets read in an order no one intended, regardless of how clean it looks on screen.
Contrast failures baked into brand templates. Light-gray body text on a white background is just as much a contrast failure in a PDF as it is on a webpage. Brand style guides that specify a soft gray for body copy often carry that choice straight into every PDF template a company produces, multiplying the same failure across every document built from it.
A Practical Starting Checklist
Before remediating a document library, it helps to know what to actually check for in each file:
- Does the document have a real tag tree, or was it exported without tagging entirely?
- Does the tag order match the visual reading order, especially in multi-column layouts?
- Does every meaningful image have descriptive alt text, and is every decorative element marked as an artifact?
- Are all fillable form fields labeled so a screen reader announces the field's purpose, not just "edit, blank"?
- Does body text meet contrast requirements, especially in templated designs inherited from brand guidelines?
- Have tables been checked for correct header associations, not just visual borders?
Tools Help. They Don't Finish the Job.
Adobe Acrobat Pro's built-in accessibility checker and tagging tools are the most common starting point for remediation, alongside dedicated PDF remediation software built for the same purpose. These tools are genuinely useful — they can auto-tag a large batch of documents, flag missing alt text, and catch obvious structural gaps quickly.
What they can't do is finish the job on their own. Auto-tagging catches some issues reliably and misses others consistently, particularly in complex layouts, tables, and forms. A multi-column whitepaper with embedded charts and a pull quote is exactly the kind of document where automated tagging gets the easy 80% right and leaves the hard 20% — the part a screen reader user actually needs — requiring manual review and correction of the tag tree by someone who understands how the structure needs to read.
The Documents Most Likely to Get Named
The pattern worth remembering: the highest-risk PDFs are exactly the ones a business publishes the most of and thinks about the least. Gated lead-magnet whitepapers. Spec sheets. Annual reports. Terms of service and privacy policies. Government-facing forms.
These are high-volume, low-attention documents — produced by marketing or legal teams on a deadline, exported once, and left untouched for years. They're also, not coincidentally, exactly the kind of document a demand letter loves to cite: publicly available, easy to test, easy to demonstrate as inaccessible, and directly tied to a company's core business activity.
Closing the Blind Spot
A fully WCAG-compliant website sitting next to a resources page full of untagged PDFs isn't a compliant company. It's a company that fixed the part everyone was looking at and left the part nobody checks wide open — and the two carry the same legal exposure, because both are content the company chose to publish and both are covered by the same underlying obligations.
The fix isn't glamorous, but it's finite: audit the document library, prioritize the highest-traffic and highest-risk files first — the gated whitepapers, the forms, the policies — and get proper tag structure, alt text, labeled fields, and contrast in place, with manual review wherever automated tools leave gaps.
If your team has spent real effort making the website accessible and hasn't yet looked hard at the PDFs sitting behind it, that's the blind spot worth closing next. Talk to us about getting your documents audited before one of them ends up as an exhibit instead of a lead magnet.