Color me annoyed: OmniWeb’s blind to the consequences of its failings
July 16, 2001
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
Some of you might have noticed that we changed the link colors for some
parts of MacEdition. It’s a sop to OmniWeb, I’m afraid.
Because OmniWeb 4 doesn’t support the background-color property
for anything other than the
BODY element, table cells and
absolutely positioned items, our reader feedback zones were showing up to
OmniWeb readers as black text on teal green, with teal green links on teal
green. To put it mildly, that is not very readable.
So we changed the link color for those regions to the orange-red color we’d been using as the link hover color. It shows up fine as orange-red on teal in OmniWeb to me. But I have lasik-surgery-enhanced 20-20 perfect vision, and perfect color vision. To OmniWeb users with red-green color blindness, it’s still completely illegible.
Caring about the diversity of your readers is not just about the browser they use. People who use the Web don’t all have the same physical abilities, and it would be churlish not to accommodate them all if possible. We do check in the Bobby accessibility checker, even though we haven’t bothered going through the formal approval process. We use CSS so text readers and browsers like Lynx don’t have to wade through font tags and table cells that they can’t display. This is not trivial stuff – we get many more pageviews from Lynx than the tiny number that come from, say, IE3.
One of the reasons MacEdition looks the way it does, and uses the design elements it does, is out of concern for people using text-only browsers and the visually impaired. Unlike many CSS-using sites, we don’t fix our main body text in pixels. We let the user’s browser setting dictate how large the text should be. Of course, that means it looks unattractively large in the default setting in Windows IE, to my eye. But if that’s your browser setting, it must be the way you want it. I have no way of knowing if your browser is set to large type because all the other sites you look at set their text at tiny sizes that you want to override, or because you have problems with your eyesight. So in case it’s the latter reason, I let you choose the main type size. MacEdition’s raison d’être is its content, and we want you to be able to read that content comfortably.
You see, I have a good friend who is profoundly visually impaired enough to have a guide dog. But she still has just enough vision to read a Web page if it’s set at about 36 point on the iMac’s low-resolution setting and she sits right up to the screen. When I look at all those Web sites with 8- or 9-pixel Verdana, I think of her and wonder if it annoys her to come across those sites. Sure, IE5/Mac, Opera, iCab and others all zoom text on the screen, even if it’s set in pixels, and in Opera you can specify a minimum text size. But who wants to keep resetting their browser text size? It’s just plain inconsiderate. My friend is more important than control over the presentation of my Web pages.
At MacEdition, we also make sure that there is sufficient contrast between text and background colors so they are distinguishable to people with various types of color blindness and other visual impairments.
That’s all very well provided the browser either implements CSS1 fully or ignores it completely. But this cruddy, buggy, half-support we get in even the newest browsers makes things very difficult. I can design a reasonably accessible color scheme, but if OmniWeb only implements half of it, I may as well pull out all the colors or change MacEdition’s background to something really pale. But should I have to do this for the eight percent of MacEdition readers using OmniWeb? Or more specifically, the eight percent of that eight percent (0.64%) who are color-blind? And if you think half a per cent is not worth worrying about, consider how many people that is for a busy site like MacEdition – at least as many as we get of Netscape 4.0x, the versions that crash if I make the black border show in other versions of Netscape 4. Do you think I should let those browsers crash, just so users of Netscape 4.5-7 can see MacEdition the way it was intended?
The consequences of male-dominated geekdom
You may already know this, but color blindness, particularly the most common red-green variety, is disproportionately found in males. And males are still the majority of computer users, Web surfers and likely MacEdition readers. So this means that accommodating the color-blind is potentially more important in Web design at present than it might be to a print designer. Unfortunately, those of us with normal color vision have little understanding of how things look to people who are color-blind.
There is a site that purports to display how your pages would look to people with certain types of color blindness. Unfortunately, it’s still in beta and doesn’t support CSS yet. I suppose I could build a dummy page full of font tags and table cells with the colors set in HTML attributes, and get the tool to check that. Or I can ask the long-suffering OmniWeb-using, red-green color-blind guy on the MacEdition staff how things look to him.
Now, I’m trying to come up with a color that will still blend into our color scheme, and show up on both white and teal backgrounds, and be distinguishable to red-green color-blind people on both white and teal backgrounds. I have plenty to choose from, but I’m not confident I’ll hit on something that looks decent.
At least, because we are using CSS, if I do find such a color, I can put it in by editing a few lines in a single stylesheet file. Right now, that’s cold comfort. If Omnigroup had implemented OmniWeb’s CSS support in an orderly fashion, and not the haphazard way they seem to be going about it (absolute positioning before float, background-colors, padding or borders!), none of this would be necessary.