While all elements and components distributed within EOS Design System are thoroughly tested and WCAG 2.1 compliant, there will be times when you will need to make your own color choices for custom components. This guideline will help you keep those choices accessible.
Accessibility ensures that our applications are empathetic and inclusive of all different abilities including, but not limited to, visual limitations.
When choosing colors, take into account the contrast ratio between the foreground to the background color. The W3C created guidelines for this purpose (WCAG 2.1). These require that text uses adequate contrast for visually impaired people.
The WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text (14px) and 3:1 for larger text (~18px). Tools like contrast-ratio.com will help you check the contrast ratio between two colors.
Color contrast in components
Components don’t need to comply with AA standards for color contrast (4.5:1), but text does. This means that if you have a light gray button background with a contast ratio of 2:1, but a text within it has a color contrast ratio between its background and the text color of at least 4.5:1, the button is accessible as it turns out the success criteria for buttons doesn’t require a visual boundary indicating the hit area.
This success criteria also means that icons within buttons with a text label don’t have a contrast requirement as long as the text color 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.
To learn more about how to use icons in accessible components, go to the accessibility page for icons.
Color contrast rules do not apply to disabled components using the appropriate
disabled attribute. Assistive technology will successfully skip all disabled components.
Conveying information successfully
Colors should not be used as the only visual means to convey information, indicate a state, or distinguish an element. If you’re using color differences to convey information you need an extra cue, however, 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, in the following example the toggle component conveys its state only trough color hue. As you can see in the graphic, 3 different types of color blindness will hardly recognize the difference between active and innactive states.
To make this component accessible we must consider using contrast as a differenciator or use a visual indication:
A tipical example where color is assigned meaning is error states on form fields. Red is often used to indicate an error in an input field. However, using red is not enough to indicate the error state because color blind users won’t see the difference. The red would appear black to them. You need to add an extra cue, such as text or an icon, to indicate the error state.
Color blindness simulators
Our design system delivers accessible tested components with usage guidelines and recommendations, however, there will be times when applications will require to build and design their own components. For these scenarios, it is important that you consider all the points mentioned above, as well as our guidelines for a11y. Additionally, to ensure the correct usage of colors and contrast, we recommend using Color blindness simulators that will enable you to experience the impact or the color choices you make.
- Chrome extension: https://chrome.google.com/webstore/detail/colorblindly/floniaahmccleoclneebhhmnjgdfijgg/
- Firefox built-in accessibility
The simulator included in the Accessibility Inspector in Firefox Developer Tools allows to test what applications look like to users with various forms of color vision deficiency, as well as contrast sensitivity loss.