AUTHOR’S NOTE – You’re reading the HTML version of a chapter from the book Building Accessible Websites (ISBN 0-7357-1150-X). Copyright © Joe Clark, 2002 (about the author). All rights reserved. ¶ Back to Contents
Reading is the primary activity of the Web. For people with impaired vision who do not use screen readers, colour choices and, to a far lesser extent, type size become the accessibility issues.
The big surprise is how little work you must do to provide for big type on your Websites (in fact, no work at all for the group that truly is visually-impaired). Along the way, you will learn more than you ever thought possible about colourblindness. And that is where we’ll start.
In this chapter:
As we are all too aware, a perennial objection to making Websites accessible comes in the form of a reflexive bleating from Web designers per se: “What, I can’t use graphics? You want I should make text-only sites? What is this, 1994?”
Accordingly, when I mention that you will have to take some care in selecting colours throughout your site, certain of my esteemed readers will immediately object: “What, are you saying I can’t design now? Are you saying I can’t use photographs?” and close this book in disgust.
Um, no. Go ahead and use photographs, assuming you include the appropriate text equivalents. The colour values of any particular photograph (or illustration, for that matter) are outside the purview of accessibility.
However, colours used elsewhere on your site must be selected with modest care. You don’t have to go to extremes, and it won’t take you more than a moment to decide what to do, particularly since this book and its included CD-ROM give you all the tools you’ll need. You will, moreover, be an expert by that point.
Our goal here is to make sure that everything expressed in a foreground colour that must be differentiated from a background or adjacent colour actually can be so differentiated. In practice, we’re largely talking about typography, though icons, buttons, and large colour-filled expanses of a Web page are affected, as are combinations of typography and image (e.g., the word “Next” alongside a right-pointing arrow, or “Home” plus an outline of a house).
The assumption is that you as a designer will never have cause to use invisible text (foreground and background colours the same). That’s barely worth mentioning, though you may recall the discussion of using invisible text for navigation-skipper links in Chapter 8, “Navigation.” What we find far more often, though, is an unwise choice of foreground and background colours. Those of us who look at Websites have all seen it: Yellow type on white, or dark blue on slightly lighter blue. In rare cases, complementary colours, like red text on green, scintillate on the screen.
I will not pass judgement on these æsthetic lapses. The concern here is legibility. If, however, you do select colours for legibility, you stand a fair chance of being in good taste, if that even matters.
The term is a misnomer: Few of us are achromats who are unable to see colours at all. (Oliver Sacks’ book The Island of the Colorblind [Knopf, 1997] describes an unlikely community of many such people.) This book does not deal with that surpassingly rare group.
In practice, colourblind people confuse certain ranges of colours. The issue is nearly always colour discrimination or colour differentiation – that is, telling two colours apart (detecting that they are different). The issue is not identifying colours by name, though people with colour-vision deficiency are often able to do so, even for colours they cannot actually see, because they have learned what objects are what colours throughout their lives.
But to reiterate, you must understand colourblindness as a problem of differentiating colours, not one of colour disappearing.
Colourblindness is not an equal-opportunity disability. Virtually everyone with colourblindness is male. The measured incidence of colourblindness varies by country and race, being most common among white males. The proportion of people in the Western world with any detectable colourblindness is usually quoted at 8%. Incidence in males hovers around 4%.
If your Website attracts a mixed male and female audience (most do, but realistically, a great many sites attract vastly more men than women or, rarely, vice-versa), you can estimate the proportion of your audience that is affected.
As usual, we are dealing with minorities here. You should not jump to the conclusion that, since the number of visitors with colourblindness may be 4% or less (assuming a fifty-fifty split between the sexes and a predominantly white readership), doing any kind of work to accommodate them is a waste of time or provides diminishing returns. If that were really the case, we wouldn’t pay any attention to Web accessibility at all, because you would have to search high and low to find a site where a majority of visitors were disabled, which presumably would be the threshold at which accessibility would suddenly be worth it.
In fact, colourblindness is an easy disability to accommodate. It demands almost no special coding, usually requiring nothing more than intelligent and informed colour choices.
If you’re old enough to be doing Web design, you’re old enough to know that the retina is the light-sensitive lining of the eye, usually described as sitting at “the back” of the eye. In fact, the retina extends in three dimensions over most of the inside surface area of the eye. The retina really is a lining and is not at all like the screen of a drive-in movie theatre suspended at “the back” of the eyeball. If you dissected an eye in half from left to right, you would find a certain area lined with retina cells even in the front half.
You will likely also be familiar with rods and cones, the two main categories of light-sensitive cells in the retina. The names come from the approximate shapes of the structures. Rods, which are far greater in number (typically over 100 million per eye) and are concentrated in certain areas, are almost completely insensitive to colours and react mostly at low light levels. It is not the case that cones detect colours and rods detect grey, black, and white; cones (fewer in number, at about 8 million per eye) need more light to actuate than rods do. Rods do well at low light levels, cones at high light levels. There is a considerable range of intermediate light levels where both rods and cones are active. At high light levels, rods are overwhelmed.
The reception of colour depends on pigmentation of the cones. It certainly surprised me to learn that cells in the retina could carry pigment, but cells in the skin and hair (and the iris, the coloured part of the eyeball) carry pigment, too, and that isn’t particularly surprising.
(To keep rods and cones straight in your mind, remember the mnemonic of C for cones and colour.)
We see a rainbow of colours due to the activation of more than one kind of cone cell. Colour vision is additive: Different wavelengths of light combine to form the millions of hues detectable by a person with normal colour vision.
Through hereditary bad luck, and in rare cases through disease or exposure to toxins, some men and a very small number of women live with a colour-vision deficiency.
The technical terminology describing the various forms of colourblindness is tongue-twisting, confusable, and heavily Latinate. The lexicon takes a while to settle into understandability, but you absolutely must learn the various forms of colourblindness by name to make intelligent colour choices in Web design.
To make things easier, we should start with some general facts.
There are two main categories of colour-vision deficiency: One attributable to completely absent pigments in the cones (“anopia,” or “anopic” deficiencies), another due to abnormal or “anomalous” pigments.
The three main varieties of colour-vision deficiency are protan, deutan, and tritan. You may notice from the roots of the words that they refer to the numbers one (prot-; think of “prototype”), two (deut-; equivalent to “deuce,” which anyone who’s ever played cards will know), and three (trit-; think “triple”).
The conditions themselves (as opposed to the higher-level theoretical categories) are usually called protanopia, deuteranopia, and tritanopia.
The terms refer to an insensitivity to light in the long, medium, and short wavelengths, respectively. To a person with normal colour vision, that translates to an insensitivity to red, green, and blue, respectively, in broad and somewhat inaccurate terms. (There is some overlap in colour wavelengths and perception, as you will likely know from arguing with friends over whether a colour is bluish green or greenish blue.)
Keeping protan, deutan, and tritan straight in your mind will not be that difficult if you think back to RGB colour. The acronym is always expressed in that order, not GRB or any other permutation. In fact, acronyms like RGB and CMYK roll right off the tongue.
If you can remember and RGB and 1-2-3, you can remember protan, deutan, and tritan. Even before defining the terms fully, then, you have a range of mnemonics to keep them straight:
In both protanopia and deuteranopia and their related conditions, red and green are the colours that are confused. You get the two groups as a package deal: If you accommodate someone with red–green deficiency, you accommodate people with protanopia and deuteranopia, because their colour experiences are similar.
Why do these groups have problems differentiating red and green? It has to do with the cone cells. To distinguish red from green, the brain relies on the difference in stimulation of medium- and long-wavelength pigments in the cones (broadly analogous to stimulation of greens and reds, respectively). We’re talking differences here, and to detect a difference, you need more than one item to compare. If your cones are insensitive to medium or long wavelengths (if you’re missing one of those receptors), then you do not have a pair of input stimuli to compare. You cannot draw a distinction between the two because you have only one to work with.
Red–green deficiencies fall under the following categories.
A person with protanopia is a protanope or a protan.
Protanopes cannot distinguish reds and greens; reds, moreover, appear dark.
If you’re missing long-wavelength pigments in your cones but you have medium-wavelength pigments, you’re a protanope. Those medium-wavelength pigments are not very sensitive to long wavelengths (the reds), so the hues that colour-normals would describe as red do not look red and seem dark compared to other colours that are actually equally bright.
This brightness deficiency will come up in practical use, so keep it in mind. (You can compensate for it by simply making the colour brighter.) Since most colourblind people are men, the following joke, a stock in the colour-vision trade, is not actually sexist: “The protanope wears a red tie to a funeral.” Red and black can look the same if the red is dim enough.
A person with deuteranopia is a deuteranope or a deutan. (Note that the terms are not parallel.)
Deutans, like protans, cannot distinguish reds and greens. Unlike protans, though, there is no brightness deficiency. Hues that colour-normals would describe as red do not appear red to a deutan, but they don’t appear darker than other colours that are actually equally bright.
There are more deutans than protans in the world.
If protanopia and deuteranopia are a kind of pure or undiluted colour-vision deficiency, we also find colour deficiencies that are not necessarily as severe in practice but are still related to the main deficiencies.
As you can see, protanopes, deuteranopes, the protanomalous, and the deuteranomalous all vary in red–green vision deficiency only in details.
In building accessible Websites, you may consider all these groups roughly comparable (with the notable exception of darkened red sensitivity in protans). If you accommodate one of those groups, you accommodate all of them.
A significantly rarer colour-vision deficiency is tritanopia.
Tritanopia is not exactly analogous to the red–green vision deficiencies; though it involves blue, it does not constitute a blue–yellow deficiency. Tritanopia is analogous to protanopia and deuteranopia in that blues and greens are confused.
Tritanopes or tritans have no sensitivity to short wavelengths, broadly equivalent to blue. Tritanopia is quite rare in its hereditary form, but some diseases, including diabetes, induce tritanopia in people who formerly had normal colour vision; among elderly people, “acquired” tritanopia is more common than the hereditary kind.
There is no such thing as tritanomaly. There are no anomalous tritanopes.
Red and green are not the only hues affected. Some researchers believe that people with red–green colour-vision deficiency actually see shades of beige, yellow, or orange in place of red and/or green.
No one can be sure of what another person actually sees. Joel Pokorny of the University of Chicago, a leading scientist in colour vision interviewed for this book, was extremely reluctant to speak even in general terms about what hues colourblind people actually perceive, but the theory that red–green deficient people see beige/yellow/orange is not in wide dispute. The strongest evidence for this theory comes from the spectacularly rare group with one normal and one colourblind eye. With these subjects, it is possible to display colours to one eye and then the other, ask questions about colour differences, and draw inferences as to which colours are confused based on the subject’s responses.
Here in the real world, however, beige, yellow, and orange are also used in and of themselves.
It follows, then, that hues a colour-normal person would describe as beige, yellow, or orange hues a colourblind person could actually confuse for red and green. Why? For the simple reason that red and green are perceived as those other shades. “True” beige/yellow/orange can be confused with “false” beige/yellow/orange.
The range of hues you have to be concerned about, then, is actually pretty wide: Red, orange, yellow, beige, and green.
You now have quite enough technical knowledge about colour-vision deficiency to stultify acquaintances at dinner parties.
How will it affect your work in building accessible Websites?
Somewhat less than you might expect, actually, though you are not off the hook and you are not in a position to ignore the phenomenon altogether.
Recall that colour-vision deficiency concerns differentiating or discriminating between colours. That means making a comparison. Online, that further means making a comparison in cases where actual meaning is involved.
In accessibility terms, it is of no interest that a colourblind person might see a solitary block of colour on your page as something other than its intended red, green, or other confusable colour. Hues perceived in isolation, with no meaning attached to them, are neither here nor there.
Broadly speaking, then, it follows that photographs are exempt from accessibility considerations for colourblind visitors. The fact that a colour-deficient person doesn’t see a photograph the way a colour-normal person does is largely irrelevant.
If, however, we are dealing with the rare case in which the whole purpose of the photograph is to differentiate one part from another, and those parts appear in confusable colours, then we have a problem. Actual examples of such photos are rare, even contrived. I suppose a photograph of a traffic light at an accident scene (with red and green illumination) is one such case, or a discussion of colours for exit signs inside buildings (red, blue, and green are all variously used worldwide), or maybe a shot of a row of otherwise-identical products differing only by colour, where red happens to be handy to green.
In any event, no accessibility guidelines anywhere suggest you doctor your photographs so that confusable colours are no longer confusable, and I’m not giving you that advice, either. Some accessibility provisions incur undue hardship or fundamentally alter the nature of the enterprise. The colour characteristics of photographs, in general, fall into that category.
(A clear exception: Type or navigation icons laid on top of or close by a photograph. Such items definitely must take colour-vision deficiency into account even if the rest of the image as a whole does not.)
So what do you have to worry about?
On the Web, you have to worry about colour-vision deficiency when a meaningful object is on top of or near another object and the colours involved are confusable.
What is a meaningful object?
There may be other such items. The salient test is: If I confuse this item with something else, will I make a mistake? Will I be unable to do what I want?
By contrast, graphic design used for its own sake or for beauty, effect, or appeal need not be adjusted for colour-vision deficiency. In these cases, you need not do anything special. If the text of your page occupies two-thirds of the screen, and the text is definitely unconfusable by a colour-deficient person (e.g., black text on white), but you did a nice design treatment at the left and top that uses red, green, or other confusable colours in an artistic way, you’ve got nothing to worry about, if that design treatment carries no meaning.
Graphic designers must separate their own responses from those of the rest of the world and acknowledge that emotional impact, sensations of pleasure, and artistic appreciation are not the same as meaning in this context. You may think it’s important. It is not necessarily meaningful according to the definition we are using here.
The two phenomena may intersect. You may indeed have to change the colour of your text to make it unconfusable even though design elements on the very same page may stay untouched.
Only meaningful objects on the page need to be unambiguous.
You may alter other colour schemes out of the goodness of your heart, but nobody’s expecting you to do so. Remember, we are not in the business of exactly duplicating the nondisabled experience for disabled visitors. Colourblind people can put up with seeing a site in a way the designer did not intend. What they can’t put up with is not being able to use a site.
(And while we’re on that topic, you know already that colour fidelity is an impossibility online. Ensuring that the specific shade of yellow you used in that swath of screen real estate remains that specific shade for all visitors cannot be done. Apart from the colour-gamut differences between Macintosh and Windows machines, colour bit depth can and will sabotage your colour choices; take a look at your page in 256- or 16-colour mode for a taste of this parallel universe. Colours aren’t even consistent across a single monitor, a phenomenon quite apparent to anyone staring at a liquid-crystal display all day. Colour-deficient perception of objects that are not per se meaningful is yet another colour inconsistency we can add to the list.)
Applying these principles is easy. Keeping in mind that colour-vision deficiency deals with comparisons, you always have to think in groups.
When considering two items, is the first on top of the second? Or right alongside?
With three, five, or more items, what forms of adjacency and overlap are you dealing with?
When considering these comparisons, here’s what you do not want to do. These prohibitions may seem excessively broad, but we will return to qualify them shortly.
Is this unnecessarily restrictive? Am I taking the fun out of Web design?
Am I asking you to stop smoking and stop drinking? In the immortal words of Adam Ant, “You don’t drink, don’t smoke – what do you do?”
What you do is use your head. No, you may not use red/black or red/green combinations, nor may you mix them with beige/yellow/orange, unless:
As you can see, your true limitations are modest, but you do have to make intelligent analyses of the colours on a page.
You cannot get away with using confusable colours while expecting that other features, like a title, longdescription, JavaScript rollover, or status-line message, will save the day and resolve the ambiguity.
First of all, if you’re using JavaScript rollovers, all states must be unconfusable. Note that this means that all states may use confusable colours if, as in the previous examples, the type or foreground information is perfectly readable against any and all backgrounds.
(I’m saying “all states” here because it is possible to use an animated GIF as one of the states of a rollover. Animated GIFs contain a series of states unto themselves. Just as we can place tables inside tables or lists inside lists, graphics inside graphics must all maintain the same level of accessibility.)
It is bad usability and certainly bad accessibility to force people to scrub the mouse all over the screen until the cursor changes into a link indicator because they have no other way of finding the links on the page. It is no less illicit to force people to wait for a rollover or a tooltip or a status-line display (very easy to miss) merely to understand what the hell an item is for.
(Fine-art and experimental sites do not have to be dumbed down. You may force the visitor to work to discover the page’s links and other intricacies as long as a colourblind visitor is no worse off than one who isn’t. If, on an artistic or experimental site, everyone is “disadvantaged” equally in broad terms, there is no inaccessibility in broad terms.)
Adding such metadata is always a good idea, but don’t rely on it to absolve you of responsibility for colour choices.
You now must carry a certain yoke as a Web designer. You now know that some colour combinations should be avoided under many conditions.
But since colourblindness follows well-known patterns, it follows that certain colour combinations are A-OK for everyone, right?
The answer is yes. Before delving into the matter, though, keep this important point in mind: Not all Websites use confusable colours, and even those that do so do not necessarily use them in confusable ways, what with the various other measures at our disposal. If, however, you wish to maximally avoid colour confusions, you have a range of colour choices at your disposal.
As it turns out, there’s an impressive body of work available on colour choices for maps that is perfectly applicable to the Web. The lead author for most of this work is Cynthia Brewer of Pennsylvania State University.
Professional cartographers do not use colour merely as a differentiator; specific colour choices and intensity correlate with actual data. Online, though, colour is used mostly for differentiation. If researchers have pinpointed colour choices that work under the arduous demands of professional mapmaking, those colour choices are certainly going to work for Web design.
These findings (citations are found in the Bibliography) give us two sets of guidelines:
If you have to differentiate two items clearly, you may use one of the colour pairs. If you need to differentiate a related range of items, you may use colour steps. (Online, with its reduced resolution and general difficulty of reading, you will want to provide redundant coding, relying on more than just colour. But you knew that already.)
It gets better. A problem related to colourblindness that affects everyone with any kind of colour vision is colour naming. People disagree on what to call certain shades. But experiments have shown that you can always find a range of shades that all subjects call by the same basic name (like red or blue or green as opposed to pink or turquoise or puce). The colour lists that follow are verbally unambiguous: What one person calls blue no other person will ever call brown.
For our purposes here (a fact confirmed with Brewer), the specific red, blue, or green you pick does not matter. Do not, however, tempt fate. Don’t get fancy. Do not take this to extremes by selecting a hue that your better judgement tells you is really pink or turquoise or puce. Stick to shades that you have no doubt whatsoever can be described by the words in question. If you want red, pick a red; don’t think too hard about it. Nearly everyone else who can perceive red will also consider it red. Interpret words like dark, medium, and light similarly.
Listed below, then, are colour pairs and colour steps that are safe for people with colour-vision deficiencies and whose names are also unambiguous.
Why is yellow special? Brewer explains: “Sequences of lightness steps are difficult to produce with yellow because basic yellow is a light colour and dark saturated yellows cannot be produced.”
There’s a B-list here. Brown/yellow and yellow/blue combinations are available. But under certain very severe conditions found in specific maps but not in real-world Websites, brown/yellow and yellow/blue pairs can be confusable. Of course, we are building accessible Websites, not accessible maps, so I have Cynthia Brewer’s blessing to tell you to use the following colour pairs as much as you like.
We all know about the Web-safe palette of 216 colours that are more or less equivalently rendered on different platforms. Should we go out on a limb and call Cynthia Brewer’s list the colourblind-safe palette? How about the Brewer palette?
In any event, not every Website will require specific work to avoid confusable colour combinations. But if your site is one of those, now you’ve got six colour pairs and 32 colour increments to play with.
And playing with them is exactly what you should do.
The idea here is that, if you absolutely must use adjacent navbar buttons or something of that sort, you can ensure that they are differentiable by colour alone through the use of these well-tested pairs and increments. You will also enact other measures, like legible foreground coloration, borders, separation, and metadata. But these safe colours put you on a very firm footing.
Nobody’s forcing you to use these colour steps exactly as listed, of course. They can be useful to you even if you don’t have groups of exactly six or four items to differentiate. You can skip increments: Dark red, then light red, then medium blue could differentiate three items. Do you have six items? Enjoy the variation of using the dark-red/light-red/medium-blue step twice in a row. (Why not? That puts dark red and medium blue next to each other, and they aren’t confusable.)
It is ill-advised to jump from pair to pair, however. The pairs are like DNA strands; do not let yourself play Dr. Frankenstein and recombine the DNA. Every one of these pairs contains blue. Remember learning that nearly everyone can see blue? Well, let’s not try to ride that detail too far. If you mix and match, what are you going to be left with? Blue and blue? Red and orange? Red and purple? Red and brown?
Yellow isn’t so great either if you try to extract it from one of the pairs above and use it inside another pair. Red and green are perceived as something akin to yellow by deutans and protans. If you use actual yellow as understood by colour-normals, you run the risk of having it confused with red or green.
Should these guidelines nonetheless cramp your literal and figurative style, keep a few things in mind:
White, black, and grey are perceived as such by pretty much anyone on the planet with functional vision (even those surpassingly-rare achromats). Those colours can provide a useful contrast against millions of other shades (and, in one combination or another, with all 216 Web-safe colours). You can mix white, black, and grey with confusable colours if the results, given foreground/background combinations, contrast, and other factors, are actually unconfusable.
You can even use black and red on the same page: Red type on white, white type on black, and white or red on top of each other in either combination.
And to reiterate a previous point, you can use confusable colours all you want if the confusion has no impact on the meaning or function of the site.
There is a small detail: For various physiological reasons, grey actually does become a confusable colour in some unusual combinations, as in the colour triplet magenta–gray–cyan. Now, when was the last time you used that combination? Grey confusability is unlikely to come up very often.
If you have normal colour vision, these discussions of colour-vision deficiency are rather hypothetical. How do you apply your knowledge in the real world?
Well, colour-normals require simulators to approximate the appearance of Websites as perceived by the colourblind.
A word of warning: Looking at your pages in greyscale mode is not an adequate simulation of the experience of colourblindness. None of the groups discussed in depth here – protans, deutans, and tritans – sees the world without colour (as the very uncommon achromats do). Greyscale simulations are not bad as a tool for checking contrast levels, but you’re checking contrast in the absence of colour, an unnatural condition for the groups you are trying to accommodate. I must have read a dozen instances of the advice “To ensure your site works for colourblind people, evaluate it with a black-and-white monitor” while researching this book. It doesn’t work, and there is pretty much no such thing as a black-and-white monitor on First World computers anyway. It is usually impossible even to reset a colour monitor to greyscale. You should discount this advice altogether.
The Web Accessibility Initiative Web Content Accessibility Guidelines are blunt when it comes to colour: “Don’t rely on colour alone.”
That guideline goes on to say:
Ensure that text and graphics are understandable when viewed without color. If colour alone is used to convey information, people who cannot differentiate between certain colours and users with devices that have non-colour or non-visual displays will not receive the information. When foreground and background colours are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of colour deficits.
On the face of it, if you have no particular knowledge of colour deficits, this sweeping prohibition does seem like a party-pooper. I suspect designers are misreading the guideline as “Don’t use colour.” That’s not the intent.
There is certainly some debate as to what the intent actually is. It appears to mean “Don’t use colour by itself to convey meaning.”
At this point, we could pretend we were philosophers of art and launch into a discussion of the way the associative values of colour (red means blood, passion, also stop; green means grass, calm, also go) are a form of meaning, if you feel like stretching the term. Let’s not.
I would suggest coming back to the test of colour confusability: If I confuse this item with something else, will I make a mistake? Will I be unable to do what I want?
In the case of colour-deficient vision, we considered colour combinations – pairs, triples, and beyond. The guideline as written appears to force us to consider colour in terms of single objects. In reality, we are nonetheless meant to draw a comparison – between an item in a certain colour and another item with a different meaning.
The most common example of use of colour “alone” will clarify that there is really no such thing as using colour alone. I speak of financial tables, where negative numbers may be printed in red. (“Red ink,” as they say.)
Red differentiates the number from a positive figure. A comparison is in fact being made with such positive figures, even if none exist on that page.
Take another example found online: If you make a mistake filling out a form, a Website may bounce you back into that form with the defective fields marked in red. You can disregard all the other fields, and to do so you draw a comparison with them.
Having spent a great deal of time wracking my brain on this topic, the only other case I could find involves dumb-arse Geocities-calibre Web “designers” who tell you “Click the green square to enter! Click the red square to exit!”
They’re both squares, so a comparison based on shape won’t help you. Apart from hovering over the images or otherwise inspecting the target filename, you have no particular means of telling the two apart other than colour.
In these specific cases, you must adjust your approach. You must make visible changes to your design in order to make it accessible. The groups involved here aren’t merely the colourblind but also screen-reader users, anyone with a text-only browser, or a visitor using a monochrome display (not that there are many of those left in the world).
− or −. Also, – or – will do in a pinch, though it’s not the same.) Use the appropriate typographic formats for your language and region; a minus sign may trail the number, or parentheses may not be permitted, as the case may be for different languages.alt text like Alert, Error, Correction needed, or Attention. You could even use an asterisk or exclamation point if you absolutely must, but some screen-reader users will miss those unless they’ve selected a setting to read every punctuation item. Or just add explicit, normal, everyday HTML text containing the warnings. You can also use stylesheets or HTML elements like <strong></strong> to emphasize the type, or you can draw a border around the field or a background behind it. (Watch for colour confusions.) Add however many levels of redundancy you wish.alt texts that define them as such. You may then add redundant colouration if desired, leading to alt texts like Red triangle, Green circle, and Black square. Whenever you specify colours on a Website, you need to specify at least five colours all at once: Body text, background, normal link, active link, and visited link. Why all five? If you specify fewer than that, your visitor’s default colours may make the combinations unreadable even to someone with colour-normal vision. The visitor’s preferred colours will be used for any setting you did not specify.
Now, obviously it is desirable for people to have the ability to override Web designers’ colour choices, either for personal preference or to accommodate a visual impairment. But in a duel of colour assignments, both sides need to be equally armed: You need to specify every possible colour and so does the visitor, who trumps you with ultimate authority.
If the visitor has no special colour preferences, your colours come through in their entirety and not piecemeal. If the visitor does indeed have preferences, then those colours dominate in their entirety. In either case, someone is completely happy. Leave a colour unspecified, and you both end up unhappy.
How do you do it? In two places: The <body></body> element and in your stylesheet. Apart from the five main colours, you may optionally specify a few other link colours, like the colour a link adopts as it is being selected (usually clicked) or colours seen when you hover over a link.
HTML that is typical of a Website put together by a designer who cares (not all do, and that is not a criticism) might look like this:
<body bgcolor="white" text="black" vlink="purple" alink="blue" link="#990000">
bgcolor is the background colour; text is the text colour. That much you figured out.link attribute.vlink.alink sets the colour for a link as it’s being clicked (an active link).You need these assignments (which may appear in any order in the tag) to take care of those few graphical browsers that don’t support the colour attributes of stylesheets, which nearly all graphical browsers in use today actually do.
XHTML 1.0 Transitional is the last document type in which specifying link and background colours on the <body></body> element is valid. XHTML 1.0 Strict and XHTML 1.1 prohibit it.
But since most browsers run on stylesheets, you need to duplicate your settings in the document’s stylesheet, where you may add yet more settings.
To duplicate what’s in the HTML <body></body> element, use a stylesheet that contains the following:
body { color: black; background-color: white }
a:link { color: #990000; background-color: white; text-decoration: underline }
a:visited { color: purple; background-color: white; text-decoration: none }
a:active { color: white; background-color: purple; text-decoration: underline }
(The actual colours are up to you. As for the text-decoration attribute, see the section on “Underlining links” later in this chapter.)
As in HTML, a stands for anchor or hyperlink, with the colon signifying “pseudoclasses,” or approved minor variations, of the class known as a.
Though the background-color property is supposed to inherit from parent elements, it won’t kill you to explicitly specify the background colour for links. You may also use the specification background-color: inherit.
You’ve got one more commonly-used pseudoclass to play with:
a:hover { color: white; background-color: red; text-decoration: underline }
The a:hover pseudoclass governs what happens when you hover the cursor over a link without clicking it. It’s kind of sexy. But it’s optional.
A mobility-impaired person who uses switch access, tabbing, or some input device other than a mouse is unlikely ever to see the hover effect. For such visitors and for everyone else, you may specify the a:focus pseudoclass, which governs the appearance of a link when it has focus, that is, when the next action you take will apply to it. In real-world use, focus can be distinguished from hovering or activation almost exclusively through keyboard input. If you tab through the links on a page, each successive link gains focus, not hovering or actuation.
A conventional way to signify focus is with a border. In fact, it’s the default in many browsers.
a:focus { color: #990000; background-color: white; border: solid 1px gray; }
You could use any other typographic technique, but you must keep a:hover and a:focus distinct.
Make sure your HTML and stylesheet colour declarations match exactly inasmuch as they overlap: There’s no equivalent to a:hover or a:focus in HTML, so there’s nothing to match there, but there are equivalents for background, text, and normal, visited, and active links.
Order of listing of a: stylesheet declarations is important because all a pseudoclasses have the same “specificity,” meaning the last one listed wins if a link falls into more than one category. The order suggested by Überexpert Eric A. Meyer is:
a:link
a:visited
a:focus
a:hover
a:active
One detail remains: Extreme super-hotshot visitors may have set up a custom user stylesheet to override any of dozens of attributes on your pages. The difference between user stylesheets and simply selecting preferred colours in a browser’s preferences is one of degree rather than kind. User stylesheets confer more power – particularly through the !important attribute, the doomsday weapon of user stylesheets that takes priority over any other definition. Even with this formidable quill in the quiver, the nature of the duel between the designer’s colour preferences and the visitor’s remains unchanged. What the visitor wants the visitor ultimately gets.
In Cascading Stylesheets Level 2 (CSS2) and later, we benefit from a range of new colour keywords of theoretical value in accessible design.
Instead of referring to colours per se as exact or approximate hues (as in rgb(255,51,51) or #f33 or red), these selectors refer to system colours, whatever they may be. Instead of using, say, red for a certain item, you may adopt whatever colour the visitor’s computer operating system uses for text on buttons, or any of a great many system colour choices.
You the designer will not know in advance what the exact colours are. But that is the whole point: You are exercising your own design choices using a palette that respects the system limitations and personal preferences of the visitor. This may strike you as oxymoronic, but we’ll get to that shortly.
Accessibility is listed as one of the official reasons to use these selectors: “They produce pages that may be more accessible, as the current user settings may be related to a disability.” But browser support for these CSS2 selectors leaves much to be desired, at least at time of writing.
Yet even I, a hardcore accessibility advocate, have doubts about the worth of this feature. It is possible, even likely, that sighted Web-surfers enjoy the graphic design and variety of the Web. That is true for at least a portion of the visually-impaired audience, who may object to flashing animated GIFs or other excesses but, when pressed, might admit that Websites often look nice. There is no obvious movement to turn the look of Websites into the look of computer operating systems.
In other online contexts, we already deal with examples of grafting operating-system graphics onto the Web:
We hear a lot about “Web applications” – application software that runs on the Web, usually via remote connection with a far-off server. Usabilitistas debate the merits of standardized vs. customized interfaces for such applications. I can imagine that the less-imaginative developers, or those working in fields where graphical originality is essentially nil (like engineering), will make their Web applications look exactly like Windows applications.
Do we wish to hasten this “standardization”?
More to the point, how are you better off specifying system-colour selectors?
A case could be made that links should always be underlined. Virtually nothing else is underlined on Websites (though I have suggested a few such applications, as in markup for the <abbr></abbr> and <acronym></acronym> elements). Underlined text is almost always a link.
Many browsers allow the user to turn off link underlining. Some people do find it tacky. In stylesheets, the declaration text-decoration: underline turns underlining on, while text-decoration: none turns it off (for whatever item it refers to – in this case, a link expressed by the <a></a> element).
The underscore itself adopts the colour of the link, meaning that colour-confusion issues may theoretically come up. In practice, text in a different colour that’s also underlined is generally recognizable as a link even when minor colour confusions are possible. (If you have unwisely specified red links against a green background, the colour confusions involved are hardly minor. But you know better than to do that anyway.) The redundant coding of different colour plus underlining unambiguously identifies the text.
If you’re looking at a greyscale monitor, the link text will appear in a different shade and also will be underlined. Also unambiguous.
On a monochrome display (single-bit, black or white and nothing in-between), all you’ve got to go on is the underscore (unless there’s also something like <strong></strong> involved).
Obviously, then, the case for underlining links is open-and-shut. Right?
No. Web-surfers have developed a range of heuristics for figuring out what a link is. A colour or font or size change can be sufficient. Left-hand navigation has trained people that stacks of words, images, or combinations of both tend to be links no matter what they look like. Top navigation is viewed similarly based on common experience. The subconscious thinking is: Anything in those broad regions is probably a link.
It is not uncommon for designers to use stylesheets to remove underlining from text links in navbars but retain them in body copy. Unlike navbars, it is not the case that anything in body copy is a link; in body copy we definitely need differentiation.
Sometimes links should be underlined and sometimes they shouldn’t. I’m not going to tell you which orthodoxy to adopt. You may even mix and match. You must nonetheless ensure that your typographic choices in totum are accessible to a person with colour-vision deficiency. You have more than enough knowledge, and all the relevant software utilities, to carry out that task.
You may also use the more æsthetically pleasing dotted underline in all these cases. An example would be:
a { border-bottom: 1px dotted gray }
Now that we have colourblindness out of the way, let’s consider visually-impaired people who have trouble reading “normal” type on Websites.
I am using the term “visually-impaired people” advisedly here. Even people with normal vision have to squint, peer, or work hard to read things from time to time – the instructions on a pill bottle being one example. Does that constitute visual impairment? For that specific task, yes, but not in general.
If people with normal vision find the type on a Website too small, are they visually-impaired? For that specific task, yes.
But that does not constitute a characteristic such people cannot change. Even if the type on a site is too small, if you look across your desk at a newspaper a moment later you are quite likely to be able to read that.
Transitory difficulty in reading a specific Website does not constitute visual impairment. Nor does a preference for 18-point type over whatever the designer specified because some sites were too small to read otherwise, prompting you to set your default at 18 point. (What about the sites whose type would have been quite large enough without your 18-point override?) These are not systemic and unchangeable conditions.
Experienced Web designers will be aware of the battles raging over which units of measurement to use if you want type on a page to be resizable. The ostensible purpose of such resizing is accessibility for the visually-impaired. In reality, you are merely accommodating normal-vision people who find the task of reading that specific page difficult.
While this is surely a form of accessibility, it is too low-level for this book to worry about.
It is generally accepted that pixel (px) sizing is the most compatible with text-zoom features on today’s browsers, and that any type less than nine pixels in height is unreadable. It is further accepted that not every browser can zoom text, and that such a function is essential.
But I have a newsflash for everyone debating these issues: They are essentially irrelevant to actual visually-impaired people.
Recall from the earliest pages of this book that visually-impaired people typically use screen-magnification software, which blows up everything on the screen.
If you use pixel-based sizing and are all proud of yourself for “accommodating the visually challenged,” aren’t you forgetting that the entire computer system has to be accessible, not just your very important Web page?
A Website with big, readable type is not very usable if your menubar insists on communicating with you via teeny 9-point type, if you can’t read the names of the icons on your desktop, or indeed if you can’t read anything except for the Website because it’s all too small.
Screen magnifiers, then, magnify everything equally (or everything according to the settings the user selects). The menubar. The title bar of the window. The contents of the window (your Website). The Taskbar or Control Strip, if any. The trash or wastebasket or recycling bin. Toolbars. Everything.
To accommodate a visitor with a visual impairment severe enough to require big type but not so severe as to invalidate the use of a monitor altogether, there is nothing particularly special you should do. Indeed, there is nothing particularly special you can do.
I know this is a big shock to you, but look on the bright side: It’s one less thing you have to worry about. Accessibility is handled exclusively by the visitor’s adaptive technology.
One possible exception concerns type expressed in graphics or bitmaps, which scale rather poorly. (If you’ve ever used the resize command in Opera, which resizes text and graphics, you know this yourself.) On the other hand, screen-magnification software attempts to make an intelligent, high-quality magnification given that the intended user already has a vision loss. The bitmapped type in your graphic should remain generally legible. An alt text is of course necessary, and can be relied on if the visually-impaired visitor has turned graphics off (which some do); an added title is always nice.
It may interest you to learn that some visually-impaired people use screen readers and screen magnifiers together. A screen reader can certainly read an alt and title if necessary.
There’s another problem with screen magnification. To the extent that I could uncover (manufacturers were quite unhelpful, perhaps understandably based on what I’m about to mention), screen-magnification software blows up the bitmaps already on the screen. But most of the type on your screen has already been blown up from an outline font – a PostScript or (more likely) TrueType outline. The magnifier is not smart enough to re-poll the underlying outline font and provide a clean, smooth magnified character. Instead, it merely blows up the dots already on the screen; they may look nice and tidy at their existing size, but if you quadruple that size, the resulting characters will epitomize the term “jaggies.”
From what I can tell, the only screen magnifier that does the obvious and blows up type from the underlying outline font (why is this not the expected behaviour in the first place?) is the limited ZoomView utility in Mac OS X 10.2, which I had not actually seen at press time. Nothing else blows up type correctly. (Magnifier manufacturers are invited to write in with corrections if I have overlooked something, but I rather doubt it.)
Now, given this fact, I have a hard time getting all high and mighty about pictures of text. Who says they’ll be unreadable when blown up? All the type on the page may look unreadable! And pictures of text at least have alts to back them up, and preferably also titles.
What’s the real problem?
There is a small final detail. Due to a phenomenon known as halation or irradiation, light type on a dark background (reverse or negative type) looks bigger than the converse. When dealing with small type, as we usually do on the Web, the differences may be imperceptible (that is, less than a pixel’s difference). If you have designed a site that uses somewhat larger type (14 point or above, let’s say), you may wish to reduce the size of reverse type by maybe a pixel, or increase the size of regular or positive type by an equal amount.
Attention to this kind of detail, however, may be above and beyond the call of duty in general, and may make sense only when you are creating something like a navbar button with big reversed bitmapped text. The choice is yours.
I suppose it is self-evident that a font that even nondisabled people with eagle-calibre eyesight find difficult to read will be even harder to read for a visually-impaired person. Old German blackletter fonts (mistakenly called Old English; they’re about as English as Leni Riefenstahl) are an example of a hard-to-read font.
Beyond that, though, there are no immediate accessibility issues in type selection. Visually-impaired visitors and those with learning disabilities can override your choices. Totally blind visitors don’t give a darn.
There is, however, one item of advice: In specifying fonts via stylesheets, specify a generic font family in each case (at the very end of the list, usually, meaning it will be the last resort). Why? If, in the exceedingly unlikely case that a visitor has none of the fonts you specify on his or her system, the browser can substitute its own default. The generic font families in Cascading Stylesheets Level 2 are:
serif sans-serif (note the hyphen)cursive (that is, script)fantasy (no real correspondence to a typeface classification predating the Web, but think decorative or display or even “novelty fonts” here; the exact W3C specification says “[f]antasy fonts... are primarily decorative while still containing representations of characters... as opposed to pi or picture fonts, which do not represent characters”)monospace The Web Content Accessibility Guidelines are unreasonably doctrinaire on the topic of using pictures of text to represent words. Checkpoint 3.2 declares:
Content developers should use stylesheets to style text rather than representing text in images. Using text instead of images means that the information will be available to a greater number of users (with speech synthesizers, Braille displays, graphical displays, etc.). Using stylesheets will also allow users to override author styles and change colors or font sizes more easily.
If it is necessary to use a bitmap to create a text effect (special font, transformation, shadows, etc.), the bitmap must be accessible....
Here we see another example of the real-world ignorance of the Web Accessibility Initiative and the antidesign bias of these visual unsophisticates.
I spent weeks assembling this chapter explaining just how to use colours in combination for any application, including pictures of text, while remaining accessible to the only group with a significant demand for colour control. The checkpoint assumes you the designer are too much of a rube to design your own Websites properly.
For screen-magnification users, blown-up pictures of text won’t be all that much worse than blown-up text itself. Based on my research, screen magnifiers are not smart enough to use an operating system’s own font-sizing and font-smoothing capabilities (that is, TrueType or PostScript outlines) when they blow up the screen image. If the unmagnified type size is 11 point and the desired magnified size is 200 point, the screen magnifier does not ask the operating system to draw a beautiful, smooth-edged 200-point character based on the underlying font outline. Rather, the magnifier acts as dumb as a sack of hammers and blows up the 11-point bitmap. How’s that for stupid?
And how is your picture of text really going to fare worse than that?
In any event, the checkpoint invalidates its own initial advice by stating the obvious: A picture of text, like every single picture on every page of your Website, must have appropriate alternate text.
alt text and, whenever possible, a title; both should reiterate the actual text.