Document accessibility guide

A practical, plain-English guide to creating accessible PDFs, Word documents, and PowerPoint presentations. Learn what makes a document accessible, why it matters, and how to get it right, whether you author one document a year or publish thousands.

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.

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 cannot read it, and people using assistive technology cannot navigate it properly.

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, such as headings, alt text, reading order, and language, then export to tagged PDF when you need a fixed-layout deliverable.

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 such as Heading 1 and Heading 2, not bold text that merely looks like a heading.
  • Start with one Heading 1 for the document title, then step down one level at a time.
  • Do not skip levels 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 common culprits.

  • Verify the reading order after export, particularly for designed layouts coming out of InDesign.
  • Mark decorative elements as artefacts so screen readers skip them.
  • Keep tag types meaningful: paragraphs, headings, lists, tables, figures, and 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 and aim for one or two sentences.
  • For charts and complex graphics, provide a short alt text and a longer text description nearby.
  • Do not start with “Image of” because screen readers already announce that it is 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 the first column if relevant, as header cells.
  • Avoid merged or split cells where possible because they confuse screen readers.
  • Give every table a caption or summary that explains its purpose.
  • Split very wide tables into smaller tables where practical.

8. Forms and interactive fields

Interactive PDFs and Word forms need labelled fields, a logical tab order, and clear instructions. If your form cannot be completed with a keyboard alone, it is not accessible.

  • Give every field a visible label and a programmatic name.
  • Group related fields such as radio buttons and 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.
  • Do not rely on colour alone to convey meaning. Pair colour with text, icons, or patterns.
  • Choose readable typefaces at a sensible size.
  • Left-align body copy because justified text creates uneven word spacing that is harder for many readers.

10. Language and metadata

Assistive technology uses the document language setting to choose the right voice and pronunciation.

  • Set the document language, for example English (Australia), in the source file.
  • Tag passages in other languages so they are announced correctly.
  • Fill in the document title, author, and subject in the file metadata.

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.

Suggested testing toolkit

  • Built-in checkers: Microsoft Accessibility Checker and 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 or JAWS on Windows, and VoiceOver on macOS and iOS.
  • Keyboard testing: navigate the whole document with Tab, Shift+Tab, and arrow keys only.
  • Specialist tools: PAC for PDF/UA conformance.

12. Building an accessible document workflow

One-off remediation is expensive and fragile. The organisations that get document accessibility right build it into document production instead of bolting it on at the end.

  • Create accessible templates for Word, PowerPoint, and InDesign.
  • Train authors in the basics: headings, alt text, tables, and 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.

Common document accessibility issues

Use this interactive triage tool to review the most common document accessibility problems, focus on a category, search for a specific issue, and track what you have already reviewed.

Interactive review tool

This section keeps the practical filterable workflow from the earlier standalone tool, but is now presented inside the ExceedAbility guide layout so it feels like part of the same page rather than a separate application.

Best used for: PDF triage, internal QA, author training, and quick remediation planning before a deeper accessibility review.

0 of 12 issues reviewed

Beyond the common mistakes

These 12 issues cover frequent document accessibility failures, but they are not exhaustive. Other important areas include lists, focus order, complex layouts, multimedia alternatives, and compatibility with assistive technology. For broader guidance, refer to the WCAG 2.2 understanding resources or move from triage into full remediation planning.

Where to next?

Three ways forward, depending on where you are starting from.

Need a hand with document accessibility?

If you have documents to fix, templates to build, or a production pipeline to make accessible, we can help. We remediate one-off files and set up scalable workflows for ongoing output.

Talk to us about remediation

New to this area?

If this is all new, start with the basics. Explore our training service offerings to get an entry-level understanding of accessibility before diving deeper.

Explore training services

Ready for the standards detail?

If you already know the fundamentals and want to understand how specific WCAG criteria affect different users, explore our criteria search tool.

Open WCAG criteria search