Library tutorials & articles

Accessibility for Web Developers

Guideline 2

Guideline 2: Don't rely on colour alone

Colour is an integral part of design, and using colours carefully can make the difference between a professional looking site, and an amateur looking site. It's sometimes unfairly claimed that accessible sites are dull. If you want to see examples of accessibility sites that are well designed, visit Accessify, and AnitraPavka.com. They're both extremely well designed, with accessibility in mind. Professional sites use colour sparingly. You don't need to grab the visitor's attention, as you already have it. They've visited your site, and usually just want the information in a clear and concise manner.

This guideline has 2 checkpoints, ranging in importance from Level "A" (essential for the site to be accessible), to Level "AAA" (beneficial to ensure the accessibility of your site).

Important - Priority 1 Checkpoint 2.1 Ensure that all information conveyed with colour is also available without colour

This checkpoint is a priority 1 checkpoint. It must be satisfied for your site to be considered accessible. Visitors who cannot differentiate between certain colours, or using a non-colour display will not receive information that is conveyed using colour only. For example, if you provide links that rely on colour only, colour-blind visitors, and visitors using non-colour displays, such as a PDA, won't see them. To overcome this, important information that relies on colour should contain some other form of context or markup to ensure it's conveyed to all visitors. In the case of links, you could use text-decoration, or maybe change the font weight to make links obvious.

a
{
    font-weight: bold;
    text-decoration: underline;
    color: #00c;
    background: transparent;
}

This checkpoint is by no means saying, "Don't use colour". Colour is useful, but you should ensure the information doesn't depend on colour. If your site lists vacations, and vacations in "red" are half price, your visitors may see red for completely different reasons than your design intended.

2.2 Ensure that foreground and background colour combinations provide sufficient contrast

This checkpoint is a priority 2 checkpoint for images, and a priority 3 checkpoint for text. The contrast between the foreground and background colour should be sufficient that visitors can read the text without straining. As you would expect, light colours on a light background, and dark colours on a dark background are not good choices. Colour-blindness is another consideration. There are many forms of colour-blindness; Protanopia (red/green colour blindness - no red cones), Deuteranopia (red/green colour blindness - no green cones), and Protanopia (blue/yellow colour blindness - no blue cones), including many grey areas in-between. It is advisable to try and avoid these combinations, as information could be lost to some of your visitors. To get an idea of how your pages look to a colour-blind visitor, you can view your pages through a range of Colour Filters.

A popular technique to ensure that colour is conveyed properly is to allow visitors to change the colours to suit their preference. This technique involves specifying your colours through several external style sheets. The style sheets are applied to the document in the <head> section of your code, using the <link> element.

The main style is given a "rel" attribute of "stylesheet", and the alternative style sheets are given a "rel" attribute of "alternate stylesheet". If the visitor's browser supports switching style sheets, they can select a style sheet to control their experience of your site. The visitor will see the name you provide through the "title" attribute. Most standard compliant browsers support this technique.

The following is an example of specifying a style sheet, with two alternatives.

<link href="main.css" rel="stylesheet" type="text/css" title="Standard" />
<link href="plain.css" rel="alternate stylesheet" type="text/css" title="Plain" />
<link href="yellow.css" rel="alternate stylesheet" type="text/css" title="YellowValue" />

For browsers that don't support style sheet switching, you can use JavaScript to switch the colours, providing the visitor has enabled JavaScript. A List Apart has a great tutorial for this technique.

Further Reading

Comments

  1. 08 Apr 2004 at 12:43

    My question is related to implementing Accessibility when using a datagrid, a datalist, XML, and/or a database.  All the info has been advocated in many circles and I would like to comply using ASP.NET and XML.NET.


    In many cases we are writing our ASP.net code to give access to data that is already in place and has been used for a considerable amount of time.  The biggest problem is that many databases and XML files are already set in place and we cannot change the data ( or the powers that be are unwilling to do so).  Likewise we are not in a position to add columns to the information in support of addressing Accessibility issues (for ex. a column for dynamic insertion of an ALT tag to explain images stored inside of the database, addition of supportive information (summary, caption, and scope) when tabular data is dynamically built from an XML data file as in


    <table width="90%"  border="0" cellpadding="4" summary="this summary">
     <caption>
     this caption
     </caption>
     <tr>
       <th scope="col"> </th>
       <th scope="col"> </th>
     </tr>
     <tr>
       <td> </td>
       <td> </td>
     </tr>
    </table>


    AND / OR a dynamically built link that usually would be <a href="http://www.here.com" target="_blank">go here</a>


    but really should be constructed as the code below for Accessibility reasons


    <a href="http://www.here.com" tabindex="3" title="A location to enjoy" accesskey="1" target="_blank">go here</a>


    So what can we do to increase Accessibility in these instances beyond adding to the XML or the database?


    Another issues to address would be in dynamic paging of a datagrid where the use of numeric or alpha characters are used to paginate through the data.

  2. 01 Jan 1999 at 00:00

    This thread is for discussions of Accessibility for Web Developers.

Leave a comment

Sign in or Join us (it's free).

Gez Lemon I'm available for contract work. Please visit Juicify for details.
AddThis

Related podcasts

  • Episode 15 Bug Review

    In this episode Matthew and Federico sit down to talk about some interesting bugs and lessons learned that our team has run across while testing ASP.NET. This is a different type of show that we are experimenting where the bugs take center stage.News *Silverlight 3 is releasedBugs Showca...

We'd love to hear what you think! Submit ideas or give us feedback