Why is a 'text-based' PDF still not accessible?

Because accessibility depends on structure (read order, headings), language, links, and tables. A PDF can contain real text but still be hard to navigate or understand.

What’s usually the best starting point: Word or PDF?

Build in Word with proper styles, then export while preserving structure. This typically produces a more reliable PDF for accessibility.

How should we validate documents before publishing?

Use a PDF accessibility validator and verify with at least one real screen reader + keyboard navigation on a representative file.

Accessible PDF & Word documents (RGAA)

Websites aren’t the only surface. PDF and Word documents can block users if they lose structure during export. Here’s a practical, RGAA-style workflow for keeping documents readable, navigable, and reliable.

1) Think “structure”, not “content presence”

Accessibility relies on headings, reading order, language, and meaningful link text.
Don’t assume “text is there” means “users can navigate”.
Images also need alternatives when they convey information.

2) Word: build with styles (the reliable baseline)

Use real heading styles (H1/H2…) instead of visual formatting.
Create lists as lists and tables as tables (not as spacing tricks).
Add a caption/title for data tables when appropriate.
Use descriptive link text and include accessibility-friendly image alternatives.

3) Export to PDF without breaking navigation

Goal: preserve reading order, heading structure, and link semantics.
Avoid “scanned” or image-only PDFs whenever possible.
Validate that what you see matches what assistive technologies can interpret.

4) Common PDF issues to check

Reading order is correct (no missing blocks).
Language is set properly.
Links are understandable without context (no “click here”).
Tables expose headers/structure appropriately.
Forms (if present) have labeled fields and clear errors.

5) Validate with real tools + real users (minimum)

Use a PDF accessibility checker (validator).
Verify with a screen reader and keyboard navigation on a representative document.
After corrections, revalidate before publishing.

Quick checklist

The document is not an image scan: text is selectable and structured.
Heading hierarchy is consistent.
Reading order matches the intended flow.
Links have meaningful labels.
Images have appropriate alternatives.
Tables and (if applicable) forms are accessible.
A validation step is performed on a representative file.

If you’re building a full compliance workflow, connect document checks to your statement process and keep everything consistent with your DINUM accessibility statement checklist.