Published in its revised form in June 2018, The Web Content Accessibility Guidelines (WCAG) 2.1 is the main guideline that web developers and designers should look to for accessible design requirements. It describes everything related to the world of accessible design — closed-captioning details, time-related factors, alt-text, spacing, and of course, guidelines for successful contrast across the user interface.
The topic of contrast within the WCAG 2.1 is a big deal. In fact, the concept of “contrast” is so important the guidance document dedicates three sections to it in order to cover various design elements.
Our present article introduces the concept of contrast at a basic level, discusses the contrast related sections of the WCAG 2.1 reqs, and provides a couple of real-life examples of good and bad contrast in digital design as it applies to websites and apps.
What is contrast?
In simple terms, contrast is the difference in brightness between objects in our field of view. The image of the green apple and the orange… um, orange… show how two objects that appear completely different due to color, are actually very similar when only contrast is considered.
Often, when we are talking about contrast on a website or app, the two objects being compared are objects in the “foreground” and stuff in the “background”.
Side note: For those unfamiliar with “foreground” and “background” the former refers to objects closer to the observer, while the latter refers to objects farther away from the observer. Understandably, these concepts seem odd in a digital landscape like a website or app, which is fundamentally two-dimensional. However, without getting too bogged down in the details, “foreground” content would include things that the user is meant to focus on, such as the text or images. “Background” content would include the white space “behind” the text or images.
If your background content is pure white, and your foreground content is pure black, then this would be considered the highest level of contrast possible. However, the closer the shades of your foreground and background colors approach one another, the lower your contrast.
How do we quantify “good” and “bad” contrast?
As noted above, contrast is not a standalone phenomenon, but rather a matter of comparison. Specifically, a comparison of the brightness between two objects. Because contrast is only definable as part of this comparison, the measurement that practitioners discuss most often is called the, “contrast ratio”.
A “good” contrast ratio corresponds with a higher value, while a bad contrast ratio is associated with a lower value.
Although beyond the scope of this article, it’s worth noting that many practitioners and researchers have not reached a point of consensus on exactly how to measure contrast ratio. We encourage those that are interested to read up on this elsewhere, as these differences might matter to your context or application. However, most methods — at least for the majority of UX practitioners — produce *very* similar results for the level of fidelity and accuracy that you’ll need.
What are the levels of accessibility compliance within WCAG 2.1?
The WCAG 2.1 defines three levels of accessibility compliance: “A”, “AA”, and “AAA”. More “A’s” means better accessibility compliance. The single “A” represents the “basic” or “minimum” standard that designers and developers should meet no matter what. If you miss the mark here, even users with a low-level disability (e.g., early stages of macular degeneration or Parkinson’s disease) may struggle with your design.
WCAG’s “AA” level is the standard for accessible design compliance. Rather than just meeting the minimums, this level is increasingly used as the benchmark for accessible design by companies. It’s also used as the standard in the (revised) Section 508 of the Rehabilitation Act in the United States.
“AAA” is the ideal or optimal level of accessibility compliance possible, according to WCAG 2.1. Designs that meet this level of compliance are theoretically usable by the widest range of users with a disability.
One reason there are different levels is that it’s not always possible to create designs that consistently meet the highest level of accessibility compliance. The design of a product or system is inherently tied to changing contexts of use, interface size, interaction mode possibilities, user capabilities and constraints, and variable use scenarios. And, while there may be ways to change parts of a design to be “AAA” compliant, it might cost the design (and the user) elsewhere to make it possible.
What does WCAG 2.1 say about contrast?
The WCAG 2.1 discusses the topic of contrast in accessible design in three sections. These sections include:
- Section 1.4.3: Contrast (Minimum) — i.e., “AA” level
- Section 1.4.6: Contrast (Enhanced) — i.e., “AAA” level
- Section 1.4.11: Non-text Contrast
The table below highlights all of the criteria described in these three sections of the WCAG 2.1 guidance. To clarify, “graphical objects” refers to things like photos and other images, and “incidental assets” refers to design elements that are not actionable and are purely decorational.
Bad contrast example: Mac’s calculator
Interestingly, although our visual systems can detect approximately 10 million unique colors, its ability to tell one shade of gray apart from another is much more limited. Contrary to research conducted decades ago, more recent publications say humans only perceive about 30 unique shades of gray before the small differences between them start to wash together (Kreit et al., 2012).
Furthermore, our ability to distinguish shades of gray diminish as the shades approach the extreme ends of black and white. In other words, we are worse at detecting differences between two very dark shades of gray, than we are at detecting differences between two medium shades of gray. With respect to design, this means that we need starker contrast differences to aid our perception and successful interactions with designs, especially dealing with the extreme ends of the grayscale.
Many designers and developers violate these rules of accessible contrast. And not just the small mom and pop shop designers either. For example, Apple doesn’t design every product with the best contrast. This seems strange given the company’s strong advocacy for inclusive design. Not to mention: products like their Voice Over (iPhone’s screen reader) is held is such high regard among many users with a visual impairment.
Nevertheless, take a look at the mac calculator.
Although it’s the same design as the calculator app you’ll find on an iPhone or iPad, one use-related factor in conjunction with one design-related factor can make the computer version inaccessible from a contrast perspective. Unlike the app-based calculator version, the computer version can be moved around the screen, and laid atop other windows the user has open already (i.e., use-related factor). However, this poses a big contrast issue given the fact that the top segment of the calculator has a subtle transparency in its design (i.e., design-related factor).
These two factors combine to make the Apple calculator have poor contrast on stark white backgrounds, and okay contrast when placed over darker backgrounds.
On a white background, the application’s exit, maximize, and minimize buttons in the top-left corner all but disappear (contrast ratio = 1.08 to 1). Windows users who are used to the opposite corner being home to these buttons will find this particularly frustrating, since the salient visual cues appear to be missing from the design. Second to this — and arguably a bigger hit to user performance — is the fact that the main display text also has not-so-great contrast with the background as well (contrast ratio = 2.92 to 1).
Lastly, the white text on orange buttons offers poor contrast, regardless of whether the calculator is placed on a white or black background (contrast ratio = 2.29 to 1). This is true in the app versions of the Apple calculator as well.
A few things improve from a contrast standpoint when the calculator is place on a black background. For starters, the calculator exit, maximize, and minimize buttons in the top-left corner are much more discoverable (contrast ratio = 7.97 to 1). The contrast of the main calculator display text jumps up considerable too (contrast ratio = 14.55 to 1).
Use-related factors such as this are important to think through across all of your users. As this example demonstrates, they can make your product difficult or impossible to use, if your design doesn’t mitigate the issue in some way.
Be careful with all-or-nothing thinking here though.
Apple doesn’t necessarily have to get rid of the transparency in their design. For example, they could incorporate a type of conditional design element based on the background color behind the calculator window; the design would be more transparent when the calculator is placed over a dark background, and more opaque when placed over lighter backgrounds. All the while, contrast would remain predictable and accessible for users.
Bad (and good) contrast example: iPhone’s airplane mode
A common design strategy to explain that an asset is currently disabled or unavailable is to show it in a low saturated, or grayed-out state. In regards to contrast, this design strategy can present some challenges to users with low vision. Often, users with a visual impairment that affects their contrast perception cannot see an asset in a disabled, grayed-out state. The contrast is just too low. As a result, these users may not be able to visually determine that this particular feature is an option in the system.
As an example, think of the “airplane mode” feature on the iPhone’s swipe up menu (aka: Control Center). When airplane mode is turned off (i.e., disabled), the button is a transparent gray. When it’s turned on (i.e., enabled), the button turns orange and opaque.
In regards to contrast, there are some surprising mistakes with this design.
On the positive side, in the enabled state, the contrast ratio for the airplane mode button meets WGAC 2.1 “AA” and “AAA” compliance. Remember, that unlike text that requires higher contrast ratios, graphical objects such as this only need to have a 3 to 1 contrast ratio.
But, in the disabled state, the contrast ratio fails to meet even “AA” criteria. In fact, it falls way short of the mark at a contrast ratio of only 1.65 to 1. Keep in mind, since this button design is moderately transparent, the overall button contrast in a disabled state is influenced by the user’s background image on their phone. Had the user chosen a different background, the outcome might be a little different.
In some ways though, Apple’s design does find a work-around to this issue.
Although the button itself has poor contrast with the background, the stark white airplane icon placed in the middle of the button is far more discoverable for users with low vision. That’s because the airplane icon has decent contrast from the button itself (i.e., contrast ratio of about 5:1).
So, even if the user cannot successfully perceive a difference between the button and the background, they might be able to tell the difference between the airplane icon and everything else in the background. Though this does make the interactive “target” size smaller — the airplane icon is smaller than the button shape — the user will hit the button by default, even if they somewhat miss the airplane icon target.
Final thoughts about contrast
There are many reasons why we allow poor contrast into our world of design. Some involve not knowing about the influence of poor contrast on reading performance, or the hinderance it places on those with a visual impairment. Others involve the need for creativity, and a desire to make your design stand apart from the black and white design world. After all, if you were designing text content on a website for hours on end, you would probably think of black text on a white background as vanilla flavored cardboard too.
The fact of the matter is that contrast is one of the most fundamental elements of accessible design. It’s a big part of what makes assets in a design “perceivable” by users — regardless of whether they have a disability or not. If your team is part of the Human Factors or User Experience (UX) community, and you’re producing content that violate basic contrast guidelines, you need to stop and ask yourself why. Sometimes just having the conversation with your team is enough to push them toward generating better, more accessible design.
About the Author
Joe O’Brian | Senior Human Factors Scientist | Research Collective
Joe O’Brian is a Senior Human Factors Scientist at Research Collective. He has co-authored articles on topics ranging from judgment and decision making to education and healthcare technologies. At Research Collective, his contributions include project planning, observational and biometric research, and advanced statistical analysis for major automotive and healthcare organizations. Joe can be found on LinkedIn here.