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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • tcertain

    I agree completely! Somewhere along the way, this was completely forgotten. Buttons and underlines are a universal language along with the ubiquitous [alt-text] that shows when no images are showing. Those who forget these in there design are only cheating themselves out of visitors.

  • Anonymous

    Interesting article. It is always good to think about global accessibility, and covering all your bases is important. You ultimately get to the fundamental point in the very last sentence of your article, that “we can’t rely on color *alone* to convey information”, and I think that would have made for a better title: “We Can’t Solely Rely on Color.” I was originally expecting a different kind of article when I first clicked the link.

    Regarding proper accessible design, I think more needs to be done to support that in standards and browser agent metadata. I personally do not believe it is appropriate to sacrifice good quality visual design, where color IS used as visual aids and cues, in order to support good quality accessible design. I think a far better accessible web world can be supported if we, as web designers, had the ability to DETECT what accessibility features a particular user required. Instead of always underlining links, for example, which can indeed destroy a beautiful web design (and not just in the modern world of flat, that can be the case in past phases of design that involve more visual and graphic complexity), it would be better if we could simply use CSS and other web features to selectively serve up versions of our page that include underlined links only when absolutely necessary. CSS, combined with perhaps an @accessibility rule that worked similar to the @media rule, paired with browser accessibility settings and UA flags, we could not only use the existing CSS accessibility features to solve these problems, but we could take it a step further and serve up pages for those with color blindness that underlined links, or pages for the blind that contained additional aural cues and text reader support, or those with impaired vision pages with much larger text and possibly a layout better suited to displaying a more useful amount of large-text content on screen, etc.

    Instead of calling for designers to sacrifice visual design beauty for accessible design, perhaps we should call for more support in standards and browsers for flexible disability detection and dynamic accessible design that wouldn’t interfere with our ability to still produce visually stunning web sites for the greatest majority of users.

    • brothercake

      Hmm well … I can sympathise with what you’re saying to some extent, but I also think it would be a slippery slope — it would implicitly encourage designers to think of accessibility as a “feature” instead of a base requirement.

      And there’s a reason why screenreaders don’t implement aural CSS — because screenreader users don’t want web pages to be able to control how they perceive content. You or I might think that a particular piece of text would be better in a female voice, or spoken more loudly, but it’s not up to us to decide that, because we’re not the users. We really shouldn’t have the ability to design the spoken soundscape, only to suggest such things through semantic markup.

      At the end of the day, user experience is more important than aesthetics, and web design is not art. Who is this design beauty actually for, if it’s not there to enhance the user experience? Branding? Artistic design? Such things are not as important.

      • Anonymous

        I think you have a fairly narrow view of what things like “artistic” web design and aural CSS extensions should be used for. I don’t disagree that usability, across the board, is a critically important factor.

        However, I think that things like Aural CSS can be used to good effect to create say something along the lines of an audible multi-person conversation for a story published online that a blind person could listen to with their reader. Without aural styles, such a web site would be read in a limited monotone, and would lack any of the nuances in an audibly read version that the author wanted to portray. A blind person is then getting a LIMITED experience, rather than the best experience they can given their disability.

        As for web sites not being art, that is entirely subjective. It depends on what the site is all about and who it’s for. In a corporate web site context, it is unlikely that the site itself is an artistic expression, however the web is not purely comprised of whitewashed corporate sites. It is entirely possible, and valid, for a site to be an artistic representation of an artist and their work…in which case the look and feel is just as critical as the usability (if not more so).

        I understand your arguments, but I think there is too much tunnel vision when it comes to discussions on this kind of subject. The web is an open platform, open to a near-infinite range of personalities and web site styles to go with them. As such, being able to control how a web page is spoken back to a blind user (certainly with the option for the blind user to disable designer-side control if they prefer), or calling a web design “art”, are just as valid and important as usability…in a general sense. Which ones are important and take priority really depend on the actual context and purpose of each specific web site…there is no blanket rule here.

        • brothercake

          You have to use the right tools for the job. In the example you’re citing, you wouldn’t do that with web technology at all, you’d get a person to record it and the user would listen to the audio. Perhaps one day synthesized speech output will match that quality of experience, but we’re many years away from that yet.

          You make some fair points, but you’re placing the producer ahead of the consumer. There’s a place for that, sure, just as there’s a place in art for alienating the audience, but most of use aren’t working on that kind of stuff.

          • Anonymous

            You use the tools that solve the problem you have *within the time and budgetary constraints you have.* If you have the budget, sure, you’d hire some people to record voices for you, assuming your primary audience is blind people. I’d counter that, assuming similar circumstances to the book author’s blog, you use the tools already available. Aural CSS is one of those tools. As I said before, there is no cut and dry here…its an open web, and there are often many ways to solve the same problem, none of them “invalid” per-se.

            Anyway, we obviously approach web design and development from different angles, so perhaps we should just leave it at that.

  • David Ford

    As someone with the red/green colour vision problems you mentioned – I agree.

    I have been told by support staff on numerous occasions “But it’s a big red button – can’t you see it?”

    I do find the ‘flat’ style more difficult to use – luckily I’ve been around since the beginning so I know we just have to wait for the pendulum to swing back.

    In the meantime a great many ‘modern’ web sites will not be getting very much of my time and patience.

  • Anonymous

    Disregarding the colour vision issue for a second, I’ve seen a lot of designs that I think lean too heavily on colour to communicate navigation (in particular). The colourised navigation in design can look great in a shell but then when you add content, colour images, banner ads and logos the page soon becomes a Where’s Wally of hues.

    Frequently in user testing I’ve seen that this adds a sense of confusion and detracts from the corporate colour pallet and branding. The awareness of colour coding also changes depending on whether the page was reached through a deep link or by navigating from another page, it’s not consistent and frequently overlooked.

    In providing indicators to end users on the structure or function of interactive elements I think its best in 9/10 cases to use form, tone and texture first and keep colour for adding interest, not informing the function in the page.

  • Tim

    This article could use some images.

  • brothercake

    I think you’re misunderstanding me. You seem to be responding as thought I’ve said that design can’t be artistic, but that’s not it at all.

    Design is not defined by style or content, it’s defined by function. That’s the difference between art and design — design has a function, art does not.

    The function of design is to solve a problem within constraints — those constraints are the very nature of design. And that’s why design is not art, because art has no such constraints.

    For example, the most left-field or experimental design would never render text in a 3pt font, because the text would be utterly illegible. You would never use the same color for both foreground and background, because users wouldn’t be able to see the text at all. Web design will always be constrained by its objective of allowing people to consume content.

    Your point about budget and time limits is fair enough, and I understand the use-case you’re describing. But I still think you’re making a false assumption — you’re assuming that the sound of spoken output is equivalent to the appearance of visual output — but that’s not the case.

    Spoken output to a screenreader user is like unstyled text to a sighted user, and as a sighted user yourself you can make decisions about what will work for a design without making the text illegible. But do you have that experience as a screenreader user? Do you have experience of navigating with screenreaders, and an understanding of the kind of user experience that people who are blind have with such devices?

    Very few people do, and could easily mess things up badly, even in the most well-intentioned way. And that in a nutshell is why screenreaders don’t support aural CSS; why it can’t be subject to the whims of design fashion.

    There is a use case for aural CSS, but it’s for speaking browsers, not screenreaders — it’s for devices that are designed to be used by sighted users, with speech that’s supplementary, or an aid to comprehension. The use case you described would be perfect for that, but it wouldn’t apply to screenreaders.