How to create accessible documents in Office 2016

Accessible practices for digital document creation in Office 2016.

Looking for the Microsoft 365 version? Try How to create accessible documents in Microsoft 365

What is an accessible document?

An accessible document is fully usable by persons with and without disabilities. Making your documents accessible allows users to navigate them in different ways.

For example, a blind user may use a screen reader or a braille display. A person with a motor impairment may use a keyboard rather than a mouse. Other users may need to adjust the font size or spacing to compensate for vision loss or cognitive disabilities.

Meeting accessibility standards

Accessibility of digital content (including web pages and documents) is evaluated according to the Web Content Accessibility Guidelines (WCAG). Following this guide does not ensure full compliance with these guidelines, but it is a good start!

Writing content

Using plain language ensures that everyone, including persons with cognitive disabilities, can understand the content of documents and use the information effectively. Documents should be clear, concise, and well organized.

Use short sentences and plain language
Measure to a Grade 8 reading level
Avoid jargon and unusual words
Define acronyms when first used
Follow best practices for the subject matter and intended audience

Document structure

Headings

A good heading structure makes it easier to navigate and locate content, especially for users of screen readers. It is crucial to use built-in heading styles for all headings.

Apply a consecutive, logical heading order where higher level headings provide context to lower level headings. Do not skip heading levels. For example:

Subsections of a level 1 heading should be heading level 2, not 3 or 4
Subsections of a level 2 heading should be heading level 3, etc.

Avoid these common heading errors:

Formatting the text (bold, larger size) instead of using heading styles
Using heading styles to format text (bold, larger size) when the text isn’t a heading
Using different colours, sizes, or fonts for headings of the same level

Tables

Tables may be difficult to navigate or edit for users of screen readers. Design tables to be as simple as possible.

Do not use tables for layout / styling
Use built-in software features to create tables
Define column headings and row headings
Add alt-text to tables with a short summary of the content
Avoid nested tables, merged cells, split cells, or blank rows / columns

Links to websites

Link text should make sense even when read out of context, for example in a list of links.

Use the name of the website or organization as link text
Don’t use the URL as the link text, unless the full URL needs to appear in print
Avoid generic wording like “Click here” or “Read more”
Make link text as short as possible while still making it clear where the link goes

Other special elements

Use the software’s built-in functions to create elements which should be treated differently from normal body text. These include:

Bulleted and numbered lists
Table of contents
Headers, footers, and page numbers

Avoid using text boxes. These are typically ignored by screen readers and are inaccessible to keyboard users.

Formatting

Colours

Text must have a contrast ratio of at least 4.5:1 against the background. Black text on a white background is always a safe choice.

Check contrast with the Colour Contrast Analyser or WebAIM Contrast Checker
Avoid complex background images. If you must use a background image, use the Text on Background image a11y check
Include a contrasting outline/stroke around the text when the background cannot be changed to meet contrast requirements

The same principles apply to meaningful non-text elements such as icons and charts, but the requirement is relaxed to 3:1. For example, adjacent slices in a pie chart should be easy to distinguish from each other.

Fonts

Choose fonts and styles that are easy to read rather than decorative.

Use sans-serif fonts with sufficient spacing between letters and lines
- Arial, Verdana, and Calibri are all sans-serif fonts
Body text size should be 11 to 14 points for a print-style document like this one
- Some fonts appear larger than others. Compare with 12 point Arial.
Larger fonts should be used for presentations (18 point minimum)
Avoid using italics for more than a few words

Do not rely solely on visual formatting to convey information. For example, avoid phrases like “priority tasks in bold”, “changes highlighted in yellow”, or “see the left sidebar for details”.

Non-text elements

Visual elements such as photos, icons, diagrams, and tables should include alternative text (“alt text”) that briefly answers the question “What information is the image conveying?”.

A good starting point for writing alt text is to imagine that you are describing the image to a person over the phone.

Short alternative text

Keep your descriptions as brief as possible (at most 65 characters). Ignore details that don’t relate to the document. For example, a picture of a group of students appears in a document about hiring summer students.

Good: “Students being trained in a boardroom”
Too long: “Five students in business attire sit in a boardroom looking at a projector screen while the presenter gestures towards the leftmost student”

Avoid these common alt text errors:

Putting text inside an image
- If images of text can’t be avoided, include all visible text in the alt text
Starting each description with “Image of…”
- Do begin with “Screenshot of…” if the image is a screenshot
Repeating the text of an adjacent caption
Describing decorative images (which don’t convey any meaningful information)
- Instead, set alt="" for the web, or set description as “decorative” in Word

Long text description

Sometimes the short alt-text isn’t enough to describe the visual element. In these cases, you should also provide a long description. Include this in the visible text if possible.

Examples:

Road map with directions: Describe each step needed to follow the directions
Flow chart: Use numbered components to fully describe the process
Line graph: Describe trends, then include the data points in a table

For more examples, see the W3C’s tutorial on Complex Images.

Video, audio, and multimedia

Embedded audio or video requires a transcript. Videos should be captioned and audio-described. The player controls — start, pause and stop — must be accessible.

Additional resources