Web sites are designed by people with fast, powerful computers, modern browsers, IT staff to keep verything running, their choice of software, and local disk storage -- or at worst, a fast network. They are browsed by people with any of a variety of computers, whatever browser the machine shipped with, software that may have been installed by an IT department that thinks Web browsing is counterproductive, and modems. In fact, it's so easy to ignore this gap that it's easier to offer advice for how to flaunt it than it is to give advice for closing it. Following is a set of principles for doing just that -- making your site as inaccessible as possible.
Accessibility means that people can access your site. Simple, really. Too simple. When we evaluate the "accessibility" of a site, it's too easy to write off serious barriers to entry as easy to overcome. We're computer people. It's all easy to us -- and most of us are doing this on computers that we own, or at least control.
In general, accessibility problems fall into several basic categories. Browser requirements, user requirements, bandwidth requirements, and simple usability. It's no accident that most of these are about requirements; the chief accessibility problem is that sites start making demands of their users. When these demands are too inconvenient, the users go elsewhere.
Let them. In this article, I explore ways in which a designer, flush with the newfound power of authoring tools with capital letters in the middle of their names, can keep the heathens at bay, and ensure that only the chosen view his work.
Never tell them exactly what you use -- just say "requires 4.x browser." Use all the features you can. I don't run JavaScript; the most recent version of Netscape available for my primary desktop machine has a security flaw that makes it possible for 14-year-old children to use my personal computer for porn storage before you can say "h4xor." By building a site that uses JavaScript for even simple links, you can keep my prying eyes away from your trade secrets.
Go ahead and put an "upgrade" button on your page. While you might expect this to let a lot of people in, in practice it makes no difference at all. The users who have older versions may be unable to upgrade. Maybe it's technical competence; maybe it's company policy. My mother is in the news industry; she writes for a paper. The paper's computers can browse. They have limited browsing capabilities. These capabilities will not be changed; they are a policy. She can't upgrade the browser. She can't download plug-ins. So go ahead, put in the "upgrade" button. Taunt her a little; power is there to be flaunted.
Keep in mind that a browser isn't just a single, monolithic program; you can also require plug-ins (many of which may only exist for one platform, or may not be very stable). PDF can be another great choice; it's easy to think that everyone has it, but some computers users don't have it and can't get it. Laugh at them.
Insult (or ignore) blind people. A good Web designer can create a page that comes out of a text reader as "IMAGE! IMAGE! LINK! IMAGE! IMAGE! EMBED!" That's pretty amusing. Think of that laughable wanna-be customer, trying in vain to find a descriptive word anywhere on the page. Of course, this also applies to text browsers, people with low-bandwidth feeds, and others.
Pick a resolution and make sure your page works only at that resolution, and only with a default font size. (You may want to try to specify certain fonts, and make sure the page won't work without them.) The word "pixel" sounds sort of French, so it's probably one of the metric units; it's safe to assume that a pixel is always precisely 1/72nd of an inch. People with small monitors only have them because they can't afford larger monitors; they couldn't afford your product anyway. People with large monitors are showing off, and you should spite them.
Pick colors. Use a black background, black text, and images with a fairly pale background, so that people who don't use images can't read your text. Low contrast can be fun too -- and don't forget that some color blind people will be unable to read combinations such as "green on red."
A menu typically consists of a half-kilobyte to a kilobyte of simple HTML, a few links, and not much else. No fun! Each menu item should be its own carefully rendered image -- this requires multiple connections from the client's browser, and may substantially increase the time it takes to finish the menu. Of course, a single large graphic allows you to avoid the possibility that users will look at where each button links to; use a server-side image map, so they have to use your image.
Headings should always be done using graphics. If you use plain HTML headings, you have no real control over the font used, and only some users will get nice antialiased text. Instead, use a large image rendered in your favorite DTP program; it will help enforce your choice of the one true and correct resolution.
Two basic philosophies of design allow you to keep the end users out of your face. The first is to make sure that there's no functional search, so everything has to be done through whatever navigational aids you choose to offer. The second, and more subtle, philosophy is to make sure that much of your content can only be reached by using your search engine. This is especially effective if your page design standards lead to pages of results -- all of them showing only the leading text, which is the same on all pages. Copyright information is great for this.
Remember that menus, copyright information, and other secondary information should always take up as much space as possible. Consider putting all the content into a small frame, so users aren't overwhelmed by it; they'd rather have a couple inches of margins than too much content, and you're saving them the trouble of resizing their browser windows.
Frames are wonderful: They allow you to make your page totally unprintable, they make bookmarks meaningless, and they are totally unusable on small displays. Tables are nearly as good -- and don't forget to start every page with a <TABLE> with no closing </TABLE>, so that Netscape (versions 2 through 4, anyway) won't render it at all.
That was a lot of fun to write, and I hope it was fun to read -- but I also hope you realize it was ironic. The sad thing is, every principle I described is one I've seen in use, on real pages. I've even had people tell me they aren't really concerned at all with whether blind people, or people with less than cable-modem bandwidth, can see their page.
Web designers are often artists; art, by nature, is not about accessability, it's about vision. When you want to paint something, you can afford to say "only some people will get this painting." However, a corporate Web site can't afford to dismiss whole sections of the population so casually.
Blind spots are a big problem here. We forget how privileged we are. One user I know was complaining about the habit of putting PDFs on a Web page instead of HTML. I thought this seemed harmless -- until I realized that not everyone has the authority to install a specialized reader on a computer, and people using text interfaces can't read PDFs at all. Try to check your assumptions by asking people who don't have the newest computer what options they think they have. (It doesn't help if /you/ can fix a limitation, unless you're willing to commit to doing this proactively for every user who might ever visit your site.)
When you require a specific version of a browser, or a specific feature, you are telling all the people who don't have it, for whatever reason, that you don't want their business, you don't have anything to say to them, and you don't care. Is this ever something you want to say?
No, it isn't. Build a page that works in everything, be it Lynx, be it the so-called browser that runs on my PDA, or be it the latest and greatest version of Netscape. If you want extra features, go ahead, but make sure the page works if I don't enable them. Use alt tags for images. Some day, you will need to access your page from that crappy old Mac your parents turn on every month or two, or from a Palm Pilot. The sanity you save may be your own.
This week's action item: Get access to a text browser (Lynx is great) and try to navigate around your company's Web site. Try to figure out what's going on without reading the page source.
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at crankyuser@seebs.plethora.net