Accessible writing is good writing. It makes your content easier for everyone to consume. Here are some tips on how to write with accessibility in mind.
- Print Ally's .
Write plainly
Documentation is only as good as what people can get out of it. If the writing is too complicated, they won't be able to use it. Plain language improves accessibility.
Keep your writing simple and concise with these tips:
- Keep sentences short. They should be around 20-25 words at most.
- Use simple words. Use sites like these to find simple words to use:
- Use tools like Hemmingway Editor to measure the readability of your text. To meet WCAG standards, aim for a readability level of grade 8 and lower.
Heading structure
Headings are critical when creating accessible content. They provide screen reader users with the ability to jump directly to specific content, which can save them time.
Work with the system you are writing in. All popular tools, like Microsoft Word, PowerPoint, and Open Office provide style and formatting options to help you build the proper structure into your documents. Use the styles and formatting options provided in your chosen content editor tool.
Example: Heading 1 (<h1>)
The numbers in the heading style create structural context for the screen reader and help non-visual users understand the content even when they cannot see the visual breaks in the document.
Example:
<h1>Accessibility in Education</h1>
<h2>Accessibility at Blackboard</h2>
More on designing accessible content
Emphasizing content
Screen readers do not identify font styles including the following:
- Color
- Bold
- Italics
- Underline
- Strikethrough
Use these styles to provide visual breaks. Do not use them as the only way to indicate importance or convey information.
Example: Red text looks like an alert. Users of screen readers will not know the text is red. They miss the cue and don't know it's an alert.
When you need to give a strong visual cue, make sure that you use an accessible alternative. Use an exclamation mark at the end of your sentence if it is important. Screen readers intonate exclamation and question marks. This means the tool will not read "question mark"—instead, it will lend a questioning tone as it reads a question aloud.
Example: Again, don't use font styles alone to indicate importance!
Images
Ask yourself what the purpose of an image is. Is it to give a page visual appeal? Or to give a sighted user a visual reference of what to expect? Is the image something all users need to consume to understand your content?
If you don't know the meaning or purpose of the image, don't use it! It is clutter and will be overwhelming to those with learning disabilities.
Alt Text
If you are using an LMS or website to convey information, you will come across a field for alternative text, or alt text, when uploading an image. For decorative images, leave the alt text field blank. The screen reader will ignore the image in this case. An image is decorative when it doesn't add to the information on the page.
More on decorative images on the web accessibility initiative website
Example: If you have an image showing the tools in a User Interface (UI), describe how to get there and what it is on the page. See an example of describing an image on the page.
If you don't want the screen reader to skip the image, include alt text in your images. You don't need to say "Image of" as the assistive tools already know it is an image. Be concise, clear, and descriptive.
Do not use the same alt text for every image, such as "Image illustrating associated text." It is meaningless and adds clutter.
For complex images, keep the alt text short-6 or 7 characters-and include a caption under the image that is visible to everyone and provides a clear description.
Infographics
Infographics require a text alternative. This is a narrative telling the same story users get from the visual. The text alternative should be on the page immediately following the infographic. Include an anchor link at the top of the page to view the text alternative.
See an example of an infographic with a text alternative.
Text in images
As per the WCAG guidelines, text should not be included as part of an image. Explain the image in text on the page instead.
Links
It is critical to make your links descriptive. Every link should describe what the user can expect to find when they click it. This is key for the Links List tool that screen readers provide. This tool only list the links on a page, nothing else. There is no additional context for the link.
Example: On this page the Links List tool would read the following: "See an example of describing an image on the page," "example of an infographic with a text alternative," and so on. Each describe what you can expect to find when you select them.
- Avoid using generic phrases such as "click here" or "see more." The Links List tools will read the text of the link exactly as entered. When the same link is repeated (imagine hearing "click here, click here, click here" repeated multiple times) it creates chaos and confusion for users. They need to understand where the link goes and why they should click here? Descriptive links provide this context.
- Web addresses or URLs are not considered informative and should not be used. The screen reader reads each letter individually. Instead make the text descriptive.
- Opening links in a new window can be disorienting. Keep them to a minimum. Tell your users when you are using a new window.
List and tables
Let the tools you are creating content in do the work. Use the bullet, numbered list, and table tools in the content editor. Or view the source and use the correct HTML tags.
Lists
Properly created bulleted lists (<ul>) inform screen reader users how many items are in the bulleted list.
Properly created numbered lists (<ol>) inform the screen reader user how many items are in the numbered list and read the number for each item.
Tables
Use lists over tables when you can! Tables can be made accessible, but screen reader users need to know advanced keystroke commands to navigate and understand them.
Use column headers (<th>). This causes the screen reader to re-announce the column heading for each cell as the user navigates through. This gives the user context for each cell content. Consider how each cell will read when naming the columns and adding information to the cell.
Never use tables to create visual layout of content.
An example of an accessible table
Keystroke commands
There are global standards for keystroke commands in web content. For example, you can press Tab to put your computer's focus on the next button. You don't need to describe those. For a list of global commands, see this JAWS Keyboard Commands Quick Reference Guide.
At times, developers need to create original keystroke commands for their product. For example, Blackboard Collaborate created original keystroke commands to turn the microphone on and off. Document those original keystroke commands in your topics.
Click and keystroke command instructions are two separate thoughts and should not be in the same paragraph. If Mac commands are different than PC commands, use two sentences in the keystroke topic paragraph.
Example 1
By default, you are hidden and muted after you complete the setup. Click the microphone and camera icons to begin full meeting participation.
With your keyboard, press Alt + M to turn your microphone on and off. Press Alt + C to turn your camera on and off.
Example 2
Browse buttons appear when you share a presentation so you can navigate from slide to slide.
With your keyboard, press Alt + Page Up to move to the next slide. Press Alt + Page Down to move back. On a Mac, press Alt + Fn + Up Arrow and Alt + Fn + Down Arrow.
Video
Videos should be captioned. To learn more, see about captioning videos.
