PDF Accessibility Basics for Teams That Share Documents

A university contact couldn't use our onboarding PDF — screen reader jumped from footer to heading to page number in random order. Visually? Fine. Structurally? A pile of coordinates pretending to be a document.

Accessibility isn't a niche charity feature for PDFs. It's whether the file makes sense when you can't rely on eyes scanning layout — voice navigation, reflow on small screens, search for a clause at 11 PM.

Who benefits (it's not a tiny group)

• Blind and low-vision users with screen readers
• Dyslexic readers using text-to-speech
• Mobile users reflowing content
• Search indexing inside document libraries
• Anyone copying quotes without retyping

When you ship scan-only PDFs, you ship barriers.

Core building blocks

1. Real text (not picture of text)

Digital exports from Word/Google Docs usually include text objects. Scans need OCR — optical character recognition — to add a searchable layer.

Test: try selecting a sentence. No selection = accessibility problem for text tools.

2. Tags (structure)

Tags mark elements semantically:

• Headings (H1, H2…)
• Paragraphs
• Lists
• Tables with row/column scope
• Figures with alt text

Untagged PDFs are "draw text here" instructions — fine visually, chaos for assistive tech.

3. Logical reading order

Multi-column layouts, sidebars, and footnotes need explicit order. PDF viewers guess wrong often — classic failure mode in annual reports.

4. Alt text on meaningful images

Decorative images can be marked artifact/ignored. Charts and diagrams need text descriptions — not empty alt.

5. Color and contrast

Light gray body text fails WCAG contrast. Accessibility includes legibility for low vision — not only screen readers.

Creating accessible PDFs at export time

Easier than repair later.

From Word

• Use built-in heading styles (Heading 1, 2) — not manual bold size
• Add alt text to inserted images (right-click → Edit Alt Text)
• Enable "Document structure tags for accessibility" on PDF export (Windows Word checkbox)
• Avoid text boxes floating over layout for main body content

See Word to PDF tips for broader export quality.

From slides

• Titles in title placeholder, not drawn text boxes
• Speaker notes aren't a substitute for slide alt text on charts

From scans

• OCR during scan workflow when possible
• Don't compress so aggressively OCR text becomes garbage

Fixing existing PDFs (harder path)

1. Run accessibility checker (Acrobat Pro, PAC, axesPDF — tool varies by budget).
2. Add tags manually or auto-tag with review — auto-tag always needs human pass.
3. Fix reading order panel — drag blocks into sentence order.
4. Add alt text to figures.
5. Re-test with screen reader sample (NVDA free on Windows, VoiceOver on Mac).

Browser tools like Merge PDF and Compress PDF typically don't rebuild tags — assume merge output needs re-check for regulated docs.

Merge and accessibility

Combining accessible cover letter + untagged scan appendix = partially accessible packet. Common in mixed PDF workflows.

Mitigations:

• Tag digital sections properly before merge
• OCR scan sections
• Run checker on merged file
• Provide HTML or accessible Word alternative for critical forms when PDF can't be fixed quickly

Common team mistakes

"We PDF'd it so it's final"
Final visually ≠ accessible structurally.

Scanned forms with no fillable fields
Users retype everything; screen readers can't help.

Using merge without checking page 1 tags post-merge
Tags silently drop.

Legal disclaimers as images
Must be real text or read aloud via alt.

Ignoring metadata
Title field helps navigation — empty title hurts orientation in screen readers.

Lightweight checklist before external publish

• [ ] Text selectable (or OCR applied)
• [ ] Headings use styles / tags exist
• [ ] Reading order sanity-checked
• [ ] Images have purposeful alt text or marked decorative
• [ ] Tables have header rows tagged
• [ ] Contrast readable (not faint gray)
• [ ] Merged files re-validated

Privacy and tooling

Accessibility checkers and remediation often run offline on sensitive docs — prefer local tools for client material (browser PDF privacy).

Alternatives when PDF can't be fixed fast

• Publish same content as accessible web page
• Offer accessible DOCX alongside PDF
• Split: accessible summary PDF + appendix scans labeled "image-only appendix"

Troubleshooting

What makes a PDF accessible? Accessible PDFs have tagged structure (headings, paragraphs, lists), logical reading order, searchable text, and alt text on meaningful images — not just a visual layout that looks fine on screen.

Are scanned PDFs accessible? Not by default. Scans are images until OCR adds a text layer and tags define structure. Untagged scans fail screen readers.

Do I need special software to create accessible PDFs? Word and Adobe exports can produce tagged PDFs when settings enable tagging. Fixing bad PDFs later is harder than exporting correctly once.

Limitations

When not to use this approach

Related reading

• Word to PDF Conversion Tips
• How to Scan Documents Properly
• Combining Scanned and Digital PDFs
• PDF Metadata — What It Reveals

Conclusion

Accessible PDFs aren't a separate document species — they're tagged, ordered, searchable files that work when layout cues disappear. Export with structure from Word, OCR your scans, re-check after merge, and run a checklist before client-facing publish. You don't need perfection on day one — you need to stop shipping image-only PDFs and calling them done.