Start with the source, not the export
Accessible documents start in the authoring tool, not after export. If your Word or InDesign source is structured well, your PDF will be dramatically easier to make accessible and much cheaper to maintain over time.
This guide walks through the core elements of document accessibility: the standards you need to meet, the practical techniques that make documents usable for people with disability, and the testing steps that prove it works. It applies to PDFs, Microsoft Word, PowerPoint, InDesign, Google Docs, and most long-form document formats. If you want a faster diagnostic path, jump into the Common Document Accessibility Issues tool alongside this guide.
1. Why document accessibility matters
Documents remain the backbone of government and enterprise communication: reports, policies, forms, guidelines, briefings, annual reports. When those documents are inaccessible, millions of people are shut out, and your organisation carries real legal, reputational, and operational risk.
Who is affected
- People who use screen readers need tagged structure, reading order, and alt text to understand a document.
- People with low vision rely on good contrast, resizable text, and clean layouts.
- People with cognitive or learning disability benefit from clear language, predictable structure, and consistent navigation.
- People who use keyboards or switch devices need forms and interactive elements that work without a mouse.
Tip: If you only remember one thing, remember this: an untagged PDF is a picture of a document. Screen readers can't read it, and nobody using assistive technology can navigate it.
2. Standards: WCAG 2.2 and PDF/UA
Two standards do most of the heavy lifting for document accessibility:
- WCAG 2.2 (Web Content Accessibility Guidelines) covers all digital content, including PDFs and Office documents. Most regulators reference Level AA.
- PDF/UA (ISO 14289) is PDF-specific. It sets out technical requirements for tagged PDFs, structure, metadata, and assistive technology support.
In practice, a well-made accessible PDF satisfies both. For Microsoft Office and Google Docs you apply the same principles (headings, alt text, reading order, language), and export to tagged PDF when you need a fixed-layout deliverable. You can also cross-check these concepts in the issues tool if you want examples of what goes wrong in practice.
3. Document structure and headings
Headings are the skeleton of your document. Screen reader users navigate by heading, jumping between sections much like a sighted reader scans a table of contents.
Get headings right
- Use real heading styles (Heading 1, Heading 2, etc.), not bold text that just looks like a heading.
- Start with one Heading 1 for the document title, then step down one level at a time.
- Don't skip levels (H2 straight to H4) because it breaks logical nesting.
- Use lists for list content, and quote styles for quotations, not manual indenting.
4. Reading order and tags
Assistive technology reads a document in its tag order, which may not match what the eye sees on the page. Pull-quotes, sidebars, multi-column layouts, and floating images are the usual culprits.
- Verify the reading order after export, particularly for designed layouts coming out of InDesign.
- Mark decorative elements as artifacts so screen readers skip them.
- Keep tag types meaningful: paragraphs, headings, lists, tables, figures, captions.
5. Images and alternative text
Every meaningful image needs alternative text that conveys the same information as the image. Decorative images should be marked as decorative so assistive technology ignores them.
Writing good alt text
- Describe the purpose of the image, not just what it looks like.
- Keep it concise: aim for one or two sentences.
- For charts and complex graphics, provide a short alt text and a longer text description nearby.
- Don't start with "Image of…" — screen readers already announce that it's an image.
6. Accessible tables
Tables are for tabular data, not layout. Use real table elements with proper header rows and columns so screen readers can announce the relationships between cells.
- Mark the first row (and first column, if relevant) as header cells.
- Avoid merged or split cells where possible; they confuse screen readers.
- Give every table a caption or summary that explains its purpose.
- Split very wide tables into smaller tables where practical.
7. Meaningful links and navigation
Link text should make sense out of context. Screen reader users often pull up a list of links to navigate the document, so "click here" and "read more" are unhelpful.
- Use descriptive link text: "Download the 2024 annual report (PDF, 3.2 MB)".
- Flag the file type and size when linking to downloads.
- For long documents, add bookmarks and a clickable table of contents.
Interactive PDFs and Word forms need labelled fields, a logical tab order, and clear instructions. If your form can't be completed with a keyboard alone, it isn't accessible.
- Give every field a visible label and a programmatic name.
- Group related fields (radio buttons, checkboxes) so screen readers announce them together.
- Provide instructions before the field, not after it.
- Write error messages that explain what went wrong and how to fix it.
9. Colour, contrast and typography
- Body text needs a contrast ratio of at least 4.5:1 against its background. Large text can go to 3:1.
- Don't rely on colour alone to convey meaning. Pair colour with text, icons, or patterns.
- Choose readable typefaces at a sensible size (11–12pt for body text, minimum).
- Left-align body copy — justified text creates uneven word spacing that's hard for many readers.
10. Language and metadata
Assistive technology uses the document's language setting to choose the right voice and pronunciation. A PDF in English that's tagged as German will be read aloud with a German accent.
- Set the document language (e.g. English (Australia)) in the source file.
- Tag passages in other languages so they're announced correctly.
- Fill in the document title, author, and subject in the file metadata. Many screen readers announce the title before anything else.
11. Testing your documents
Automated checkers are a useful starting point but catch only a fraction of issues. Combine them with manual and assistive technology testing. Once you have reviewed the principles here, the Common Document Accessibility Issues tool is a good companion for triaging recurring failures.
Suggested testing toolkit
- Built-in checkers: Microsoft Accessibility Checker, Acrobat Pro's Accessibility Check.
- Structure review: inspect the tag tree in Acrobat Pro to verify reading order and tag types.
- Screen reader testing: NVDA (free) or JAWS on Windows, VoiceOver on macOS/iOS.
- Keyboard testing: navigate the whole document with Tab, Shift+Tab, and arrow keys only.
- Specialist tools: PAC (PDF Accessibility Checker) for PDF/UA conformance.
12. Building an accessible document workflow
One-off remediation is expensive and fragile. The organisations that get document accessibility right bake it into how documents are produced, not bolted on at the end.
- Create accessible templates for Word, PowerPoint, and InDesign.
- Train authors in the basics: headings, alt text, tables, meaningful links.
- Put a quality check in the publishing sign-off for every document.
- Maintain a remediation queue for legacy documents and work through it by priority.
Once these pieces are in place, most new documents will be accessible on first export, and remediation is limited to complex legacy files.
This guide explains the principles and workflow. If you want a quicker, issue-led way to review frequent accessibility problems in PDFs and other document formats, use our interactive issues page.