Structure is invisible until it is missing
A Word document can look perfect on screen and still be unreadable to someone using a screen reader. The difference is structure: the headings, lists, tables and labels that sit underneath the visual layout and tell assistive technology what each thing actually is.
This guide is part of our wider document accessibility guide. It focuses on Microsoft Word specifically, the tool that produces more inaccessible documents than any other simply because it is the most used. If you would rather work issue by issue, the Common Document Accessibility Issues tool is a good companion.
1. Why a print mindset breaks online
For decades, a Word document had one destination: a printer. When the only output is paper, all that matters is how the page looks. You can fake a heading by making text big and bold, create space with empty paragraphs, line things up with tabs, and use a table to position two columns side by side. The printed result looks fine, so the habits stick.
Online, those same habits fail. A screen reader does not see your page, it reads the underlying structure. Bold text is just bold text, an empty paragraph is announced as "blank", a layout table forces the reader through cells in a confusing order, and a tab-spaced list is read as one long run-on line. The document that printed beautifully is now a barrier.
The shift: stop formatting how things look and start declaring what things are. A heading is a heading because you applied the Heading style, not because you made it bold. That single change is the heart of accessible authoring.
This is the same principle we cover in the blog post accessibility isn't a button or an add-on: accessibility is a property of how the document is built, not a finish you apply at the end.
2. Common Word pitfalls to look for
These are the issues we find most often when remediating Word documents. Most come straight from the print mindset above.
- Bold text used as a heading. Looks like a heading, carries none of the structure. Use Heading 1, 2 and 3 styles.
- Manual lists. Typing "1." or a hyphen at the start of a line does not create a real list. Use the bullet and numbering buttons.
- Spacing with empty paragraphs or tabs. Screen readers announce blank paragraphs and run tab-spaced content together. Use paragraph spacing and proper styles instead.
- Text boxes and floating shapes. Content in text boxes is often skipped or read out of order. Keep body content in the main text flow.
- Tables used for layout. Tables are for data. A layout table sends a screen reader through cells in a way that makes no sense when read aloud.
- Merged and split cells. They break the row and column relationships that screen readers rely on.
- Images with no alt text, or charts and infographics whose information exists only in the picture.
- Colour as the only signal. "Items in red are overdue" fails for anyone who cannot see the colour.
- Non-descriptive links such as "click here" that make no sense out of context.
- No document title or language set, so a screen reader announces the file name and may read English text with the wrong pronunciation.
3. Headings and structure
Headings are how screen reader users navigate. They pull up a list of headings and jump between sections, exactly as a sighted reader scans a contents page. The governing criterion is 1.3.1 Info and Relationships.
- Apply heading styles from the Home ribbon (Heading 1, Heading 2, and so on), not manual bold and size changes.
- Use one Heading 1 for the document title, then step down a level at a time. Do not jump from Heading 2 to Heading 4.
- If you do not like how a built-in heading style looks, modify the style rather than abandoning it. You keep the structure and get the look you want.
- Use the Navigation Pane (View > Navigation Pane) to see your heading structure at a glance and catch gaps.
4. Lists and accessible tables
Real lists and real tables carry relationships that assistive technology announces. Faked versions do not.
Lists
- Use the bullet or numbered list buttons so the list is announced as a list with a known number of items.
- Do not mix manual numbering with real lists in the same document.
Tables
- Use tables only for tabular data, never for page layout.
- Mark the header row: select it, then Table Design > Header Row, and tick "Repeat Header Rows" under Layout for tables that span pages.
- Avoid merged or split cells in data tables.
- Keep one idea per cell and avoid leaving cells blank where a screen reader user would expect a value.
5. Images and alt text
Every meaningful image needs alternative text that conveys the same information the image does. Decorative images should be marked decorative so they are skipped. The criterion is 1.1.1 Non-text Content.
- Right-click an image and choose View Alt Text (or Picture Format > Alt Text).
- Describe the purpose of the image in context, not just what it looks like. Keep it to a sentence or two.
- Tick Mark as decorative for images that add no information.
- For charts and infographics, give a short alt text and put the underlying numbers in nearby text or a real table.
- Do not begin with "Image of"; the screen reader already says it is an image.
6. Links, language and metadata
Three quick settings that are easy to miss and make a real difference.
- Descriptive links: edit the link text so it makes sense alone, for example "Download the 2026 annual report (PDF)". See 2.4.4 Link Purpose.
- Document language: set it under Review > Language > Set Proofing Language (English (Australia)). Tag passages in other languages too. See 3.1.1 Language of Page.
- Document title: set a real title under File > Info > Properties. Many screen readers announce the title first, and it carries into the PDF metadata.
7. Using the Accessibility Checker
Word has a built-in checker at Review > Check Accessibility. It is a useful first pass, but it is not a pass or fail certificate.
- Run it early and often, and keep "Keep accessibility checker running while I work" turned on.
- Fix every error and warning it reports, working from the Inspection Results panel.
- Remember its limits: it cannot tell whether your alt text is meaningful, whether the reading order is logical, or whether your links are clear. Those need human judgement.
For why automated checks only get you part of the way, see manual vs automated accessibility testing.
8. Exporting a tagged PDF
All the structure you added is only useful in the PDF if you export correctly.
- Use File > Save As (or Export) and choose PDF. Do not use Print to PDF, which throws away the tags and gives you a picture of a document.
- In the Save dialog, open Options and enable Document structure tags for accessibility and Create bookmarks using Headings.
- Open the result in Adobe Acrobat Pro and confirm it is tagged, the reading order is correct, and the title shows in the title bar. See our Acrobat accessibility guide for that final check.
Tip: a well-authored Word file usually needs little or no work in Acrobat. A poorly authored one can take hours to remediate after export. The cheapest place to fix accessibility is always the Word source.
9. Common questions about Word accessibility
Why is bold text not the same as a heading?
Bold only changes appearance. It adds no structure, so a screen reader cannot announce it as a heading or let users jump to it. A real heading style adds the structure assistive technology needs, and it is what carries through into a tagged PDF.
Is the Word Accessibility Checker enough on its own?
No. It catches roughly a third of WCAG issues and cannot judge alt-text quality, reading order or link clarity. Combine it with a manual review and a screen reader pass. See manual vs automated testing.
How do I export an accessible PDF from Word?
Author the file correctly, then File > Save As > PDF, open Options, and enable Document structure tags for accessibility and Create bookmarks using Headings. Avoid Print to PDF, which produces an untagged file.
Do I need Acrobat Pro to make accessible Word PDFs?
Not always. A clean, well-structured Word file can export to an accessible PDF on its own. You will want Acrobat Pro to verify the result and to fix anything complex, such as table headers or reading order on designed layouts.