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.
Browser requirements
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.
User requirements
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."
Bandwidth requirements
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.
Plain old design
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.
But seriously folks...
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.