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.
- Next time, we'll take a look at curbing JavaScript dependency.
- The W3C site serves as a "canonical" source of Web accessibility guidelines.
- Visit the IBM Ease of Use site for the latest in design guidelines, from designing for the Web to out-of-box experience.
- On a lighter note, SatireWire's review of a Cubist Web site is (while fictional) worth noting from an accessibility standpoint. The author has been to many (nonfictional) sites like this.
- Other installments of The cranky user column: Read about other Web and software usability topics.
- developerWorks Web
architecture zone: Get the Web development solutions you need.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags