There’s a growing demand for designers to make their interfaces accessible to all users. It’s important to accommodate users with disabilities, but there are many myths to color contrast accessibility being perpetuated by misinformed people.

They often parrot these myths to discredit a design without understanding which situations a color contrast standard applies. Not only that, but they assume an interface is inaccessible whenever color contrast is used to convey information.

Designers often feel the need to obsess over accessibility because of this. They’re misled into believing their interface isn’t accessible when it actually is. This article debunks common color contrast accessibility myths and sets the record straight.

Myth 1: The WCAG requirements are always optimal.

The Web Content Accessibility Guidelines (WCAG) is used as the standard for determining accessible color contrast. However, these guidelines are not always optimal and applicable. Instead of following them blindly, you should examine how the color contrast standards measure up in practical application.

One case where the WCAG standards aren’t applicable is with the brightness contrast of white text. Both buttons below have a blue background, but one has white text, and the other has black. When you survey users on which button is easier to read, the majority will tell you the button with the white text is more readable (source). But the accessibility color contrast ratios tell a different story.

The contrast ratio for the black text is 5.41, which passes the requirement. However, the contrast ratio for the white text is 2.94, which fails it. According to the contrast requirements, the button with white text should be less readable, but it’s more readable.

A similar study comparing white and black button text confirms this finding. Not only did normal visioned users find the white text easier to read, but color blind users did as well (source).

This contrast inaccuracy seems to occur with white text on blue and orange backgrounds. The WCAG contrast ratios don’t always account for the high brightness contrast of white text. White is pure brightness with no hue or saturation, and brightness is the strongest form of contrast. Therefore, it makes sense why the button with white text is easier to read.

The reason the contrast ratios failed with the white text is that it has high brightness and is on a background with high brightness. Bright text on a bright background is rendered low contrast computationally. Your design is supposed to satisfy what people see, not computational algorithms. It’s why the designer’s eye should always play a part in the equation.

The WCAG are guidelines to help designers choose the right color contrasts. The adage, “The map is not the territory,” applies here. Don’t confuse models of reality with reality itself.

Myth 2: Text needs to meet the AAA requirement, or it’s inaccessible.

WCAG has different levels of conformance for accessibility. Some believe that all text must conform to the highest level of requirements (AAA), or it’ll be inaccessible to a large portion of their users. This notion is false and is evident when you understand how the AAA requirement was made.

The AAA requirement constitutes a contrast ratio of 7:1 to compensate for contrast sensitivity loss by low-vision users with a vision loss of 20/80 or more. Many of these users use assistive technologies that have contrast-enhancing features. They need this technology because they aren’t just viewing content on a single interface, but multiple. The AAA requirement only applies to 20/80 vision loss users who don’t use assistive technologies, which is few and far between (source).

A vision loss of 20/80 is rare among the general population and mostly affects the elderly suffering from age-related eye diseases. A study found that most low vision is related to aging (source). If the majority of your user base is 70 or older, meeting the AAA requirement is beneficial. The standard is 70 or older because visual acuity starts to decline among users with healthy eyes at that age (source).

Meeting the AA requirement is sufficient for the majority of users. The AA requirement constitutes a contrast ratio of 4.5:1 to compensate for the loss of contrast sensitivity by users with a 20/40 vision loss. A study found the “majority of persons maintain at least fair acuity (20/40 or better) into their 80’s” (source). This finding means that meeting the AA requirement will make your text accessible to the majority of users.

Myth 3: Interface components have the same contrast ratio standard as text.

Many make the mistake of holding interface components to the same contrast ratio standard as text when they are different. Interface components have a contrast ratio of 3:1, while text is 4.5:1. Text requires a higher contrast because users need to read it. Interface components don’t require reading and have a lower standard (source).

Many nuances affect text contrast, such as font size and weight. Large text sizes (18 pt) and text with heavier font weights (14 pt bold) require lower contrast ratios (source). Not only that, but certain interface components are exempt from the requirement. Before you hold an interface component or text to a contrast ratio standard, make sure you’re applying it correctly in the right situations.

Myth 4: Gray text and buttons are inaccessible and look disabled.

Another common myth is that gray text is inaccessible. Many assume users can’t read gray text because it looks low contrast. Sometimes this may be true, but other times it’s a false assumption. For example, the button below has gray text and some would assume it’s inaccessible. However, running it through a contrast checker shows that it’s not only AA compliant, but the ratio is well above the standard.

The other myth you might hear is that a gray button is inaccessible because it doesn’t meet the contrast ratio standard. It turns out the success criteria for buttons doesn’t require a visual boundary indicating the hit area. If a button with text has a border, there is no contrast requirement beyond the text contrast (source). Therefore, the gray button that most would assume is inaccessible passes the contrast requirement.

This success criteria also means that icons next to buttons don’t have a contrast requirement as long as the text label meets the 4.5:1 contrast ratio. However, if an icon is without a text label, the 3:1 contrast ratio requirement applies to the icon.

There’s also the myth that gray buttons look disabled, which is often parroted by biased observers who don’t understand the proper signifier for inactive components. Disabled buttons are signified by the lack of contrast to the text label. When a button is hard to read, users don’t bother with it, which is the intent of a disabled button. Not to mention, the contrast requirement does not apply to inactive components.

Myth 5: Color blind users can’t tell the difference between contrasting colors.

A common assumption is that if a design uses color contrast to convey information, color blind users won’t notice the difference. Color hue and color contrast are two different dimensions. Color blind users have trouble distinguishing specific color hues. They don’t have difficulty perceiving differences in color contrasts (source).

For example, many would assume the buttons below aren’t accessible to the color blind because it’s using color contrast to indicate different states. But the truth is that color blind users can differentiate the contrasting colors quite clearly. The buttons only use one color hue with no other competing and have sufficient contrast disparity.

By using a color blindness simulator, you can simulate what color blind users see. Users with a red-green color deficiency and blue-yellow deficiency have no trouble seeing the difference in color contrast.

Color blind users only have a hard time noticing color contrast when the colors are green and red, with nearly the same darkness (source). The example below shows what color blind users would see if the buttons were red and green with similar darkness.

If you’re using competing color hues to differentiate states, you need another visual cue besides color. But if you’re only using color contrast to differentiate states, it’s likely accessible to color blind users.

There are various types of color blindness, but the ones you should focus on the most are red-green deficiencies. Red-green color blindness affects more than 99% of all color blind people (source). There are several color blindness simulators you can choose from on Chrome extensions, such as Colorblindly.

Myth 6: Using a color cue alone isn’t sufficient in conveying information.

This last myth is probably the one that people get wrong the most. They’ll often cite the “Use of Color” requirement without recognizing when this standard applies. There are nuances to these standards you need to understand before you start using them willy nilly.

The accessibility requirement states that “color should not be used as the only visual means to convey information, indicate an action, or distinguish an element.” However, this standard only applies to cases where different colors are assigned specific meanings to inform the user (source). In other words, if you’re using color differences to convey information you need an extra cue. But if you’re using lightness and darkness to convey information, you don’t need an extra cue as long as the contrast difference is high enough.

For example, the toggle tokens below use a blue color to indicate the active state. But there is no specific meaning assigned to blue. The active state is conveyed through the color contrast, not the color hue.

The color hue for the active state is arbitrary. You could use any other color hue, and it would suffice as long as it maintains a high contrast level to the inactive state. As such, the “Use of Color” requirement does not apply to this scenario.

An example where color is assigned meaning is error states on form fields. Red is often used to indicate an error in a text field. In this case, red is not enough to indicate the error state because color blind users won’t see it. The red would appear black to them. Therefore, you need an extra cue, such as text or an icon, to indicate the error state.

Another example is using color to indicate system status on a page. The color hues green and red are often used to indicate the severity of system issues. In this case, the “use of color” requirement applies because specific meaning is assigned to the color hues. Icons are needed to help color blind users distinguish each system status.

Color contrast isn’t always the only cue at play when it comes to states. Visual depth is also a cue that users experience. It occurs when objects contrasting with the background appear closer and dominant, while objects that lack contrast appear further away and subdued. The blue button in this example seems closest to users. As a result, the emphasis and prominence signify the active state.

It’s from this play of contrast with the background that creates depth in the buttons and allows users to distinguish the active state. If both buttons had the same contrast level, users wouldn’t be able to perceive depth as a visual cue.

The Nuances of Color Contrast Accessibility

Understanding the nuances of color contrast accessibility will help you meet the WCAG standards accurately. When others project color contrast accessibility myths onto your design, you can correct them. You’ll stay true to visual simplicity and aesthetics while balancing accessibility at the same time. The result is an inclusive interface that satisfies everyone.