Introduction
Every PDF your organization publishes is a potential access point, or a potential barrier. One in five Americans lives with a disability, and many rely on screen readers, keyboard navigation, or magnification software to read documents online.
When a PDF is untagged, image-based, or poorly structured, it locks these users out entirely. That's not just a usability problem.
Businesses that ignore digital accessibility face real legal exposure: more than 700 ADA-related lawsuits targeted digital accessibility failures in 2023 alone, and a quarter of those defendants had already been sued before.
This article focuses specifically on PDFs. ADA is the legal framework; standards like WCAG, Section 508, and PDF/UA define what "accessible" means in practice. We'll cover:
- Creating accessible source files
- Remediating existing PDFs
- Testing your work
- Keeping accessibility intact as documents change
Key Takeaways
- Accessible PDFs need structure, reading order, navigation, forms, and descriptions—not just selectable text
- Automated checkers catch structural errors but miss reading-order quality and real assistive-technology usability
- Build accessibility into source workflows (Word, PowerPoint, design) instead of fixing PDFs after export
- Prioritize large document libraries with clear ownership and documented quality assurance
What PDF Accessibility Means for ADA Compliance
The ADA became law in 1990, decades before PDFs existed. Courts and regulators have since applied its nondiscrimination principles to websites, apps, and digital documents, though the exact legal duties vary by organization type, funding source, and jurisdiction.
Enforcement has followed that shift. In 2014, the DOJ intervened after the National Federation of the Blind alleged that H&R Block’s website and mobile app were inaccessible to blind, deaf, and physically disabled users. H&R Block settled under a consent decree and paid $100,000 in damages.
The Standards That Define "Accessible"
ADA does not define technical criteria by itself. Organizations typically map compliance work to these standards:
- WCAG (Web Content Accessibility Guidelines) sets technology-neutral success criteria used for web and document accessibility
- Section 508 covers federal technology and procurement and incorporates WCAG-based criteria
- PDF/UA (ISO 14289-1) defines the structure required for an accessible PDF
- VPAT documents how a product or service meets accessibility criteria and is often required in procurement
For state and local government entities, DOJ's Title II rule sets WCAG 2.1 Level AA as the technical standard for covered web content and mobile apps, with compliance dates that depend on population size and entity type.
When a PDF Becomes a Barrier
A PDF creates an accessibility problem the moment it's:
- Posted on a public-facing website
- Used during a procurement or application process
- Distributed as instructional or training material
- Required to access a service, benefit, or transaction
If that PDF is untagged, scanned without OCR, or impossible to navigate by keyboard, it excludes users who rely on assistive technology—even when the layout looks fine on screen.
A note on legal guidance: Compliance dates, exceptions, and alternative-format rules change. This article is educational, not legal advice—confirm current DOJ Title II and state obligations with qualified counsel before making compliance claims.
PDF Accessibility Requirements: A Practical Checklist
PDF accessibility is a set of structural and design decisions that work together—not a single toggle or export setting.
Structure and Reading Order
Real, selectable text is the baseline. Beyond that, every PDF needs accurate tags: headings, paragraphs, lists, tables, figures, and links that reflect the document's actual semantic structure rather than just its visual layout.
Reading order matters as much as the tags. Screen readers follow tag order, not the visual layout on the page:
- Set a consistent heading hierarchy (H1, then H2, then H3, in order)
- Add bookmarks for longer documents
- Specify a descriptive document title and the correct language
- Confirm tab order matches the logical reading sequence
Non-Text Content
Every informative image or chart needs concise, meaningful alt text. Purely decorative elements should be tagged as artifacts so screen readers skip them entirely. Complex graphics, diagrams, and mathematical content need an equivalent explanation, not just a one-line description.
Tables, Forms, and Links
Tables require proper header tags and relationships that assistive technology can interpret. Avoid unnecessarily complex layouts, like merged cells or nested tables, when a simpler structure will do.
Forms need:
- A visible label for every field, programmatically tied to that field
- Tab order that matches the visual flow
- Error messages that state what went wrong and how to fix it
Links should describe their destination. "Click here" tells a screen reader user nothing; "download the 2026 benefits guide (PDF)" does.
Visual and Interaction Requirements
- Verify text-to-background contrast meets WCAG minimums (4.5:1 normal text, 3:1 large text)
- Never rely on color alone to convey meaning (like marking required fields only in red)
- Confirm content stays usable when zoomed
- Preserve keyboard access to every link, control, and form field
Before you publish, confirm:
- Selectable text, tags, and logical reading order
- Heading hierarchy, document title, and language
- Alt text, table headers, and descriptive links
- Form labels, tab order, and error messaging
- Contrast, zoom behavior, and full keyboard access
If any item fails, remediate before release.
How to Create or Remediate an Accessible PDF
The cheapest accessibility work happens before the PDF export, not after.
Start With the Source File
Build accessibility into the authoring file before you export:
- Use built-in heading and list styles instead of manually bolding text
- Add alt text to images before export
- Keep tables simple and use descriptive link text
- Set the document language in the file's properties
- Run your authoring tool's built-in accessibility checker before export
The Export Process Matters
Save or export using accessibility-preserving settings that carry over tags and structure. Avoid print-to-PDF workflows whenever possible. Microsoft has documented that files created through the Print command can lose accessibility tags and other structural metadata entirely, forcing you to rebuild the structure from scratch.
Remediating an Existing PDF
If you're starting with an already-published document, follow this sequence:
- Inspect the document and run an automated accessibility checker
- Add or repair tags, then correct the tag tree and reading order
- Add or revise alt text for all informative images
- Fix table structure and form field labels
- Set language and title metadata
- Address contrast issues or defects that trace back to the source file
Scanned and Image-Only PDFs
Scanned documents need OCR (optical character recognition) before they can have any real text layer at all. OCR accuracy depends heavily on scan quality, lighting, and font clarity, so treat it as a starting point, not a finish line. Review the recognized text for errors, especially with complex layouts, unusual fonts, or handwriting, then manually add tags and descriptions.
Difficult Document Types
Multi-column brochures, long reports, interactive forms, math notation, and documents with repeated headers or footers all present unique remediation challenges. For some of these, especially highly visual layouts, a redesigned source document or an accessible HTML alternative delivers a better experience than forcing an inaccessible layout into a tagged PDF. At Yes Yes Know, our per-page remediation work is priced by complexity for exactly this reason. A basic report with clean heading hierarchy and simple tables (our MODERATE tier, $50 per page) requires far less work than a document full of charts, diagrams, and fillable signature fields (our COMPLEX tier, $90 per page). If your organization publishes recurring agendas, manuals, or policies, building accessibility into the source template will always be more sustainable than remediating the same document type over and over.
How to Test and Maintain PDF Accessibility
Automated checkers are a useful first pass, not a finish line. Adobe Acrobat's built-in checker and other standards-oriented validators flag missing tags, untagged content, and other structural issues quickly. But a passing report doesn't prove full ADA or WCAG conformance.
WebAIM's 2026 analysis of the top one million home pages found an average of 56.1 accessibility errors per page, with low-contrast text on nearly 84% of pages. Automated tools flagged plenty of it, but WebAIM notes these tools "cannot automatically detect all conformance failures."
What Manual Review Catches
- Inspect the tag tree directly and confirm reading order matches the visual flow
- Navigate the entire document using only a keyboard
- Tab through every form field to check order and labeling
- Test zoom and reflow behavior
- Listen to the full document using a screen reader like NVDA or VoiceOver
For business-critical documents, test with more than one assistive technology. NVDA and JAWS remain the two most-used desktop screen readers, according to WebAIM's most recent user survey, and they don't always behave identically with the same PDF.
Documenting Your Work
Keep a record for each tested document that includes:
- Document version and applicable standard (WCAG 2.2 AA, Section 508, etc.)
- Testing tools used and manual checks performed
- Known limitations and remediation owner
- Review date and escalation path for unresolved issues
Content changes reintroduce defects. A document that passed testing last year can fail today if someone added an untagged image last month. Recurring documents need a repeatable review step, not a one-time certification.
That maintenance risk is why automated checks and manual review belong together. Our accessibility audits pair automated scanning with manual screen-reader testing and, where possible, usability testing by people who use assistive technology day to day.
Founder Jen Bullard holds a CPACC certification through the International Association of Accessibility Professionals. The credential strengthens how we approach the work; it does not replace document-level testing or guarantee legal compliance on its own.
How to Build a Sustainable PDF Accessibility Program
One-off remediation projects solve today's problem. A program prevents tomorrow's.
Inventory and Prioritize
Start by cataloging your document library and ranking each file by:
- Audience impact and public availability
- Legal or procurement importance
- Frequency of use and document age
- Support for an essential service or transaction
Fix the documents tied to essential services first. A benefits application form matters more than an archived newsletter from three years ago.
Assign Real Ownership
Accessibility fails when it's "everyone's job," meaning no one's job. Assign clear responsibility across content, design, product, engineering, procurement, and legal teams.
Document the rules for:
- Accessible source files
- Approved export methods
- Remediation steps
- Version control
Know When to Redesign Instead of Remediate
Sometimes the better move is a redesigned source document or an accessible HTML alternative rather than repeated PDF patching.
Any alternative version must provide substantially equivalent information, timeliness, privacy, and ease of use—not a stripped-down substitute. Confirm the approach against applicable legal guidance.
Where Specialist Support Fits
Organizations running complex B2B, SaaS, fintech, or cybersecurity products often have document libraries as tangled as their software interfaces.
Yes Yes Know's accessibility audit combines automated tools, manual testing with NVDA or VoiceOver, and keyboard-only navigation checks. Findings map to specific WCAG 2.2 AA criteria with severity ratings from critical to minor.
The flat-fee audit runs $5,000, with a report delivered within 10 business days of kickoff. It covers both product interfaces and the document libraries that support them.
Before publishing any compliance claim or VPAT statement, research current WCAG revisions, Section 508 requirements, and any state or federal obligations that apply to your organization. Standards shift, and yesterday's compliant document isn't automatically compliant today.
Frequently Asked Questions
Can a PDF be ADA compliant?
Yes. Proper tags, reading order, text alternatives, and assistive-technology testing can make a PDF accessible. Whether that meets your ADA obligations still depends on the legal and technical standards that apply to your organization.
What are the ADA requirements for PDFs?
There's no single ADA checklist for PDFs. Most organizations follow WCAG or Section 508 for structure, selectable text, alt text, reading order, tables, forms, and keyboard use—then validate against the standard that applies to them.
What is required for 508 compliance?
Covered federal technology and procurement generally must meet the Revised Section 508 Standards, which incorporate WCAG 2.0 A and AA for web and non-web content. Confirm the current standard and scope for your situation.
What are the new WCAG guidelines for 2026?
WCAG 2.2 remains the current W3C Recommendation. WCAG 3.0 exists only as a working draft, not a finalized standard, so don't base compliance claims on it yet. Always verify the latest published version and the legal standard governing your organization.
What are 508-compliant instructional materials?
They are training docs, manuals, worksheets, and courses that work with assistive technology—tagged structure, accurate alt text, and accessible tables and forms. Test them before distribution, not after complaints arrive.
What is an ADA compliance document?
The phrase can refer to an accessible document itself, an internal accessibility checklist, a compliance statement, or supporting evidence like a VPAT. If people with disabilities need to use the document, the document itself must be accessible, regardless of what you call it.
