What user researchers need to know about accessibility

As a UX researcher, you are intimately familiar with identifying and solving problems. However, one glaring issue that doesn’t always get enough attention is accessibility, since many of us don’t have access to a pool of users with various impairments to test things with. But that’s never stopped us before, has it?
Since accessibility is gaining attention and popularity, it’s going to be one of the next types of testing added to our toolkits, so we may as well start our homework!

In a nutshell, accessibility is how users with impairments – whether permanent or temporary – use the web. A permanent impairment might be a user who is legally blind, and a temporary impairment might be someone riding the bus without headphones so they can’t listen to sound on their phone. Accessibility applies to both, and ends up making websites and other digital products better for everyone.

To touch on temporary disabilities, let’s acknowledge that they are more common than we think. Maybe you broke an arm so you’re down to typing with one hand for a few weeks, or maybe you just don’t want to keep switching between your keyboard and mouse so you use keyboard shortcuts. Accessibility lets you navigate a site with shortcuts and fewer keystrokes so you don’t really need to use a mouse.

Of course these aren’t necessarily your ideal participants for accessibility testing, but it helps to put yourself in the mindset that you don’t need to have a severe disability to benefit from good web accessibility.

Getting started with web accessibility

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

There are tools that 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 colorblindness.
• 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

The Web Content Accessibility Guidelines (WCAG) 2.1 offer a really detailed list of what kinds of things you need to look for, why they matter and how to fix them

Print yourself a copy of an Accessibility Checklist and tackle one page at a time to get familiar with the checkpoints. Then scan your site with an accessibility checker like AChecker, W3C Validator, and many others so you have a place to start and can get a feel of what to look for.

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.

But don’t get discouraged – 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.

For example, in order to make an accessible table, WCAG 1.0 Checkpoint 5.1 specified “For data tables, identify row and column headers.” WCAG 2.1 Success Criterion 1.3.1 specifies in a much broader way, “Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”

Essentially, both these checkpoints make sure a screen reader user has the context of what row and column they are in when exploring a table. But since we have many more ways than just HTML to create a table, the WCAG 1.0 method is antiquated.

Final important 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 you 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 it is to future proof.

You’ll gain a sense for 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.

I’d 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. After all, how good is an accessible site if it isn’t usable?