Basic Tips for Considering Accessibility on Your Projects

I’ve supported a couple projects focused on promoting programmatic and physical accessibility and have learned a tremendous amount in a short time about the unique needs of this population. I admittedly need to get smarter on this topic, but I have picked up a few tips that I try to incorporate on the projects that I manage. I often find myself sharing these tips with junior project managers and other colleagues, so I’ve summarized them here in case others might benefit.

• Consider that someone may be consuming your content via a screen reader. A screen reader is a software program that reads text displayed on the computer screen with a speech synthesizer or braille display. To make it easier for the speech synthesizer to process the information, use alternative (alt) text to caption images, capitalize each word of multi-word hashtags, and refrain from using open circle bullets (the default second tier of bullet points in Microsoft Word.) The screen reader reads them as “oh’s”, not as bullet points.

• Use contrasting colors. Someone with low vision or who is colorblind may have difficulty distinguishing colors that do not have a sufficient degree of contrast from one another. WebAIM has a free contrast checker that you can use to validate your chosen color scheme. Enter the hexadecimal codes of the background and foreground colors that you intend to use. The site assesses the degree of contrast between the colors and lets you know whether the selected color scheme passes the contrast test.

• If you’re using Microsoft Office products, run the built-in accessibility checker. Microsoft Word, Excel, and PowerPoint include a built-in accessibility checker that checks for basic accessibility concerns, such as missing alt text or missing column headers in tables. Failure to include these items makes it harder for someone using a screen reader to consume your content. While the accessibility checker won’t find everything, it can help correct some of the more common issues.

• Identify whether your deliverable would benefit from a Section 508 compliance review. Section 508 of the Rehabilitation Act of 1973 governs IT accessibility laws and policies. Ensuring compliance with Section 508 requires specialized training. If you have the time, the budget, and the staff to conduct this review, consider incorporating it as part of your deliverable development process.

• Use inclusive language. If you’re using Microsoft Word, you can adjust your proofing options to check for bias, such as gendered language. A simple change you can make is to swap out “he” or “she” for “they.” “They” is increasingly being used as a singular pronoun, so no need to worry about subject-verb agreement.

Hope you found these tips helpful. Please let me know in the comments if you have other insights you’d like to offer!