Here at Rally, developing applications with accessibility is always top of mind: many of our users rely on our products to navigate their healthcare and it’s important to ensure all our users are equally able to access our applications. .

Regardless of your user demographics, creating experiences that all users can enjoy should be a top priority for any designer or engineer taking pride in their work.

Let’s look at how to design with accessibility in mind, identify the sorts of users we need to consider when creating these interfaces, and discuss how to ensure that accessibility remains a top priority in all phases of development.

Understanding the Scope of Accessibility

When envisioning the groups affected by accessibility concerns, we tend to think about people with permanent disabilities, specifically the blind. However, it's equally important to remember that there is a wide spectrum of disabilities that can alter the way users access a digital experience. It can be helpful to categorize disabilities by duration and type:

Duration

- Situational

- Temporary

- Permanent

Type

- Visual

- Motor

- Hearing

- Cognitive

By viewing the intersections between these categories, we can better imagine the variety of disabilities our users might face:

We can now start to understand how many users will at some point be accessing our apps or websites while navigating some kind of impairment.

Why Accessibility is Critical to You

As mentioned earlier, Rally takes extra care in developing our applications. But what if your app is targeted at the general population? Should accessibility be as important to you? This might help put it in perspective. Consider the prevalence of these disabilities in the US population compared to the market share of commonly-supported browsers:

It might surprise you to see that many types of disabilities are more frequent than browsers typically given first-class support from developers and product owners. There's no sense in supporting IE 11 if you haven't already given full support to the colorblind and those with visual impairments.

A failure to provide an accessible experience is certainly going to negatively impact your users’ impression of your product, and they’re going to make their concerns known. If you want your product to have a reputation for excellence, accessibility is an important factor in maintaining a high user rating across all metrics, including app store ratings, and Net Promoter Score (a measure of how likely your users are to recommend your product to others).

How to Promote a Culture of Accessibility

There are lots of excellent resources available for free to get designers and developers up to speed with the gritty details of how to create and implement accessible interfaces. Instead of discussing that here, let's look at some ways to address the underlying issues that can create organizational apathy toward accessibility concerns.

Think About Accessibility From the Beginning

In a perfect world, all UX designers would be well-versed in how to make applications accessible for everyone, but most organizations aren't quite there yet. As developers, it's our responsibility to advocate for accessibility at every opportunity, and that includes providing constructive feedback on the designs we're given for implementation.

Be on the lookout for these common problems in particular:

Color

When first encountering a new design, pay close attention to the usage of color and contrast. Verify that color is not the sole means of conveying semantics to the user (i.e. error messages should not just be red, but should also include a label like "Error"). Relying on color alone will hinder users with visual impairments like colorblindness.

Similarly, ensure that there is sufficient contrast between foreground and background colors, especially between text and its background color. This helps both the colorblind and those with otherwise impaired vision to clearly read all of the important text.

Use of Non-Native Elements

Designs, implicitly or explicitly, often require the use of custom elements such as dropdowns to allow for greater control over the appearance of the UI to match the desired brand guidelines. It’s often possible to leverage CSS to reskin native browser controls to match the required designs, but when that’s impossible, you may need to create a custom component.

Push back against these custom components as strongly as possible in favor of their native browser counterparts. The native implementations already support all the required accessibility features, and replicating that in a custom component will not be a trivial task. For reference, see [the keyboard interactions that a collapsible dropdown needs to support](https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html) to achieve AAA compliance.

If you lose the battle, refer frequently to the ARIA Design Pattern Example relevant for the component you’re building. Most of them contain compliant code examples you can and should use as a starting point.

Add Accessibility to Your Workflow

It's easy to take steps to involve accessibility in your daily work. For example, when building out a new view or UI component, take the time to occasionally [pop open the DevTools Audit panel](https://developers.google.com/web/tools/lighthouse#devtools) and run an accessibility audit against your work to check for any automatically-detectible deficiencies, like contrast issues or missing ARIA attributes.

Familiarize yourself with screen reader technology, and use it to navigate your (and your teammates') UI views and components to ensure things are navigable and comprehensible. If you're on a Mac, you can launch your screen reader, VoiceOver, by pressing ⌘+F5. You'll be able to pick up the basics of VoiceOver in just a few minutes. If you're on Windows, you can download the NVDA screen reader for free. It's worth learning and using both since, much like web browsers, different screen readers will interpret the same HTML differently. Mobile devices use their own screen readers built in to their operating systems. iOS has its own version of VoiceOverand Android uses TalkBack, both of which are well-documented.

When reviewing your teammates' code, always keep accessibility in mind. Consider adding a task checkbox to your pull request template confirming the developer has verified the accessibility compliance of their code changes.

Enforce Where Possible

You're probably already running automated linters against your code, so adding some linters for accessibility should be easy. There are plenty out there that can easily fit into any linting or pre-commit workflow, including AccessLint and eslint-plugin-jsx-a11y.

While you're at it, remember that DevTools Audit pane we mentioned earlier? Those audits can also be automated and added to your CI workflow. Look into leveraging a tool like Lighthouse or react-axe. If you have end-to-end tests running, you can run an accessibility auditing API like axe-core against every tested view. Strongly consider failing your builds if any serious or critical issues are found. Remember: A serious accessibility issue means that the affected portion of your application will be unusable for some portion of the population. If you don’t want that in production, this is the place to prevent it.

A Great Experience for Everyone

As engineers, we're all invested in creating software that has a meaningful impact on the lives of as many people as possible. By making a few small, low-effort changes to the way we work, we can ensure that every single one of our users feels like our software was made *for them*. That's something we can all be proud to strive for.

Advocating for a Compassionate UI