The short answer: an accessible document is one that a screen reader, a keyboard user or someone with low vision can read from start to finish without help. In practice that comes down to seven habits: real headings, plain language, alt text for images, readable fonts and contrast, simple tables, built-in lists, and descriptive links. Then you run the built-in checker before you share the file.
Clients and colleagues ask me the same question every few weeks: “How do I actually make a document accessible?” This guide is my answer. It is the checklist our team has refined over 9+ years of accessibility work, written for content teams, marketers, website managers and anyone who publishes files online.
A bonus most people miss: accessible documents are also clearer documents. They are easier to scan, easier to search and easier to reuse.
Screen reader users jump between headings the way sighted readers skim. That only works when headings are built with styles, not just bold text.
In Word: select the text, then choose a heading in Home > Styles. Open View > Navigation Pane to see your outline the way a screen reader will.
Plain language helps everyone, including people with cognitive disabilities, readers in their second language and busy managers.
A good diagram can make a complex idea easier to follow. Two rules make it accessible:
An image supports the content. It never replaces it. Anything important in a chart should also appear in the text.
There is no single “accessible font”, but clear sans-serif fonts such as Arial, Calibri or Verdana work well. Avoid thin, light or condensed fonts that blur for readers with low vision.
Use a table when you are really comparing data, such as a schedule or a price list, not to lay out the page.
When a list is created with the Bullets or Numbering buttons, the screen reader announces “list, 5 items” and tells the reader where they are. Typed dashes or numbers do not do this.
“Click here” tells a screen reader user nothing when links are read out of context. Make the link text describe the destination, for example “WEB-A document accessibility services”. In Word, select the text, press Ctrl+K and add a ScreenTip if more context helps.
In Word: Review > Check Accessibility. The checker lists errors and warnings, explains why each one matters and shows how to fix it. Keep it open while you work. Microsoft’s guide, Make your Word documents accessible to people with disabilities, walks through the same checks.
Exporting to PDF: File > Save As > PDF > Options, and make sure “Document structure tags for accessibility” is checked. Then check the PDF itself in Adobe Acrobat (Accessibility Check). A tagged PDF built from an accessible Word file needs far less fixing. For the PDF-side checklist, see our PDF accessibility rules.
Automated checkers catch only part of the issues. For important documents, our experts also test with a real screen reader.
For 9+ years our experts have made websites, apps and documents accessible by hand, tested with real assistive technology. If you have a backlog of Word files or PDFs, or want your team trained to create them right the first time, talk to our document accessibility team.
A logical heading structure, alt text for images, readable text and contrast, simple tables, real lists, descriptive links and a set document language, so assistive technology can read it in the right order.
Start with the Word file. A well-structured Word document exports to a tagged PDF that needs only light checks, while fixing an untagged PDF is slow work.
No. It catches structural issues such as missing alt text or headings, but not unclear language, poor alt text quality or a confusing reading order. A manual review is still needed.
WCAG 2.1/2.2 at level AA is the common reference, and PDF/UA for PDFs. In Israel, IS 5568 is based on WCAG.
This website uses essential cookies to operate and, with your consent, statistics cookies (Google Analytics). For more details, see our Privacy Policy.