The content we create must be accessible and usable for the widest possible audience. This includes users of all mental and physical capabilities. We must always consider standards for accessibility and inclusion when editing and creating content, from the words we choose to the way our content is organized.
I've written an accessibility style guide which outlines some best practcies. Feel free to copy this document in whole and add it to your company style guide.
I've also included accessibility in my speaking policy.
Read the best practices or skip ahead to resources.
When considering how to write and speak with inclusive language, there are words we should use and language to avoid. Language to avoid may sound awkward at best or at worst, be offensive.
Writing inclusive language in our docs starts with realizing the ways in which we've internalized ableism in our everyday lives.
- Read guidelines for writing about people with disabilities
- Avoid euphamisms
- Use precise language. Read a DEI glossary
Clear instructions are the most critical element of a technical writer's job. We recommend you write short, complete sentences; use precise language; use exact measurements; and use nouns instead of pronouns. Additionally, we recommend that you break up longer tasks into smaller chunks and share examples.
For UI copy, clear instructions mean that the user can always answer 3 questions: where am I? What can I do here? How do I move forward?
Don't rely exclusively on the visual elements to convey information. This includes colors, patterns, images, font styles, and directional language. Always use text or alt text along with visual elements.
From W3C:
- Avoid sensory characteristics
- Use color as one of many elements to communicate
Heading language should be scannable and understood without context. Additionally, it's important to use semantic HTML, which means the HTML tags you choose correctly align with the value of the content between the tags.
- Read the W3C's semantic HTML guide
- Take the Learn Accessibility content structure module
Provide unique, consistent, and relevant labels for link text to allow people who use screen readers (and those who don't) to take action.
Alt text ensures all users, regardless of visual ability, can appreciate the image content on your site. Alt text should be contextual, concise, and spared from too many keywords. If the image is purely decorative, consider including no alt text to keep from distracting a user with a screen reader.
Want to know how folks experience your content? Test it! Review W3C's recommended accessbiliity tools.
Clear, simple text lets your audience focus on learning, rather than deciphering what you're trying to say.
Here are a list of resources on the topic of accessibility. Some are directly related to writing and communication, others more loosely connected about web development and design.
- MailChimp's guide on writing for accessibility
- A11y style guide for developers, designers, and writing
- Google developer documentation style guide: accessibility and inclusive language
While not primarily about content, the Learn Accessibility offers useful commentary on business and legal impact, which can be used to argue for funding accessibility.
- "Move beyond empathy: a11y in documentation, a talk by me, with video.
- "A11y friendly documentation", a talk by Carolyn Stransky (video from Write The Docs)
- "Don't say simply", a talk by Jim Fisher (video from Write The Docs)
- "Leveraging Accessibility and Usability to Serve Truly Diverse Audiences", a talk by Tearyne Almendariz and Kat Shaw (slide deck)
- Learn Accessibility from web.dev
- ARIA guidelines
- The Accessibility Cheatsheet by bits ofcode
- GSA Government IT Accessibility program (i.e. Section 508)
- Microsoft inclusive design toolkit
- Smashing Magazine's guide to designing accessibly
Always test your work. You can't help your users if you have no understandng of accessibility tools.