What user researchers need to know about accessibility

As a UX researcher, you are intimately familiar with identifying and solving problems. However, one area that doesn’t always get enough attention is accessibility. It can be difficult to test for accessibility, especially if you don't have a pool of qualified users to help.

So, what is accessibility? And what do you need to know about it?

Accessibility is how users with impairments – whether permanent or temporary – use the web. A permanent impairment might be a user who is legally blind. A temporary impairment might be someone that wants to watch a video on their phone but is in a public space where they can't play the sound. In both cases, users need a more accessible experience.

Obviously, you want people from all backgrounds to be able to benefit from your experiences. Plus, when web experiences are accessible to those with impairments, they wind up being more accessible to all. A feature that was designed for someone hard of hearing may, in turn, benefit others who prefer to read via closed captioning.

Getting started with web accessibility

If you’re learning about web accessibility, you can do a lot by yourself with free tools and a little common sense.

For example, some tools remove stylesheets so you can see what an unformatted website looks like:

• Use a browser extension to see how it looks for different types of color blindness.
• Increase the font size to 400% and see if you can still sensibly view all the content.
• Use a color contrast analyzer to make sure that any text on top of your images is actually readable.

Accessibility compliance

Since WCAG has three different levels of accessibility, start by implementing essential fixes and aim for A compliance. This is fairly reasonable to do with your own team and a little bit of training.

Once you’re there, the next goal is to get to AA accessibility, which is generally understood to be the industry standard. The next step up, AAA compliance, is very difficult to achieve in many instances, but it addresses virtually all accessibility issues and usability issues pertaining to accessibility.

Once you start validating for AA compliance, testing becomes much easier with input from actual users with impairments.

Testing for accessibility

First, go through your checkpoints to see how much you can implement and test on your own. Then as things get more complicated, find actual assistive technology users to try it out and demonstrate how well the more technical, nuanced fixes hold up in a realistic setting.

To validate your level of compliance, you’ll want to build a study that has users with varying impairments walk through the main or most popular flows of your site to see what they encounter.

You could direct them to a task that gets them involved in a checkpoint you aren’t sure is accessible or not. Your first few studies will probably be a combination of validation tasks to see if you’ve met the WCAG 2.1 success criteria, and common tasks to see if users with different assistive technologies can make sense of your site’s content.

It’s unlikely that all your participants will visit all 13 checkpoints across all your pages, so keep your study realistic and focus your efforts where you have uncertainty and where the most users will be affected.

However keep in mind that users with impairments may have different goals on your site depending on the content, which could change the focus of your study.

It’s very likely you’ll walk through the same study a few times until you’re satisfied with success rates and overall ease of navigation with assistive technology. Your studies will evolve as you focus on different checkpoints or discover better ways for users to access content on your site.

Regardless of where you are in your usability testing, remember that analyzing results from an accessibility test may be different than what you’re used to. It’s just as important to address an issue that one participant found as it is to fix what all participants found.

Each assistive device acts differently, and you will see different results depending on the participant’s operating system and browser. If you just test for NVDA (Non-Visual Desktop Access) on Chrome for Mac, you’re ignoring an enormous chunk of users looking for accessible websites, which could mean they won’t visit your site again.

Future-proofing accessibility

Accessibility testing takes a lot of time, and you’ll need a variety of users to test your site in the most complete way possible. Luckily, these guidelines, checklists, and other resources make it very clear what to look for as long as you put in the time and effort.

Once you take your first pass at accessibility, it becomes much easier to future-proof your site. These guidelines have been designed to withstand the test of time, so even as technology changes, these checkpoints won’t change significantly.

The reason we have WCAG 1.0 vs 2.1 shows us how much thought was put into this very concept. WCAG 1.0 focused more on specific HTML-based recommendations to keep your site accessible, whereas WCAG 2.1 kept the same principles but made them technology-independent and concept-based instead, adding much more flexibility.

Final takeaways

Making a site accessible makes it better for everyone, not just assistive technology users. Just like how you might use a wheelchair ramp with your rolling luggage, an accessible website shows that your site has clean, up-to-date code that is properly labeled and has interactions that follow familiar patterns. Good accessibility and good usability go hand in hand.

Unless you have the luxury of building a new site from scratch and can build accessibility into your roadmap, integrating accessibility after the fact takes a lot of time upfront. But once you reach compliance, it’s harder to backtrack than to future proof.

You’ll gain a sense of what you know will be accessible, and what you’d prefer to verify with assistive technology. Once you get your first page template accessible, it’s much easier for the rest to follow suit. Whether you want to focus on one page at a time, one checkpoint at a time, or one impairment at a time, accessibility is a flexible task to tackle.

We recommend keeping a spreadsheet of what has been tested so you don’t end up putting in too much work. Let automated scans guide your accessibility testing, but keep that human element to make sure you consider usability with your accessibility fixes.