It goes without saying that designing for all types of people, whether they are suffering neurological conditions, vision impairment or motor disabilities, is an essential constraint. At Andculture, research often focuses on particular users, such as students, first time moms, people seeking medical treatment, and a variety of other user types. In the back of our minds, we are aware that in addition to these user types, we have to take other accessibility concerns into account.
Andculture has a history of utilizing accessibility guidelines like Section 508, part of a federal law mandating that anything electronic or information technology related, used by the federal government, is accessible to people with disabilities, and Web Content Accessibility Guidelines (WCAG) 2.0, which defines how to make the web more accessible to people with disabilities, on projects. To assist in determining if a site passes accessibility guidelines, there are a variety of tools at one’s disposal as well as both Section 508 and WCAG2.0 being well documented.
For the tools, the designers here at Andculture have been looking into ones that fit into our current tool set, such as Sketch, online tools for testing things like color and contrast, and those that allow us to test entire websites in the browser. For instance, we’re currently focusing on making sure the colors we are using on a large enterprise site comply with 508 in regards to contrast. As two other designers and myself are working in Sketch for this particular project, we started using a plugin called Stark that allows us to see what a person, with one of eight types of colorblindness, would see. I am able to select a particular artboard and view it from the perspective of someone with the Protanopia condition. Stark also allows us to check contrast, an important criteria in WCAG 2.0, which outlines that for AA requirements color contrast should be 4.5:1 or 3.0:1. or large text and for AAA requirements, the color contrast should be 7.0:1 or 4.5:1.
We use several websites to check contrast, including https://webaim.org/resources/contrastchecker/ and https://contrastchecker.com/. With both options, I like that I can move around on the color wheel, or use the sliders, and see how much or little is needed to pass the contrast requirements. This feature came in handy when we were testing a blue, which was a possible primary color for a client on different backgrounds. We realized that, due to it being a lighter blue, even the lightest backgrounds caused it to fail. Fortunately, as the blue wasn’t set in stone we were able to darken it slightly. This allowed for background colors that, when used on buttons for example, would have enough contrast with the web page’s background color (which was general white or a light gray). There are also online sites that can load a site within the tool, and view issues, like Wave (which I also discuss below).
Finally, there are a variety of browser extensions that we’ve been using to test for accessibility issues. One my favorites so far is aXe accessibility, with a set of tools that shows us a variety of errors for common accessibility issues. This isn’t the first tool we use, when we’re still designing the pages, but once the developers launch MVP (or beyond), this is a great chance to run through the site to see if anything was overlooked. It is also a helpful tool if you want to check your current site for issues, before doing a relaunch, etc. There are some other extensions that we’ve tried, like Funkify and Wave, but so far I personally default to aXe.
As you can see there are a lot of tools out there for checking accessibility issues, so there is no excuse not to use them. Most of these tools are pretty easy to use and deliver results. And, while some might have subtle glitches, I believe these tools will continue to get better and better as time goes on.