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, or open the full WCAG 2.2 Quick Reference when you need to look up a specific criterion in plain English.
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. See accessibility statistics and research and the cost of inaccessible digital experiences for the Australian numbers.
Who is affected
- People who use screen readers need tagged structure, reading order, and alt text to understand a document. See JAWS vs NVDA vs VoiceOver vs TalkBack for the assistive-technology context.
- 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.
This is a quality-assurance issue, not an add-on. We explore the principle in the companion blog post Accessibility isn't a button or an add-on.
Tip: If you only remember one thing, remember this: an untagged PDF is a picture of a document. Screen readers cannot 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. See WCAG Level A vs AA vs AAA for what each level covers and which to target.
- 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. If your audience needs more than a tagged PDF (Easy Read, large print, audio, captioned video, Braille), see alternative formats.
To look up the exact WCAG success criterion behind any technique in this guide, use the WCAG 2.2 Criteria Search (filter by disability impact, level, principle and primary focus), or the plain-English WCAG 2.2 Quick Reference with failure examples.
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. The underlying WCAG criterion is 1.3.1 Info and Relationships.
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.
- Do not skip levels (H2 straight to H4); it breaks logical nesting.
- Use lists for list content, and quote styles for quotations, not manual indenting.
Designers and content authors: the accessibility for designers and accessibility for developers guides cover the structure traps that recur in document and web work.
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. The relevant WCAG criteria are 1.3.2 Meaningful Sequence and 2.4.3 Focus Order.
- 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.
For worked examples of reading-order failures and the fixes, see the common document issues tool.
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. The governing criterion is 1.1.1 Non-text Content.
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 (or link to an HTML data table).
- Do not start with "Image of..."; screen readers already announce that it is an image.
- For information presented only as an image (an infographic, a scanned form), provide a text equivalent or, where appropriate, an alternative format.
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. The structural criterion is again 1.3.1 Info and Relationships.
- 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. See WCAG 2.4.4 Link Purpose (In Context).
- 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 cannot be completed with a keyboard alone, it is not accessible. Relevant criteria include 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value.
- 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
The contrast criterion is 1.4.3 Contrast (Minimum). The wider non-reliance on colour rule is 1.4.1 Use of Color.
- 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 (11-12pt for body text, minimum).
- Left-align body copy; justified text creates uneven word spacing that is 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 is tagged as German will be read aloud with a German accent. See 3.1.1 Language of Page and 3.1.2 Language of Parts.
- Set the document language (e.g. 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. 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. We cover the trade-off in detail in manual vs automated accessibility testing.
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 or 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.
For a fully independent audit, fix-priority report and re-test, see our audit and compliance service, or assistive-technology user testing when you need real users in the loop. Procurement audiences may also need a formal VPAT or Accessibility Conformance Report.
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 bolt it on at the end. This is the maturity story we cover in from reactive to resilient: building accessibility maturity.
- Create accessible templates for Word, PowerPoint, and InDesign.
- Train authors in the basics: headings, alt text, tables, meaningful links. See our training options.
- 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.
- Embed accessibility into procurement, design and governance through an organisational uplift programme or targeted consulting and strategy work.
Once these pieces are in place, most new documents will be accessible on first export, and remediation is limited to complex legacy files. For end-to-end remediation of an existing document estate, see document remediation.
The principles above apply across formats. Here is what to actually do in each tool, with the gotchas that we see most often during remediation engagements.
14. Australian context: DDA, Digital Service Standard, NSW
If you publish documents to the Australian public, several obligations apply:
- Disability Discrimination Act 1992 (DDA): the DDA applies to digital content, including documents published online. Inaccessible documents are a frequent source of public complaints to the Australian Human Rights Commission.
- Australian Government Digital Service Standard: expects WCAG 2.2 Level AA for new and existing digital services. See government accessibility consulting for how this lands in practice for federal, state and territory agencies.
- State and territory frameworks: NSW, Victoria, Queensland and others publish their own accessibility expectations on top of the federal baseline. Our NSW Accessibility Intelligence and Australian Government Accessibility Index datasets track agency performance.
A note on accessibility overlays
Overlay widgets (UserWay, accessiBe, AudioEye and similar) appear on many Australian websites that also host inaccessible PDFs. An overlay does not tag a PDF, fix reading order or supply alt text. In 2025 the US FTC fined accessiBe one million dollars for marketing claims that an overlay could deliver WCAG compliance.
Read: why accessibility overlays will not make your website compliant.
15. Common questions about document accessibility
What makes a PDF accessible?
An accessible PDF is a tagged PDF whose tag tree matches the visual content: real headings, lists, tables, figures with meaningful alternative text, reading order verified, language set, document title in metadata, and any form fields labelled. The technical standard is PDF/UA (ISO 14289), and the content standard is WCAG 2.2 Level AA. An untagged PDF is, in effect, a picture of a document and cannot be read reliably with a screen reader.
Does Microsoft Word produce accessible PDFs?
Yes, when the Word source is authored correctly (real heading styles, alt text on images, table headers set, language set, descriptive link text). Export using File then Save As PDF with the Document structure tags for accessibility option enabled. PowerPoint and Google Docs follow the same principle. Documents exported from design tools such as InDesign usually need extra reading-order and tag work in Adobe Acrobat Pro.
Is the Microsoft Accessibility Checker enough?
No. Built-in checkers catch only a fraction of accessibility issues (broadly around a third of WCAG criteria). They miss meaningful alt-text quality, reading-order correctness, link-text clarity and other judgement-led criteria. Combine automated checks with manual structure review and screen reader testing before publishing anything important. See manual vs automated accessibility testing.
Are Australian Government documents required to be accessible?
Yes. The Disability Discrimination Act 1992 applies to digital content including documents, and the Australian Government Digital Service Standard expects WCAG 2.2 Level AA. Many agencies also publish to PDF/UA. Inaccessible documents are a frequent source of public complaints and Australian Human Rights Commission inquiries. See government accessibility consulting.
Can I make a scanned PDF accessible?
Not without significant work. A scanned PDF is an image. It must be put through OCR to produce real text, then properly tagged, with reading order verified and figures given alt text. For large or complex scans, regenerating the document from the original source is almost always cheaper and more reliable than remediating the scan.
How long does it take to remediate a PDF?
A simple, well-structured PDF can be tagged and corrected in under an hour. A complex annual report, designed brochure or scientific paper with tables, charts and figures can take 4 to 12 hours per document. Most savings come from fixing the source file and the publishing template once, rather than remediating every export. See document remediation.
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.