Seven Mortal Sins
of Professional Web Designers

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:

Their consequences are serious, up to and including making the pages completely inaccessible.
They are not difficult to fix. In fact, it may be easier to do it right in the first place. Many of them can be fairly classified as beginners' mistakes. And yet...
They're found on more "professionally designed web sites" than you can shake a stick at.

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.

The First Mortal Sin:
Missing Alt Text

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.

The Second Mortal Sin:
Hardcoded Table Widths

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 Third Mortal Sin:
Setting Some but Not All <body> Colors

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: bgColor, text, link, vLink, and 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.

The Fourth Mortal Sin:
Gratuitous Javascript

Javascript is a fine thing. I have friends who are slaves to Javascript; I appreciate the functionality and fun it can add to a page. But: safe use of Javascript (and other advanced technologies) relies on remembering that not every visitor can interpret Javascript. Whether they use a browser that's not Javascript-aware, use one that includes a Javascript version that doesn't support your techniques, or simply leave it turned off out of concerns about stability or security... unless your site is about Javascript and nothing else, a fair proportion of interested visitors won't be able to use scripts. Which means if the content is hidden behind Javascript access, they won't be able to see that content.

Consider WELL Engaged conferencing software, which lets you click a poster's ID to see a bio of the poster. Using Javascript, the designers open the bio in a new, small window without navigation controls. The use of a script improves the user interface, but there's no reason not to let Javascript-less visitors simply follow the link to the bio page without opening a new, special window. The <noScript> tag makes this sort of fallback relatively transparent. But Engaged doesn't do it, and thus locks out anyone not using Javascript.

Some sites make a page more unusable for those who do have Javascript than those who don't. The use of Javascript to overwrite the status line (which normally holds the URL) deserves dishonorable mention here. Although, thank God, the scrolling status bar seems to have gone the way of the giant animated GIF, I still see plenty of sites that display the name of the link instead of the URL in the status bar. I already know the name of the link; I'm holding the mouse over the name of the link.

Time to fix: variable, depending on what the Javascript is used for and how it's implemented. The rule of thumb, though, is to avoid making information gratuitously inaccessible. If the information can be viewed without Javascript - if it's text, or pictures, or other content that doesn't itself rely on a script - then visitors who don't use Javascript should be able to get to it somehow.

The Fifth Mortal Sin:
Antialiasing Abuse

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.

The Sixth Mortal Sin:
Unfriendly Frames

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:

Redesigning the site to move away from frames may sound like an enormous task, but for almost all framed sites, it's a relatively simple matter of identifying the one frame that has the content, then adding the navigation controls it needs.
If you decide to keep the frames, to ensure your site's accessibility you need to make sure the <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.
A similar tactic is to include a link to the content page in your <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.
Some sites offer separate framed and frame-free pages, usually with a link on the index page so the visitor can choose. This option ensures accessibility, but it has the drawback of requiring the same content to be created and updated in two places.
If you're using frames to ensure that certain repeated elements appear on each page, consider server-side includes instead.

The Seventh Mortal Sin:
Ignoring Browser Bugs

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:

If the bug creates only minor problems - if the information on the page is still accessible - then it's a judgment call as to what to do. Sometimes a little investigation will turn up a workaround that will fix the problem, without compromising the display on other browsers.
If the bug creates major problems for accessibility, but it only occurs on browsers that aren't in common use, there may be tough tradeoffs to make. Again, perhaps you can find a workaround. But if you can't, and if the construct you're using truly increases usability, you may have to decide between making the page less usable for all and making it inaccessible to a few visitors.
If the bug creates major problems on browsers in common use, it has to be fixed.

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.

Seven Mortal Sins of Professional Web Designers

Seven Mortal Sins
of Professional Web Designers