Jeanne's WorldThe ShoeboxBad Web Designer, No Cookie|
Jeanne's WorldThe ShoeboxBad Web Designer, No Cookie |
Last time, I discussed seven mortal sins of web design - common practices that could render a page inaccessible to some or all visitors.
This column is about sins which are not mortal, but venial. They don't render pages inaccessible, just annoying and difficult to use - possibly annoying enough to impel the visitor to hit the Back button rather than wade through any more.
Like the mortal sins, these venial sins are easy to fix. Like the mortal sins, they show up often on professional web designers' pages. The theological term "venial" means "forgivable", and these practices can be forgiven by browsers (and by visitors)...but it is this space's belief that they should be avoided. The road to web design sainthood is not paved with sins against accessibility, even little ones.
It's a cliche: the page with an index running down the left side and the content on the right. This design is typically created by enclosing the whole page in a two-column table. Among other things, the practice slows the page's apparent speed to a crawl by making the browser wait until the entire table (which in this case is the entire page) is downloaded before it draws anything at all. If you've sat there staring at a web page for several seconds before anything appeared, this is probably why. (Table abuse is not a pretty thing.)
Time to fix: A few minutes for your template. One alteration is to enclose the index in a table and left-align it, letting the content wrap around it and avoiding the wait-forever-for-the-page-to-appear syndrome. (However, if your index is long, bear in mind that two-column layouts don't work very well if you have to scroll down to read them.) Another possibility is to ask yourself whether your site index is so important to visitors that the loss of valuable screen space on every page is worth it to them. You may not need a persistent index at all.
The <title> element is used for two things: it's shown at the top of the page (as the window's name, in most windowing browsers), and it serves as the bookmark's name when you bookmark the page. For both these purposes, the page is served best by a pithy title. The title "Welcome to the Associated Breeder Technology Home Page - Best Breeder Technology East of the Rockies!!!" is unlikely to fit in a window of reasonable size. (You don't even want to know what that's going to look like in a bookmark menu.) Some professional designers have grasped this, but too many still go overboard.
Time to fix: about ten seconds per page. Concentrate on putting enough information into the title to identify the page - even weeks later when the visitor is looking at the bookmarks list - in a few short words. If the page is an article or other item with a long title, consider putting the title on the page and using an abbreviated version in the <title> element. The words "home page", "web site", and "welcome to" are almost always dispensable, as are marketing slogans. These can go on the page itself, leaving the basic information - for example, "Associated Breeder Technology" - to stand alone in the title.
This problem is so common, it has a name of its own: "Click Here syndrome". How many links have you seen that look like "For a picture, click here"?
There are several reasons not to do this. First is that it makes for bad bookmarks. The text that's linked is, in a sense, the link's title. If you bookmark a link, its text is used as the bookmark's name, and a bookmark called "Click here" is not very informative.
A second problem is that when you print or save a page, "Click here to see an example" is going to require editing, since it only makes sense in a hypertext environment. However, if the page says instead "Associated Breeder Technology is one example of a company that uses this method", the sentence makes sense as simple text, while the link is still easy to find and follow.
Third, following a link is not necessarily done by clicking it; it depends on the browser. For some percentage of visitors, the instruction will be wrong and potentially very confusing. "Select this" is a little better, but like "Click here", it creates a problem when a web page is printed or saved in a format that doesn't retain the links.
Time to fix:A few seconds to a few minutes per link. For most links of this kind, there's an alternative that's obvious when looking at the context. If it's hard to figure out how to change the wording, try using the name of the page you're linking to as the link text, and building the sentence around that.
Many long pages have an internal table of contents on top: a list of links to each section of the page. It's a good idea in theory, but there's one problem: when you follow a link, most browsers stop loading the current page. If the link is to another page, all well and good, since you're about to load that other page anyway. But if the link's destination is on the same page, and you select it before the page finishes loading, you miss the last part of the page.
Even worse: if the section you're trying to go to hasn't been loaded yet, the browser doesn't go anywhere - because the link's destination section isn't available yet, and selecting the link stopped the browser from loading the rest of the page. You have to reload to fix this problem, and if you haven't run into it before, you may just conclude that there's something wrong with the page, since none of the section links seem to do anything.
(Actually, this is more of a browser bug than anything else. It seems unreasonable for a browser to abort loading a page, if the user is staying on that page. But it does happen, and the smart web designer needs to be aware of the bugs as well as the features of popular browsers.)
Time to fix: Depends on how you decide to handle this situation. One possibility is to split the page so that each section is on a separate page, bypassing the browser bug. Another is to place the table of contents on a separate page, so the visitor can jump directly to the section of interest.
OK, at least some sites try. Their designers have heard that it's important to specify alt text for images. But they haven't quite gotten the message that you have to also think about what the alt text should consist of, and all too often it ends up useless or inane. Alternate text replaces the image, so it needs to take over any conceptual function that image provides - not just describe what it looks like. Many images don't have a text equivalent at all, and should be effaced with empty alt text; many others require a text replacement, rather than a description; and still others should be replaced by a glyph (such as an asterisk replacing a graphical bullet).
But on too many sites, alt text has apparently been created by mindlessly supplying a description of the image, perhaps along with its size, with little or no thought to what the visitor will experience in context. "CorporateLogo.JPG (6K)" is better than no alternate text at all, perhaps - but how much time would it have taken to figure out that "Acme, Inc." is a more effective replacement, and will make considerably more sense on the page?
Time to fix: Perhaps as much as a couple of minutes per image, to look at the page and decide what text replacement (if any) would make most sense to the visitor who doesn't see the image. For the designer who is uncertain where to begin, this space again recommends the excellent discussion by Alan Flavell on choosing alt text (which comes complete with several examples of the howlers that can result from careless choice of alt).
I don't know about you, but when I load a page that turns out to be one giant block of 7-point sans-serif text, I want to scream.
With the introduction of HTML 4.0's font face attribute (and similar capabilities in style sheets), many designers have started specifying fonts for text in their pages. All very well and good, but the same old assumptions can lead to the same old problems. When a designer specifies a font for body text, the visitor's choice of body font is disregarded. So this practice, by definition, makes text less comfortable to read for that visitor. There may be reasons to do it anyway - particularly for bits of text such as headings, where readability isn't as important - but for body text, specifying a font face is almost never wise, whether you're using a style sheet or the <font> tag. Helvetica seems to be the most popular vehicle of this sin, and Helvetica is not a very readable font; entire pages of on-screen Helvetica are a strain even at high print resolution, let alone on a screen.
As bad or worse is the use of absolute font sizes to force entire pages of text into a tiny size - presumably because the designer happens to use a low-pixel-density screen and thinks the default size "looks too big" for everyone else too. In its extreme case - the use of <font size=1> to force the smallest possible text - this practice can rise to the level of a mortal sin, making the page completely inaccessible.
Time to fix: A few seconds to a few minutes. The simplest fix is to remove font face specifications altogether; often this will actually improve the look of the page. As a rule of thumb, limit font face changes to text where easy readability is not critical; and when suggesting size adjustments, use relative sizes (such as "+2" or "-1") instead of absolute sizes (so the new size is proportional to the browser's base size).
Anyone using the font tag should take a look at Warren Steele's discussion of font tag problems. This space is not as down on this tag as he is, but his cautions are well worth reading.
A lot of people accept cookies conditionally: they set the browser to accept them, but notify them whenever a cookie request is received. (Cookies can be quite useful, but there are good reasons to want to keep tabs on them.) Unfortunately, some web designers carry a good thing much too far, resulting in dialog after dialog popping up. I was at a cookie-pushing page the other day that wanted to implant a cookie not only for the HTML file but every time a graphic loaded...and it had about 30 graphics. Enough!
Time to fix: Varies depending on what you're doing with the cookies. (But remember that you can use the Referrer field to track movement within the site.) As a rule of thumb, one cookie per site is usually enough, and one cookie per page is an absolute maximum. Annoy visitors too much with cookie alerts and they will go elsewhere.
"Web sites need to be pleasing to the eye. They need to have useful content that attracts visitors. Those are the important factors in web page design. So who cares about these piddly little things?"
If you're a site designer, you should care. For a couple of reasons, at least.
One is your own reputation. Opinions differ, and should, on all the subtle matters of effective site design - but most of these sins aren't matters of opinion so much as they are novice mistakes. Screwing up at this level doesn't show you're au courant or daring; it shows that you either don't know or don't care about the basics.
The second reason is the experience of your visitors. The people for whom the site was designed and built, remember? If your visitors ain't happy, ain't nobody happy. If they have to scroll in two directions to read your content, your content had better be damn good, or they won't come back - and not much content is that good. If they literally can't read the text on your site without changing their preferences...well, hitting the Back button and going to the next hit on that Altavista search is a lot easier.
So go thou and sin no more.
Jeanne A. E. DeVoto jaed@jaedworks.com