Accessibility as you go: Part 2

Picking up where we left off from the first in our Accessibility as you go series:

Testing tools and design process

Nip Color Contrast Issues in the Bud

During the design phase, it’s important to verify that all text on the site has high enough contrast with its background color. Level AA contrast requires a contrast ratio of 4.5:1 (except for large text, incidental text or logotypes.) Level AAA requires 7:1, which does tend to limit designers. I will often review comps as they come in from designers and point out places where it seems like it will be a problem to meet Level AA standards

If one is using Sketch for design and layout, there is a nice plugin for checking color contrast directly from the application: Color Contrast Analyzer

Photoshop and Illustrator don’t have specific tools for this yet, but you can view a comp as grayscale to help. If it seems like text contrast might be not high enough, I’ll use the eyedropper tool to check the background and the foreground using WebAIM’s Color Contrast Checker

The differences may be clearer viewing it in grayscale:

As you can see, it may be better to rely on the measurements than eyeballing it — I would have thought some of these had better contrast levels than they do!

Make sure you  evaluate any use of text over images. This can be tricky, especially if content creators can upload their own images. Consider what edge case images might provide in terms of contrast, and adjust accordingly (adding a semi-transparent background, adding a drop-shadow, or a solid color highlight behind the text). Note also that when text is over an image, the contrast tools can’t read the contrast ratio — it may pick up the color behind the image instead. You may have to test for this manually with edge cases

Designers should check contrast early in the process and when stipulating the style rules in a style guide. Front end devs who implement designs should push back when they receive designs that promise to be problematic

Note that there are different contrast standards for small text and large text. Text is considered large if it is  at least 18px normal weight or 14px bold weight.

Tools for testing

The tools I tend to use for accessibility testing include:

– Webaim’s WAVE browser plug-in:

The WAVE tool will mark errors and contrast issues both on the page and in the pop-up markup web inspector. It will also give you information on the errors and how to fix them. In the above example, there is a contrast error on text that is replaced with an image. It is still probably worth fixing to ensure it passes all tests (though an example of something that isn’t really a problem for users.)

– Khan Academy’s Tota11y bookmarklet:

Tota11y has a nice user interface, and is good for finding contrast errors. I find WAVE to be slightly more comprehensive — but in the end, checking both seems to help catch everything since they sometimes focus on different things

A comprehensive list of other tools can be found on w3.org. However, you can catch most errors using the first two

If you are using a CMS like Drupal, generally accessibility will be good out of the box. So it makes sense that problems will start cropping up as you begin implementing the design. For this reason, one of the best ways to stay on top of accessibility issues isn’t about code or design at all:

Incorporate accessibility testing into your workflow

At Advomatic, we work in two week iterations. We do code review and testing on each ticket as they are completed, and on the last day we run all tickets through a set of rigorous QA tests. This is a time for us to run the testing link from the accepted tickets through the WAVE testing tool. Because we do this early and often, we avoid having to make structural changes (like changing markup order, reordering tabIndex or replacing buggy libraries) at the end of the project

Next week, the final part of the series: Accessibility during Development.