Improve your team’s accessibility game in 5 steps

11 min readOct 18, 2019

Why aren’t more digital experiences accessible?

Web accessibility means that digital experiences are designed and developed so that people with disabilities can use them. When digital experiences are not accessible, then online content and services are unavailable for a huge population of people with disabilities.

There are already plenty of articles about how most digital experiences are not accessible. All you need to do is Google that topic. This post is about why most digital experiences are not accessible, and how we can change that on our teams.

Nobody wants to exclude people

A person says that he wants to exclude screen reader users from content, above a caption saying, never said by anyone ever.

Nobody wants to exclude people from accessing content based on how they access it. Nobody is out there saying, “I don’t want keyboard users to buy my products.” Nobody says, “I would like to exclude screen reader users from learning about my company’s services.” Nobody says, “I prefer making interfaces confusing for people with low vision.”

This is just what ends up happening.

Designers who navigate with a mouse-pointing device know how to navigate that way. They don’t navigate with their keyboard, so they don’t know how to design an interface that works well for a keyboard user. How could they? Experience designers who never used a screen reader don’t know how to design for someone who does. Writers are not born knowing how to write for people who cannot see. Developers who only use a mouse don’t consider making things work with the keyboard alone.

Would you ask someone who has only ever driven a car to design the perfect bike?

People who never heard of keyboard or screen reader navigation can have some funny ideas. They often think that keyboard users need a completely different experience. They are fearful that the beauty of their design will be impacted by adding accessibility features. They imagine that creating an experience with accessibility features will take 2–3 times as long. They waste energy wondering who will use the accessibility features. They try to defend ideas like building and maintaining separate versions of an experience. As if that wouldn’t cost way more than just doing a single version that works for everyone.

So why listen to those people? This is a post from someone who has spent years thinking about this. I know how to navigate with a keyboard, and the constraining aspects of a linear experience. I test experiences with screen readers on a daily basis. Every chance I get, I work with keyboard and screen reader power users to get their valuable insights. And I can tell you:

Accessibility features do not have to impact design.
Making an experience work well with a keyboard and screen reader makes it work even better for a mouse-pointing device.
Considering the keyboard and screen reader experience adds an exciting dimension to experience design.
Experienced teams can create accessible experiences in almost the same time frame because it becomes part of how they design naturally.
Creating an accessible digital experience protects our clients from litigation and increases their reach.

The hardest part is getting started.

So what can we do?

This post outlines 5 steps to get teams creating accessible experiences. The best part is that there’s nothing stopping you from starting to do them today. Getting started on these 5 things should lead to a place where team members start to feel ownership over the entire experience — no matter how it is navigated.

One: Train the entire team to navigate online with a keyboard and screen reader.
Two: Review wireframes for accessibility compliance.
Three: Review designs for accessibility compliance.
Four: Review code for accessibility compliance.
Five: Review any content updates for accessibility.

One: Train the entire team to navigate online with a screen reader.

Set aside 1–2 hours for your team to practice using a particular screen reader together. Be sure to include the project manager, the creative team, and the development team on the invite. Once everyone is familiar with basic screen reader navigation, try buying something online without using your mouse, and without using your screen.

This is something you can do today and I promise, it will have a huge impact.

On a Mac, this is as easy as turning on the operating system’s built-in screen reader, VoiceOver (command + F5). On Windows, download the free NVDA screen reader and use it with the Firefox browser. Don’t forget to try the screen readers that come with your mobile devices, too.

The team will experience difficulties navigating with their keyboard and screen reader. During the exercise, take time to reflect on what these difficulties are. They will include:

For the first time, they will have to navigate an experience in a linear way. Most experience design does not account for the linear experience. It will take longer to get to the content they want to access.
It will be frustrating for keyboard users to have to tab through long navigation menus on every page.
It will be hard for keyboard users to locate their focus area on a page if this was not accounted for in the design.
Vague link labels that don’t provide enough context when heard on their own will stump people trying not to look at their screen.
Critical information is available to sighted users but not announced by screen readers. For example, screen readers will announce “link” for linked icons with no name. Product tiles on an e-commerce site will not announce the price.
Screen readers announce critical information incorrectly due to visual formatting choices. The price may be announced incorrectly due to missing decimal points. All caps titles may be spelled out letter by letter.
Team members will have a hard time filling out inaccessible forms.
Some content display paradigms are inherently challenging for screen readers to interpret. These include carousels and modal dialogs. Any custom component with no native browser equivalent fits into this category.

Two: Review wireframes for accessibility compliance

A designer says, considering the linear order of navigating the page adds a whole new dimension to experience design.

The common screen reader issues listed above are preventable at wireframe stage. Check wireframes to make sure they are not present in the early stages of your experience design. Anyone who reviews the wireframes can provide this feedback. This includes another experience designer, a visual designer, or a front-end developer.

Read the wireframe contents in a linear way. Consider if the flow of information would make sense to a keyboard or screen reader user.
Does the experience design provide other ways for non-mouse users to navigate? For example, is a skip navigation link provided? Are page landmarks documented for screen reader users?
Read the link and button labels. Do they make sense on their own? Hint: Avoid vague labels like “Learn more” or “Details.”
Do the link and button labels include ableist language? Labels like “Click to expand” and “See more” do not need those particular verbs. Use more descriptive language and drop the verbs. E.g. “Expand product details” or “More articles by Jane Smith.”
Ensure linked iconography in the experience includes the icon name. The name should describe the purpose of the icon. E.g. An edit icon should have the label “Edit [item],” not “pencil.” This name is the one that the screen reader announces. It is not a visual name.
Be wary of problematic formatting choices in the design. Examples include pricing information without decimals or employing strike-through formatting. These choices need extra thought for a screen reader to announce them correctly.
Watch out for abbreviations that would sound better if announced in full. Examples include days of the week on a calendar (“Monday” sounds better than “Mon”), and months of the year. It is common for words like “included” to use abbreviations for sighted users. However, it doesn’t make sense to announce them in an abbreviated form (e.g. “incl.”).
Required form fields should be indicated in the label. Labels should include all advisory information (e.g. formatting requirements). All form fields need a defined label, even if it is not meant to be visible (e.g. search form fields need a defined label). The screen reader must announce error messages along with the label when a form field has focus. The form submission and error notification process must be documented for keyboard users.
Note missing documentation. Document how keyboard and screen reader users should experience a carousel, for example. Do not assume a developer will figure it out on their own.
Wireframes should describe focus handling for custom component interactions. Work with a developer to figure this out.
Never stop learning. When designing or developing custom components, do research. Do an online search for “accessible modal dialog” or “accessible carousel.” Ensure that keyboard specifications are included in the wireframes.
Check to make sure that the experience is designed to give users control. Can animations longer than 5 seconds be paused? Do videos include links to transcripts?
Conduct this review before sharing the experience with clients.

Three: Review designs for accessibility compliance

Common accessibility issues are preventable at the design stage. These include low contrast color combinations and using color alone to convey content. Anyone who reviews the design comps can provide this feedback. This includes an experience designer, another visual designer, or a front-end developer.

Ensure that the style guide includes the design for the skip navigation link.
Ensure the style guide includes visible focus indicator designs for interactive elements.
Ensure color alone is not used to indicate state for radio buttons or checkboxes.
Ensure color alone is not used to indicate state for links within body text.
Make sure that text against a background or image meets minimum contrast requirements. Designers should use a tool to check this, e.g. WebAIM’s contrast checker.
Avoid the paradigm of layering text over an image. It is difficult to ensure that this will always meet contrast requirements.
Icons and form elements also must meet contrast requirements against their backgrounds.
Note that images of text do not meet higher accessibility requirements. Text embedded in an image becomes pixellated when zoomed. Avoid doing this without the client’s understanding of the issue.
Document the designer’s intent for using specific imagery. This will make it easier for a writer to create proper alternate text for the images.
Conduct this review before sharing the experience with clients.
This blog post outlines a list of tools for designers to help them design in an accessible way.

Four: Review code for accessibility compliance

A developer asks a designer to put the visible focus indicator design in the style guide so that they can code it properly.

Common accessibility issues are preventable at the development stage. These include keyboard issues and custom components without defined names, roles, or states. Sometimes developers forget to use semantic HTML or separate style from structure. Anyone who reviews the code can provide this feedback if they test with a keyboard and screen reader. The developer should not consider their work complete until they have done this. Automated tools can detect code-related accessibility issues. Developers should fix issues reported by automated tools before submitting their code. Developers are also great gate keepers. They are often the first people who “try out” the design, so are the first to notice that things are missing. Developers, give that feedback to the designers.

Test all functionality with the keyboard alone.
Test all functionality with the screen reader.
Use a page-level automated accessibility testing tool to test the code. (Like the WebAIM toolbar).
Zoom into the text alone up to 200% and ensure the content is still legible and functional. You can use Firefox > View > Zoom > Zoom text alone to do this.
An appropriate name, role, and value should be announced for all custom controls. Custom controls include tabs, custom select menus, modal dialogs, etc.
When a custom control has a native browser equivalent, it should function the same way with the keyboard. For example, a custom select menu should work the same way as a native select menu.
Use semantic HTML. E.g. use heading markup to mark up headings. Use list markup to mark up lists of items. Use buttons for interactions that cause scripted behavior on the page or submit a form. Use links for interactions that take the user to a different page, or to a different place on the same page.
Separate style from structure. All headings should be configurable based on the content structure. For example, changing a heading level should not change the style of the heading.
Test the updated code with the keyboard alone, and with a screen reader.
Conduct this review and fix all issues before testing phase.

Five: Review any content updates for accessibility

An accessibility-compliant experience can become non-compliant after a simple content update. Anyone can review a content update to make sure it is accessible.

Updated text content should have a semantic structure. That is, heading tags wrap heading content, list tags wrap lists, etc.
Updated link or button text should describe the purpose of the link or button.
When adding imagery to the site, add appropriate alternate text.
When adding a video, include captions and a transcript. Ensure that text in the video meets contrast requirements. Ensure videos do not contain seizure-inducing content.
Update screen reader only content when page content changes. For example, if you update a vague link that has a more contextual aria-label, also update the aria-label.
Use a page-level automated accessibility testing tool to test the updated content. (Like the WebAIM toolbar).
Test the updated content with the keyboard alone, and with a screen reader.

Everyone has ownership

An experience designer makes suggestions to improve the screen reader experience based on his testing.

I dream of a world where everyone feels direct ownership over the holistic experience they helped to create. Where people are not mandated to go through a checklist — they simply care enough to be curious about how the experience works for everyone.

What’s next?

First, focus on the five steps above. When you’re ready, there are more things that you can do. This next set of five things will need buy-in from your leadership team. Hint: Give them the screen reader training first.

Six: Incorporate the screen reader training into your company’s onboarding.
Seven: Incorporate the accessibility reviews into every project.
Eight: Increase the diversity of your user testing groups. Add keyboard or screen reader users, or people who invert the colors of their screen.
Nine: Make sure your company’s own recruitment website is accessible.
Ten: Make a point of hiring more people with disabilities to provide insights up front on our teams.