The essence of accessible color contrast is simple. Given a foreground color and a background color, the contrast between those two must be distinguishable in a wide variety of environments, by individuals with different color perception abilities. Using the Web Content Accessibility Guidelines — WCAG — version 2.0, these contrasts are measured using an algorithm that compares the relative luminosity of the two colors and returns a ratio, which is to exceed WCAG’s recommended minimum.
But the reality of color contrast is more complicated. There are a lot of assumptions to work out before you can be confident that visually impaired shoppers can use your ecommerce site.
What Are ‘Foreground’ and ‘Background’ Colors?
The terms “foreground” and “background” are used frequently in references to color contrast. The most common contrast scenario is between text and the color of the background behind it. The foreground color refers clearly to the text and the background, well, to the background color. This is clear.
But there are other scenarios where foreground and background aren’t really the appropriate terms. In these instances, a better description is “any situation where the only characteristic available to distinguish two elements is color.”
This clearly applies when text needs to be distinguished from the background color. White text on a white background may as well be absent entirely. But it also applies to neighboring text, such as a link within a paragraph. If that link looks the same as the text surrounding it, there will be no way of identifying visually which text is linked.
If your links are underlined, this becomes a non-issue.
What Two Colors Are We Comparing?
The simple case of text in a single color and a background in another is easy. When assessing contrast, automated tools will reliably identify the two different colors.
But that is not true with other common cases:
- Text with text-shadow;
- Background gradients;
- Image backgrounds;
- Transparency in one or more colors.
These cases aren’t directly addressed by WCAG guidelines. You’re left having to make your own decisions on contrast. However, there are some helpful recommendations and rules to lean on.
Adding a thin black outline with a minimum width of one pixel is a WCAG recommendation to maintain a contrast ratio between the letter and its background. While this doesn’t directly correlate to text shadow, it’s reasonable to extrapolate that adding a text shadow to darken the boundary of your text allows you to use it for measuring contrast, rather than depending on the background color.
When the text isn’t against a solid color, it’s hard to know exactly what you should be comparing it to. A decent rule is that at least 50 percent of every character should be on a background that meets color contrast. A good technique for dealing with the problem is probably to use a text shadow, since meeting that 50 percent threshold can be difficult.
With background images and gradients, there are other issues beyond color, such as visual confusion caused by textures or shapes that interrupt the path of the letter shapes. I’ll expand on that topic in a future post.
Challenges with Transparency
Transparency is the relative opacity of a color; higher transparency allows more of the background to bleed through. Transparency is more an issue with automated testing. Not all automated color contrast tools will understand it. So when text or background colors are specified using an RGBA or HSLA definition, there’s a good chance that they’ll pick up the wrong color. This could mean you’ll get false positives or false negatives when running automated tests.
A false positive is relatively easy to deal with: You can look at the location where the test picked up the wrong color and use an eyedropper tool to identify the color that’s rendered on the page to make a manual comparison.
False negatives are more difficult. If a tool didn’t recognize a problem because it misidentified the colors, you’re typically stuck using your own eyes to assess suspicious areas of the page. Spotting color contrast problems takes practice, and can sometimes be quite surprising.
If you have good color perception, you can likely see all the significant areas on the page. You can spot text that looks too faint, and manually test those colors. But because the measurement of luminosity is designed to compensate for problems in color perception, you may find yourself believing that two colors pass easily when they fail the test severely. A significant difference in color perception could be insignificant in luminosity. Viewing a page in gray scale is an effective way to remove color perception as a factor in distinguishing these issues.
What Are the Contrast Requirements?
The WCAG’s color contrast requirements vary depending on font size. But the WCAG references only two font sizes, so this should be simple. Normal text, at a font size below 18 points (or 14 points and bold) must have a contrast of 4.5:1. Any text larger than that can have a contrast of 3.0:1.
But what, exactly, is a point? What size is 18 points?
Points are a standard measurement for fonts in print. Seventy-two points is one inch. This measurement, unfortunately, is next to meaningless on a computer screen. As a result, points need to be translated into a better web equivalent.
The most common translation is that an 18-point font approximately equals 24 pixels and a 14-point font approximately equals 19 pixels. Whether this is actually accurate would depend on the font; but it’s the best approximation I have found.
In short, while color contrast is one of the simplest tests to do — comparing two simple colors — ascertaining exactly what those two colors are, in an actual scenario, poses some challenges. But with a little guidance on understanding how to assess those colors, you can readily move forward in analyzing your color contrast issues, to ensure visually impaired consumers can use your ecommerce site.
Resources for Color Contrast Testing
- WAVE Chrome Extension;
- Juicy Studio Accessibility Toolbar;