How to check a Word, Excel or PowerPoint file for accessibility

What “accessible” means for a document

A person using a screen reader hears your document rather than sees it. The reader announces a picture by its description, jumps between headings to find its way, reads a table cell by cell with the header of its column, and says a link by its words. When those things are missing — a picture with no description, a heading that is only big bold text, a table with no header row, a link that says “click here” — the document is still there, but the person cannot use it.

Low vision is the other half: text too pale for its background, meaning carried only by colour, and slides whose words are pictures of words.

In Microsoft 365

Word, Excel, PowerPoint and Outlook share one checker: Review → Check Accessibility. It opens a pane that sorts what it finds into Errors (content that is very hard or impossible to use), Warnings (content that is hard to use) and Tips (content that could be better organised). Each finding names the object, and a click selects it with a recommended fix beside it.

Tick Keep accessibility checker running while I work and the status bar reads “Accessibility: Good to go” or “Investigate” as you type, which is the most useful setting in the pane — a problem is cheapest to fix at the moment you make it.

In other suites, and for PDFs

• LibreOffice Writer has Tools → Accessibility Check, which lists missing alternative text, low contrast, headings out of order and similar problems, with a fix for many of them.
• Google Docs has no built-in checker. Third-party add-ons exist; failing that, the manual checks below are the whole job.
• PDF is its own world, because what a screen reader gets from a PDF depends on its tags. If the document started in Word, fix it there and export a tagged PDF rather than repairing the PDF. For a finished PDF, Adobe Acrobat Pro has an accessibility checker, and the free PAC tool checks against the PDF/UA standard.

What every checker looks for, and how to fix it

• Alternative text. Every picture, chart and shape that carries meaning needs a sentence or two saying what it shows — the point of a chart, not “chart”. A file name such as IMG_2041.jpg is not a description, and good checkers treat it as missing. A picture that is only decoration should be marked as decorative, so a screen reader skips it rather than announcing an unnamed image.
• Headings. Use the Heading 1 and Heading 2 styles rather than bold, larger text, and do not skip levels. A reader navigates by them, and a table of contents is built from them.
• Tables. Give every data table a header row, marked as one, and avoid merged and split cells, which make a table very hard to read cell by cell.
• Contrast. The WCAG guideline asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (about 18 point, or 14 point bold). Light grey on white is the usual failure.
• Link text. “Read the annual report” rather than “click here” or a bare address; a screen reader often lists a page’s links on their own.
• Slides. Every slide needs a title of its own, and the reading order of the shapes should match the order a sighted reader would take them in.
• Spacing. Use paragraph spacing rather than empty paragraphs, which a screen reader announces as “blank” again and again.
• Document title. Set it in the file’s properties; it is what a reader announces when the file opens.

What a checker cannot tell you

A checker finds what is missing, not what is wrong. It knows a picture has a description; it cannot know the description is accurate. It knows the headings are in order; it cannot know they describe the sections under them. And it does not judge the words: plain language, short sentences and a clear structure matter more to many readers than anything on the checklist.

The only complete test is to listen: turn on the screen reader your operating system ships with — Narrator on Windows, VoiceOver on a Mac — and go through the document without looking at it.