We Can’t Rely on Color

A recent article by Georgina Laidlaw on the flat UI design style got me thinking about the accessibility implications of this trend, and especially how it affects the use of color to convey information.

So I thought it would be useful to review these implications, have a look at the accessibility requirements regarding the use of color, and discuss some of the ways in which we can meet them.

The accessibility of color information

There are actually two different principles in WCAG 2 which address the use of color to convey information. Each of these principles affects a different group of users, and is catered for in a different way.

People who can’t see color differences

The first group of affected users is people who can’t see color differences, but who can see other kinds of visual information (Principle 1.4.1):

• People who have a form of color-blindness that means they can’t differentiate certain colors, such as red from green, or blue from yellow.
• People who override page styling for accessibility reasons, such as disabling author colors and fonts, or applying a high-contrast stylesheet.
• People who are partially-sighted may have limited color-vision, finding it difficult to distinguish similar shades, or similar color intensities.
• People who are using a monochrome display, like a low-end e-book reader (although arguably this falls outside the realm of pure accessibility).

We can cater for this group of users with color-agnostic visual cues — such as icons, arrows and bullets, text effects like bold, italic and capitalisation, and of course, using text itself and the context of text to convey information.

For example, a while ago I produced a data table to document when elements take the focus, and I used red, green and orange to indicate positive, negative and conditional results. But the colors were not the only thing that conveyed this information, as the cells also used letter-codes to convey the same data. So users who can’t or don’t perceive the colors will still get the information.

Another, far more common example, is the way that form validation errors are typically presented — using red to indicate an error, but also bold or italics (or both) to visually emphasise the message, and often a prefix such as ERROR: to indicate its meaning. The location of the message also conveys information — adding it directly before an <input> so it obviously applies to that.

So this principle doesn’t mean that color can’t be used to convey information at all, it simply means that color cannot be relied on as the only way in which visual information is presented.

Even for users who are color-blind, and who see (for example) both red and green as a kind of browny-black, it is still possible to use these color combinations if the contrast between them is sufficiently high. So a very light green, for example, would be easily distinguishable from a very dark red, for people who are color-blind or when viewed in monochrome.

People who can’t see at all

The second group of affected users is people who can’t see any visual information (Principle 1.3.1):

• People who are blind and navigate using a screenreader, Braille reader, or other access technology.

We can cater for this group of users with semantic information — using the correct markup, adding roles and other ARIA attributes where appropriate, and (as with the previous group) using text itself to convey information.

To look again at the examples from the previous section — the data table is marked-up as a <table> with <th> elements for headers, which have scope attributes to indicate the row or column they refer to. The table also has a summary attribute, despite this being obsolete in HTML5, because the specification misunderstands the meaning of this attribute. (The summary describes the structure of the table purely for the benefit of screenreaders, whereas the <caption> describes the content of the table for the benefit of all users; a data table should have both — the specification is wrong.)

For form validation messages, the use of <strong> or <em> provides semantic emphasis, while the location of the error conveys a loose association (and of course the message itself describes the meaning). But it’s also a good idea to add aria-invalid="true" to the <input> element, and also add aria-describedby to point the message element’s ID.

Suffice it to say that semantic markup is the key to screenreader accessibility, particularly the use of headings and sections to create a logical structure, and choosing elements according to what they mean (i.e. if it looks like a button and clicks like a button, then it should be a <button>).

The pitfalls and potential of flat design

Some of the strongest visual cues that we’ve been using for many years, are now being lost in the flat UI design trend. The use of depth effects on buttons to clearly differentiate them, the use of text-shadow to improve the contrast of text on a colored background, even the humble underline on links is falling out of fashion (again) — but color alone is not enough to indicate their function (which is why I personally believe that link-underlining is sacrosanct — far too important to be lost to mere aesthetics).

What concerns me is that we’re throwing away design components which actually served an important purpose — powerful and well-understood visual cues, like borders, bevels and shadows. A design response to this will inevitably be more reliance on color and typography, and this in turn might lead to more accessibility problems.

There are also places where usability impacts on accessibility, especially where people with cognitive disabilities are concerned. The biggest problem with many of the flat designs I’ve seen, is that it’s harder to identify which are the interactive elements. And if I find it tricky (as a person who doesn’t have a cognitive disability), then for someone who does have such a disability, it could be very much harder.

Although there could be a positive flip-side here, and the potential for this design trend to improve accessibility — since flat designs tend to use larger fonts and simpler icons, both of which are of benefit to people with cognitive disabilities. And if exploring the flat aesthetic forces us to re-invent common visual cues, then the ultimate result could be a better, simpler set of conventions. It might take users some time to understand them, but all good things take time.

So far be it from me to tell designers what they should do, or to assume that this trend will inevitably lead to poor accessibility; I really just wanted to re-iterate and explain this important principle — that we can’t rely on color alone to convey information.