Accessible/Inclusive Style Guide

The intent of this document is to serve as a reminder for authoring accessible/inclusive documentation.

Term Definitions

Technical writing often uses abbreviations. These can be for agency names, software brands, code techniques, etc. It is important when authoring documentation never to assume that the user understands abbreviations. The first time the term is introduced within your writing, you must use the long form of the term followed by the abbreviation in parenthesis. This ensures the user is informed of the abbreviation's meaning.

Person-first Language

Always put the person first, not their disability. We favor "people who are blind" opposed to "blind people" because it leads with the individual and does not define the person by their disability.

Use appropriate/modern terminology

Many terms for People with Disabilities (PWD) are outdated. There are terms I have encountered in my career that are outdated and should not be used.
Good Examples Bad Examples
People with disabilities The disabled
Disabled Handicapped/crippled
Person with a disability "Normal" or able-bodied
Cognitive or Mental Disability Retarded
People with visual disabilities The blind

Reading Level

WCAG has a AAA-level requierement for SC 3.1.5 Reading Level. Most organizations do not adhere to AAA but only meet A and AA requirements instead. Still, it's important to understand how reading levels affect the end user(s).

When content is difficult to understand or when too many complex words or phrases are used, users may stop interacting with your content due to not understanding it. Plain language that is easy to understand is recommended where applicable. This concept can be challenging when performing technical writing of complex concepts but should be considered when authoring content.