Many teams struggle with PDFs that fail these checks without realizing it. Untagged exports, incorrect reading order, scanned pages with no real text, inaccessible tables and forms, missing metadata, and last-minute design edits made without retesting all quietly break the experience for assistive technology users.
This guide walks through the full workflow: spotting common barriers, combining automated and manual testing, fixing issues in the right order, validating your work, and knowing when it's smarter to rebuild a PDF from scratch rather than patch it.
TL;DR
- Most PDF failures stem from structure, reading order, alt text, tables, forms, contrast, or metadata gaps.
- Automated checkers catch technical gaps but can't judge whether alt text makes sense or a screen reader experience is actually usable.
- The core process: review the source file, run automated checks, inspect manually, remediate by priority, then retest.
- Recreate a PDF when it's image-only, severely mis-tagged, or would take longer to fix than to rebuild.
Common PDF Accessibility Problems and Their Root Causes
PDF failures follow patterns. Once you recognize the pattern, you stop patching symptoms and start fixing the actual source — which saves time on every future document.
Missing or Incorrect Tags
Semantic tags tell assistive technology what's a heading, a paragraph, a list, a table, or a decorative artifact. Without them, a screen reader has no idea what it's reading.
A common trap: text styled to look like a heading (bigger font, bold) with no actual heading tag applied. Visually it reads as a heading. Structurally, it's invisible to a screen reader.
Likely causes:
- Exporting from a source file that was never built with accessible structure
- Trusting automatic tagging without a manual review pass
- Editing the PDF after tagging, which silently breaks the tag tree
Incorrect Reading Order and Heading Hierarchy
Multi-column layouts, sidebars, pull quotes, and floating text boxes are visually intuitive but structurally chaotic. A screen reader may jump from a headline to a footer, then back to body copy, based on tag order rather than visual position.
According to W3C guidance, reading order in a tagged PDF is determined by tag order, not visual layout. A page that looks perfectly organized on screen can still read as gibberish to assistive technology.
The fix requires checking two things separately:
- The tag tree: does the underlying structure follow a logical sequence?
- The screen-reader pass: does it actually sound coherent when read aloud?
Heading hierarchy creates a related failure mode. Skipped levels (jumping from H1 straight to H4) break a screen reader user's ability to skim by heading.
Missing, Vague, or Incorrect Alternative Text
Not every image needs the same treatment.
- Meaningful images (charts, diagrams, logos with informational purpose) need concise alt text describing their purpose or content.
- Decorative graphics (borders, spacers, stock photography with no informational value) should be hidden from assistive technology entirely.
The trap teams fall into: writing alt text like "chart" or "image1.png" for a graphic that actually contains critical data. If a chart can't be summarized in a short alt tag, the underlying data needs to exist in the surrounding text too.
Inaccessible Tables, Links, and Forms
Bold text isn't automatically a table header, and "click here" isn't useful link text for someone navigating by a links list rather than scanning a page visually.
Tables need:
- Proper header tags (not just bold formatting)
- Defined row and column relationships
- Correct scope on merged cells
Forms need:
- Labels and tooltips tied to each field
- A logical tab order
- Clear instructions for required fields and error states
Links need:
- Descriptive text that makes sense out of context
- Confirmed keyboard operability
Scanned Pages, Contrast, Metadata, and Security Restrictions
Image-only scans have no real text underneath, so a screen reader sees nothing at all. These need OCR, followed by proofreading and correct tagging of the recognized text.
Beyond scans, several smaller issues stack up fast:
- Contrast below WCAG's required 4.5:1 ratio for normal text and 3:1 for large text
- Missing document language, which breaks pronunciation for screen readers
- Generic titles like "Document1.pdf" instead of a descriptive title
- Security settings that block text extraction, which can disable screen-reader access entirely
How to Test PDF Accessibility
No single method catches every issue. Effective testing blends three approaches: automated checking, manual inspection, and assistive technology testing.
Define scope and applicable standards. Record the PDF's purpose, audience, language, interactive features, and source file before testing anything. Determine which rules apply — WCAG 2.2 AA, PDF/UA, Section 508, or a client's procurement requirements.
Run an automated accessibility check. Tools like Adobe Acrobat Pro's Accessibility Checker, PAC, PAVE, or Foxit catch missing tags, missing metadata, untagged content, missing alt-text fields, and some table, form, and language failures. None of them catch everything.
Review the report and prioritize findings. Group issues by document-wide problems, page-level problems, and user-impact severity. Fix barriers that block access to the entire document first — broken navigation, inaccessible forms, missing structure — before cosmetic warnings.
Perform manual inspection. Check the tag tree, heading hierarchy, list structure, table relationships, link purpose, alt-text accuracy, document language, title, and tab order by hand. Zoom in, check reflow, and look for information conveyed only through color.
Test with assistive technology and keyboard navigation. Section 508's testing guidance requires a dedicated screen reader and accessibility API for conformance testing; Adobe's built-in Read Out Loud feature alone isn't enough. Navigate by heading, tab through links and forms, and confirm tables and images make sense when read aloud.
Record evidence and retest after changes. Save the original report, remediation notes, tool versions, and final validation results. Any layout or content change means a retest, not an assumption.
At Yes Yes Know, every PDF page we remediate goes through automated and manual testing before delivery. Clients receive an ACR and PAC report with the finished files so the results are documented, not assumed.
How to Fix PDF Accessibility Issues
Fix the source document first whenever you can. Correcting structure upstream, in Word, InDesign, or wherever the file originated, means every future export inherits the fix instead of requiring repeated manual patching.
Fix Document Structure, Tags, and Reading Order
- Add or correct semantic tags for headings, paragraphs, lists, tables, figures, links, and artifacts
- Repair heading hierarchy from actual content structure, not visual styling
- Reorder the tag tree to match a logical reading sequence, then confirm with a screen-reader pass
Add Meaningful Alternative Text
- Write alt text that conveys the purpose of an image, not only its appearance
- For data-heavy charts, add a longer text equivalent nearby instead of cramming everything into an alt tag
- Mark decorative borders and repeated visuals as artifacts so they don't create noise
Repair Tables, Lists, Links, and Forms
- Correct table tags and header relationships so screen readers announce the right header while moving through cells
- Simplify overly complex tables where possible
- Add descriptive link text and accessible form labels, tooltips, and tab order
- Confirm keyboard operability across every interactive element
Improve Text, Metadata, OCR, and Document Settings
Run OCR on scanned pages, then proofread the recognized text. OCR errors are common and easy to miss.
Add a meaningful title, the correct document language, and useful bookmarks. Check that security settings don't block text extraction or screen-reader access.
Confirm text meets contrast minimums, and don't rely on color alone to convey meaning.
Validate the Completed Remediation
Rerun the automated checker and confirm flagged issues are actually resolved, not just marked as ignored. Repeat manual and assistive-technology testing on high-impact pages. An automated pass only confirms technical checks. Real validation means someone navigated the document the way an end user would.
When to Recreate a PDF, Involve an Expert, and Prevent Recurrence
Remediation makes sense for a well-structured, editable PDF with a manageable number of issues. Recreating the file is often faster when:
- The document is primarily a scanned image with no usable text layer
- Tagging is severely broken across most pages
- The file has been edited repeatedly without a clean source version
- No accessible source document exists to rebuild from
Bring in outside expertise for:
- Long or highly technical documents (data-heavy reports, financial disclosures, regulated materials)
- Complex tables and interactive forms
- Large document libraries needing a repeatable process
- Unresolved failures during assistive-technology testing
- Procurement situations requiring a VPAT or formal audit trail
A per-page complexity model keeps scope and cost clear. Yes Yes Know prices remediation in three tiers:
- $20 per page for simple plain-text pages
- $50 per page for moderate pages with basic tables and clear heading structure
- $90 per page for complex pages with detailed alt text, intricate tables, form elements, or translation work
Founder Jen Bullard, CPACC-certified through the International Association of Accessibility Professionals, has over 20 years of UX experience on regulated, data-heavy B2B software—the document complexity this model is built for.
To prevent recurrence:
- Build from accessible source templates
- Use consistent heading and table styles across teams
- Preserve editable source files, not just final PDFs
- Add accessibility checks to your publishing workflow
- Maintain a PDF inventory with a clear owner
- Retest any time content or layout changes
Conclusion
A clean automated report isn't the finish line. Accessible PDFs require verified structure, meaningful alt text, logical navigation, and confirmation that the document actually works with real assistive technology.
Teams that get this right early spend far less time firefighting compliance issues later:
- Choose accessible source formats from the start
- Prioritize fixes by impact
- Document testing as you go
- Retest after every change
That upfront discipline is what makes accessibility maintainable instead of a recurring scramble.
Frequently Asked Questions
What are the three types of accessibility testing?
Automated testing (software scans for technical failures), manual inspection (human review of tags, order, and meaning), and assistive technology testing with real screen readers and keyboard navigation. You need all three because each catches issues the others miss.
What are the ADA requirements for PDFs?
ADA obligations for public-facing digital content generally require accessibility, but exact requirements depend on your organization type and context. Check current ADA.gov guidance and applicable WCAG or Section 508 criteria rather than treating any single article as legal advice.
Can automated tools alone fix a PDF?
No. Automated tools flag technical gaps like missing tags or metadata, but they can't judge whether alt text is meaningful or reading order actually makes sense aloud. Manual review is required.
How much does professional PDF remediation typically cost?
Pricing usually scales with page complexity. Yes Yes Know's tiers run $20 per page for simple text, $50 for moderate tables and headings, and $90 for complex imagery, tables, or forms.
Is a scanned PDF always a recreate situation?
Not necessarily. Scanned pages need OCR followed by proofreading and correct tagging. That is standard remediation, not an automatic rebuild-from-scratch.
