Colour contrast: There’s more to it than changing the colour of your text
According to WCAG, applying high-colour contrast means more than just changing the colour of text. There are various other elements requiring a change of contrast. For example:
- Icons should be distinguishable and clearly-visible
- The area of any button should be easily identified
Here, we’ll dive into some of these non-text contrast elements, outline the common mistakes made and suggest solutions using CSS.
Form controls
Form controls are ideally easily identifiable and easy to perceive.
Current design and development trends call for custom components and new user flow definition which means colour contrast is often neglected.
If we use neumorphism as an example here. And if you don’t know what that is, don’t worry, it’s s very digital design specific term which you can read about here. But without the definition, just look at this image. This has the potential to cause some accessibility headaches. Imagine the blur, size and intensity of the shadows on the buttons didn’t have enough contrast and users, therefore, could not identify the edges of the components.
WCAG tells us we must use a 3:1 contrast ratio for input indicators. This is curious because most browsers don’t have this set to default.
Insufficient contrast should be promptly addressed. A checkbox or custom radio button, for example, should show clearly the difference between an unselected and selected state. When the border offers a sufficient contrast ratio, a user with a visual impairment might still have issues differentiation the colour of the background from the colour of the selected item.
WCAG says a design may use flat design in the case where the status indicator fills a given component but doesn’t necessarily contrast with it.
You can utilise a flat design and have the status indicator fill the component without it contrasting the component. Here, it needs to contact with the adjacent colours of the component.
This is true for more than a classic form component. There are things like rating systems, toggle buttons, alert messages, loaders and toasts (to name a few) where each component needs appropriate contrast to indicate an obvious difference in their status.
To achieve this, colour contrast checkers can be utilised to ensure there’s enough contrast, borders are present and icons to indicate differences.
To do this, use the colour contrast checkers from the previous article, or try different techniques:
As we can see here, there is a great deal riding on the colour choice, background and borders regarding the accessibility of the component. This all translates into CSS.
Icons
Icons not having sufficient contrast is seen a lot. More, they do have sufficient contrast but only in states of the element containing them.
Using an inline SVG icon solves this. You can style them using CSS. Use SVG properties such as stroke
or fill
.currentColor
can also be used to manage the states of the inactive element without creating nasty code.
currentColor
is the value of thecolor
property, or if it’s not set, the inherited value. It ensures inline SVG icons will be the same colour as the text. If the text has an appropriate contrast, the icon will follow suit.
Graphs and Charts
JavaScript usually looks after graphs and charts, but you can display a chart using CSS. Admittedly, it’s not the best option available. If you do choose to use CSS for a chart or graph, ensure the colours have sufficient contrast with their background and the surrounding colours so the user can distinguish them easily.
That’s some food for thought for now. Think about how colour contrast isn’t solely a text consideration. Images, form controls, icons and other elements must also have sufficient contrast to be visible to all your users.
If you’d like to discuss a full UX or accessibility audit, contact us.