How to create accessible documents in Office 365
- Our soon to be awesome site is new and still under construction. Please open an issue on our Github project if you see anything that needs to be fixed or if you have any recommendations.
Accessible practices for digital document creation.
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!
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
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 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.
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.
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”.
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.
- 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.
- Google Docs – “Make your document or presentation accessible"
- Microsoft – "Make your Word documents accessible"
- Government of Canada “Canada.ca Content Style Guide”
- Flesch-Kincaid Reading-Ease Test for English and Scolarius for French
- Understanding non-text contrast
- Add alternative text – Microsoft Office Support
- Date modified: