Bad Web Designer, No Cookie
Everyone who writes about the Web - or, as in my case, rants about it - eventually puts out a list of pet peeves. This is mine.
There are, of course, all sorts of obscure ways to make web pages inaccessible, ugly, unreadable, or difficult to use. I've selected these particular sins for three reasons:
There are other design problems that show up on a lot of pages - overused animation, garish colors, rampant misspellings - but you (mostly) don't see them on professionally-designed sites. These seven sins, on the other hand, show up even on web designers' own sites. You'd think if designers would pay attention to details and craftsmanship anywhere, it would be on their own sites...but no.
This one has been talked to death for years on every web-design site, newsgroup, and mailing list in existence. You'd think everyone would have gotten the message by now; bad or nonexistent alt attributes should be a thing of the distant past. Yet here I am at the brand-new Apple Store site, and lo! No alternate text for the images!
Look. There are people out there who don't load images. There are people out there who can't load images. There are people out there paying for every second they spend online, and they're not gonna want to spend their pin money downloading a company logo and a bunch of themed section graphics, no matter how pretty they are. OK?
Time to fix: about five seconds per image. For web designers who aren't sure where to start, this space recommends the excellent discussion by Alan Flavell on choosing alt text.
You know these sites. Either you have to scroll horizontally, back and forth, for each line because the table is wider than your browser window (if you have a small window), or the whole page is scrunched up along the left side (if you have a large window). It's like looking at the page through a cardboard tube.
The funny thing is, eight out of ten times, simply removing the
width attribute from the
<table> tag gives you a page that looks just fine at any size. And some rethinking of the layout logic would have let most of the rest be marked up in a form that fits whatever window size the visitor finds comfortable.
Time to fix: in 80% of cases, five seconds to remove the
width attribute; for most of the rest, maybe five minutes of thought about the relationships the layout needs to show.
The problem here is pretty easy to understand. In the
<body> tag, the designer can set a color for the background, text, and links on the page. These colors override the user's color preferences. The user can choose any colors - but many web designers assume the preferences are always set to Netscape's defaults of black text on a gray background. So they set, say, the background color to white, but fail to set the text color to black at the same time.
If you find light-on-dark color defaults more comfortable to read, you'll run into this a lot. My default text color is the lightest "color cube" yellow [#FFFFCC] with a dark gray background [#444444]. (Try it.) If the page designer has specified a white background but hasn't bothered to set the other colors, I end up with light yellow text on a white background. That's a little hard to read.
You can see similar problems if the page uses a background image but doesn't set a background color. If you don't have automatic image loading on and visit this page, you'll see the text colors set by the page, but they'll be on your default background color...which may make for unreadable text if, say, the page's text is blue and your default background color is blue too.
Time to fix: Ten seconds, if you're a slow typist. There are five colors:
aLink. If you set any one of them in the
<body> tag, or if you specify a background image, you need to set them all.
Antialiasing, the process of blurring edges to make the "jaggies" from the screen's low resolution, is typically used on "graphic text". It fools the eye, making the text look like it's at a higher resolution than it really is and making it easier to read on screen. Back in the dark ages of computer graphics, some ten years ago, antialiasing was done by hand; nowadays, programs such as PhotoShop include algorithms to automatically antialias graphics and text. Most professional sites antialias every graphic heavily.
However, there is a catch. Over-antialiasing small text can blur it so much that it's actually harder to read than the same text with no antialiasing at all: take a look at this heavily antialiased graphic.
More seriously, antialiasing blurs the line between the text and its background by using colors between the text and background color, so if the background color isn't what the graphic artist anticipated, the "halo" of intermediate colors around the text becomes visible. In extreme cases, the halos can make the text impossible to read. (If you're using Netscape, try looking at this built-in Java logo. If this image is displayed on a dark background, the word "Compatible" is impossible to read.)
Time to fix: a few seconds to an hour or more, depending on the size of the graphic and the nature of the problem. Small text graphics may need to be antialiased by hand, and this is a painstaking, pixel-by-pixel process. Most graphics that suffer from haloing can be fixed by making their background the same as the page background, instead of transparent. Even if the user has a different background color, the text itself will be displayed against the intended background color, so it will be readable. Another approach is to place the graphic text over a blob of color, so the text is always viewed against that color even if the graphic's overall background is transparent.
One of the commonest accessibility problems I see on professionally designed sites is frames (I'm tempted to stop there) with useless or insolent
<noFrames> content, or none at all. I expect to see "You have a FRAME IMPAIRED browser!!! Like, get Netscape, d00d!!!" on the personal sites of snotty adolescents, but seeing the equivalent on a commercial site does give me pause. (Particularly when I am using a frames-capable browser, but have them turned off.) The result in terms of accessibility is about as bad as it can be: the visitor is locked completely out of the page's content.
Of course, there are many other potential problems with frame design: too many frames, squeezing the frame that has the actual content down to the size of a postage stamp; framesets displaying four or five scrollbars; frames that aren't big enough for what's in them, but have scrolling turned off so you can't navigate. But most of them don't actually make it impossible to read the page.
Few frame sites I see really work; they're usually harder to use than the unframed equivalent, which makes me wonder why the designers bothered with frames at all. There are counterexamples - sites that work better framed, or even require a frame mechanism to present their content - but they are rare exceptions. Frames almost always make a site uglier and harder to use, instead of better.
Time to fix: for most framed pages, a few minutes. There are several possible approaches:
<noFrames>element can stand alone. Again, for most pages, you'll find one frame has the content. Copying this frame's content into the
<noFrames>element is a simple, if inelegant, solution.
<noFrames>, instead of copying the page contents. This is more cumbersome for your visitors, since they have to follow a link to get to what they want, but if your content page changes frequently, it may be a reasonable tradeoff against the need to update content in two places instead of one.
Ah, the browsers we love to hate. Browsers have all sorts of problems - some actual bugs, some design flaws - and when I see a problem that makes a page difficult or impossible to use, much of the time the page's HTML is correct and it's actually a browser bug or design flaw that's causing the inaccessibility.
The problem is, even though in some important sense this isn't the designer's fault, it can still make the page content inaccessible, and that's something anyone who puts up a web page needs to worry about. And even popular browsers in their third and fourth version have many problems that can make a page unreadable.
By all rights, using
<font color> and
<table bgColor> on a page with its own text and background colors ought to be worry-free. But Netscape fails to ignore these color attributes when you set "Always use my colors", so the page can end up unreadable due to conflict with your color choices. Mosaic has ugly problems when right-aligning a paragraph next to a right-aligned image. MSIE 3.0 has stylesheet bugs that can render a page impossible to read.
(So-called purists can be as guilty of this particular sin as anyone else. "It follows the spec, and if a browser doesn't handle it properly that's not my problem" is less distasteful, when considered as an abstract position, than "If it works on my computer with my browser and my preferences then it doesn't matter what anyone else sees". But it still leaves the visitor up a creek.)
Time to fix: highly variable. It's a frustrating problem. On the one hand, you have a page that should work. On the other hand, for some percentage of your visitors, it doesn't work. So what do you do? I can only offer a few rules of thumb:
Even though it's not your fault, even if the page follows the specifications in every respect, the page with this sort of problem is inaccessible to too many people. And that, as they say, is the bottom line.