If you’re reading this article than you are at least interested in accessibility, a professional in the space, or somewhere in between. You may be looking for new tools or new workflows to help you test for accessibility and that’s essentially what we are going to delve into. Take note that it’s just like a bare bones package or a process that you can use to test accessibility in your web apps.
With accessibility testing in general, one of the first things to do is to catch accessibility issues early. In fact, it’s not hard and it will make your life easier down the line. We’re not going to go really in-depth into what accessibility is or why you should test for it because we’re assuming that you kind of have a sense of that already but at the core, accessibility testing will improve your applications and protect you from compromising your user experience.
Standards and guidelines
So how do we know when our content is accessible? What are we looking for?
WCAG 2.0 is the web accessibility guidelines revision 2.0 that defines pretty much the canonical standards of what web accessibility is and how to test for it. It’s a vast document that has a variety of entry points but you’re not going to be able to just get your hands on WCAG 2.0, walk through it and test every single little guideline because it’s sometimes esoteric or opaque. It’s very broad and far-reaching. This is why this article will try to help you distill that down and find tools that bundle together certain sets of rules that will make it easier for you.
With regards to WCAG, there are some high level approximations of the subset of the rules that WCAG defines:
Labeling form elements
If you don’t label your form elements, someone using assistive technology won’t be able to associate what the form is supposed to be doing. For example, you have a password field and if you don’t have a label associated with the field and someone navigates to that field, they are not going to get any announcement from a screen reader.
Alternative text for non-text content
Amongst other things, you may know it as alt attributes on images. The idea here is if someone is visiting your site and they can’t see the content as a sighted individual. They need some sort of alternative text and assistive technology can announce that to them so that they get a full experience of the content.
Ensure color contrast meets a minimum threshold
People who experience low vision are and for that matter, people outside on a mobile phone are not going to see your content if it’s extremely light grey on extremely light grey. This is sort of a best practice from a user experience standpoint in general but WCAG defines specific thresholds for contrast in your applications.
Do not use color alone as an indicator of meaning
Color blindness being the example here, if you have a series of results, let’s say, in a set of test assertions and they’re passing and failing. If one is green and one is red and if you just have a little dot there that says green and red, it’s not very communicative to someone who’s color blind.
Captioning audio content
To make it simple, if someone can’t hear audio, they’re not going to be able to enjoy your presentation that you posted online so basically, the solution is to add captions.
These are just a few of the rules you might actually encounter in WCAG and it’s a lot to manage honestly so what a lot of people have done and what others tried to help contribute to online through open source projects is bundling and codifying these rules into assertion libraries.
Basically, it’s code that you can run on a page that will evaluate aspects of these rules and this will tell you if you have errors and how to fix them. It’s not going to give you a full picture of accessibility but those kinds of things are what computers are for such as checking color contrast, checking label associations, etc. These are repetitive tasks that can be effectively codified into a library.
Useful Tools for Testing Web Accessibility
So what are the available tools that you can use today to test for accessibility? Here are some of our top picks:
Contrast Checker
This does pretty much what you would expect it to do. You enter background color on the left, a text color on the right, and it gives you a value and that value is the contrast ratio for those two colors. In general, WCAG 2.0 specifies 4.5 to 1 minimum contrast ratio for text sizes 14 point bold.
Now, keeping in mind: point is not pixel. There’s a calculation that converts points to pixels that you can do, or you can go to a site that has a table of pixel and point values, and just look it up. It’s something like 14 pointing is about 18.7 pixels so it’s something that’s easy enough to convert.
And then if you put something that’s a lower threshold, it turns red and gives you a warning message and tells you why or makes a recommendation on what would be a better combination.
Accessibility Developer Tools
This is a Chrome extension that you can install through the Chrome web extension store for free and it will make assertions on things like we discussed about. It is a set of assertions written in JavaScript that are encapsulated in a plugin.
After installing this plug-in in Chrome and you run it, it pulls up the console that you would use for developer tools that is part of many developers’ daily workflow but it actually adds failures and it inserts rules into the page. You run it and it creates a list of failures and warnings. You click on any of those failures and warnings and it opens up the element in the inspector so there’s this seamless integration for a developer between what’s failing, where it is on the page, where it is in the code, and what you can do to fix it.
For example:
For color contrast, there’s a color contrast assertion built into this library that will allow you to click a button and actually change the color of the text in the browser so you can immediately get an idea of “what would look like if I made it a little bit darker?” Maybe it goes a little darker in the blue direction or the purple direction but it’s a good starting point.
Capybara-accessible
This is an automation framework for testing accessibility within a browser. It essentially writes a script that walks through the pages and it will run tests from Accessibility Developer Tools on the page and give you a list of failures for every single page so every time you click a link or visit a page, it will automatically generate those failures.
For people who are in QA or are developers, especially if you practice test-driven development, this is kind of awesome. What it does is it integrates these rules into a capybara script.
If you’re not familiar with capybara, it is a way of automating web browser interactions. You can write a script that says “click on start” and it will click on any button on the page that’s labeled “Start” so this is great for automating web pages. By itself, you can just make regular assertions like the page should have some content but when you mix-in accessibility development tools, it actually makes assertions and then you get output.
So as a developer or a QA developer, you can run this test and get a very specific idea of where the failure is. And even better, you get an idea of regression testing so if someone introduces a bug later on down the line, all of your work testing it in the browser accessibility development tools will go down the drain if someone introduces a bug. This will guard you against that.
If you really want confidence in the accessibility of your content, you’re going to have to put it in front of people and ask them what their experience is. But before you do that, you might want to do some of smoke test, as we might call it, in the browser.
The first thing you can do is use tab navigation to ensure that you can focus all of the elements on the page with just the keyboard. Imagine you have a motor impairment where you can’t use the mouse. You’re going to be using only the keyboard to navigate the content. So if you open a link and it pops up a window and you can’t navigate to the close button, or hit escape to close that dialogue, you’re screwed. Now you’re in a state where you can’t use the site anymore. Ensuring that you can tab navigate through all the content will support both users with motor impairments and also people who are using screen readers, to some extent.
The next thing you can do is use VoiceOver or some other screen reader with your content. VoiceOver on the Mac is the built-in screen reader that you can activate by hitting command F5.
The caveat there is that unless you’re a sophisticated or even somewhat a practiced screen reader user, you’re probably not going to understand what the experience is going to be like. You’re not even getting a full approximation and you’re just trying to put yourself in the shoes of someone who is using your site and have empathy, and also troubleshoot maybe specific issues. To that point, if you enlist people who are sophisticated screen reader users, then you get a full picture.
Loop11
There’s one service in particular called Loop11. It’s a usability testing service online that will connect you with users who have disabilities that can test your site and give you feedback. It’s sort of an advanced route to really accessible content so that’s high level usability run-through.
NVDA and JAWS
If you’re using Windows, you have a couple options. Probably NVDA would be best because it’s free and very good especially with Firefox. You can also use JAWS which is still the most prevalent screen reader today. They have a trial version that stays open for 40 minutes and then you have to restart the tool to be able to use it again.
You can also use something like VMWare’s Fusion or Parallel desktop where you can open Windows on your OS X desktop so you don’t need a Windows machine to get that experience.
The bottom line?
By hook or by crook, right, make your content accessible. If you need to use VoiceOver with Safari, and that’s all you can do, that’s a start and maybe it’ll push you into a direction where you can have more sophisticated practices and tools available later on. The first step is to start with what you have.
Add Comment