Accessibility and inclusive design checklist
Everyone, regardless of device, circumstance, or ability, should be able to read, and take action on your content. This is increasingly more important as more and more services necessary to living everyday life digitize: paying your bills, buying groceries, talking with friends, etc. Some of the best things you can do to improve your product’s accessibility are also some of the easiest. Following is a list of items you can audit yourself:
Language support
Provide a document language
Programmatically specifying a document language lets screen readers know how to properly pronounce your content.
Be sure to also identify sections where the language changes, such as quotes or foreign phrases. If your app is localized, the programatic identification should update when the language updates.
Document structure
Section your content
Break up sections of content into easily-digestible “chunks” of related information. Both headings and landmarks can do this. For headings, ensure that they describe the content they contain, and are ordered in a logical manner.
Colors
Use proper color contrast
The ratio between the foreground color of your content and the background color it is placed on top of must have a ratio that helps guarantee it can be read in low vision scenarios.
Tools such as WebAIM’s Contrast Checker and Stark can help you determine if the ratio you are using is sufficient.
Images and visual media
Describe your images
Most images should include an alternative description, for those who cannot see it. An alternate (also known as alt) description should succinctly describe the content of the image.
The W3C’s WAI Web Accessibility Tutorials provides an alt decision tree to help you determine what images need a description.
Video content
Provide captions and transcripts
Video content that includes audio should display synchronized captions. Caption content should include speech, but also relevant sound effects and music.
Transcripts are also important to provide, especially for longer-form audio such as podcasts.
Form items
Give inputs labels
Checkboxes, radio buttons, and single and multiline text inputs all need to have a label programmatically associated with them. The label provides a description of what the input is for. Labels should be concise and describe what kind of input the form represents (ex:“Phone number”).
Destinations and user actions
Ensure that links and buttons work
Links should point to a valid URL, and buttons should trigger activity. Link and button content should be clearly and concisely written. Link content should provide enough context about its destination. Button content should describe what kind of action will be triggered when activated.
Related material
Keep going
The previous items will greatly help improve the accessibility of your products, but there’s more work to do. The A11Y Project’s Checklist is a great next step.
