06. The image problem
AUTHOR’S NOTE
– You’re reading the HTML version of a chapter from the book
Building Accessible Websites
ISBN
0-7357-1150-X).
Joe Clark
, 2002 (
about the author
). All rights reserved. ¶
Back to Contents
Online imagery is a core concern in accessibility. And that includes more than just photographs. On the Web, images are used for logos, navigation instruments (like “forward” and “back” or “next” and “previous” arrows), form buttons and labels, and for text itself (as
pictures of text
, with text saved as a bitmapped image rather than selectable characters). We find information graphics online – everything from spreadsheet-like graphs and charts to flowcharts to sewing patterns to musical scores.
And if visitors to your site cannot see, or if their browsers do not show graphics, they face a barrier in understanding those images.
The good news is that minimal access to imagery is ridiculously simple to achieve, while an intermediate level of access is not very much harder. The highest degree of accessible imagery is admittedly complex and harder to implement, but it is nonetheless a skill you can acquire. In this chapter, you’ll learn how to use
alt
title
, and
longdesc
to make any image barrier-free.
Goals
In this chapter:
We’ll learn three levels of accessibility for uncomplicated image types.
We’ll work through a list of complicated image types and come up with ways to make them accessible.
We’ll discourage the use of a few well-intentioned but counterproductive accessibility methods.
More than half the battle
The importance of making absolutely all the images on your Website accessible cannot be underestimated. This simple action alone gets you more than halfway toward an accessible site. You have to do it
correctly
, but even if you skip every other accessibility step, your sites immediately become fundamentally accessible.
The basics
Note: If you’re already familiar with basic HTML, you can skip this section.
With uncommon exceptions, Web pages include
text
right within the page but merely
refer
to graphics. When you open a page in your browser, the page directly contains its own text. On the other hand, any graphics that appear in your browser are actually called up
separately
by the page.
You’ve probably seen this yourself: The text of a page loads, but the browser status line tells you it is “fetching image” of such-and-such a name.
While it’s not the only way to do so, images are almost always called up using the
img
element. Here’s a typical (inaccessible) example:

The parts are:
src
(“source”) is the filename. I’m using an easy example here, but the filename can be any URL anywhere – from a subdirectory on your hard drive, from another server in the same domain, or from a separate site altogether.
width
and
height
are measured in pixels. These attributes are not mandatory, but they speed up display because the browser knows how large an onscreen display area to reserve.
border
describes the visible border around the image, in pixels. A border of zero is invisible or nonexistent; most of the time, a border is visually undesirable.
In this inaccessible example:
The browser will dutifully load the image if the file named
sunset.gif
is actually available, but if you can’t see the image, it is of no help to you.
If you’ve turned image-loading off, you’ll see a placeholder graphic, if that.
A text-only browser like Lynx will display only a placeholder – in the Lynx case,
[INLINE]
or the image filename.
A screen-reader program cannot look at the image, understand it, and turn it into words. You need a text equivalent for the image to be accessible.
You have three levels of text equivalent at your disposal:
alt
title
, and
longdesc
Your first course of action
You do the greatest good with the easiest access technique:
alt
. A part of the HTML standard since HTML 2.0 (way back in 1995!),
alt
simply means “alternate” – a text alternative for your image.
Write an
alt
text by summing up your image in a few words. Include it right in the
img
element, like so:

The attributes can appear in any order, and
alt
doesn’t have to be last.
The
alt
text can be read and used in the following circumstances:
A screen reader can read the text aloud or send it to a Braille display.
A graphical browser with image-loading turned
on
that nonetheless cannot find the image file will display the
alt
text. (This happens even on well-funded commercial sites; I run across an example about once a month in recreational surfing.) Since the
alt
text sits inside the
img
element, it is loaded with the main page; even if the browser cannot find the graphic, it already knows the contents of the
alt
text and can display it.
A graphical browser with image-loading turned
off
will display the
alt
text.
Theoretically,
alt
texts can be indexed by search engines, but this is not much of a reason to use them.
Keep the
alt
text short. There is no set limit on the length of an
alt
text, but as we shall see shortly, a very long
alt
may not be fully displayed when image-loading is turned off or when the browser cannot locate the image file. By convention, limit
alt
texts to 1,024 characters (1 K) or less.
When it comes to writing the actual text, remember that
alt
takes the place of the graphic. Tell us what the picture
is
or
represents
or sum up its
function
, but don’t tell us that it’s a picture. I’ll give you actual examples in a moment, but steer clear of writing a sort of meta–
alt
text, like “Picture of sunset over Darling Harbour” or “Picture of company logo.”
Examples to avoid
Do not use the image filename, and don’t let your authoring program substitute a filename automatically for you; it’s better to leave an
alt
text blank or leave it out altogether than to foist a filename on your unsuspecting visitors. (How would you like to see the word “spacer.gif” ten times on one page? Isn’t it even worse to hear your computer utter the phrase “spacer.gif” ten times on one page?)
Also be sure not to accidentally leave in an authoring program’s reminders: Merely in the course of recreational Web-surfing while writing this book, I found more than one site with
alt
texts reading “short description of image.”
Further, do not get cute. I know of an adult site – contain your
pro forma
surprise, please; it’s
Nightcharm.com
– that uses “lubricating” as the
alt
text for a simple, G-rated photograph of the site owner. (Should we call this photo a “headshot”?) I guess that’s supposed to be some kind of tremendously droll synonym for “loading image.”
On that topic, do not act as though
alt
texts function as placeholders while graphics load; do not, in other words, use
alt="Loading image"
or anything similar. Nor should you fill an
alt
text with advertising slogans of any kind. (Alternate texts for ads are discussed later in this chapter.)
Include an
alt
for absolutely every
img
without exception. An
alt
is required for every graphic in HTML 4 and XHTML. (The requirement reads: “The
alt
attribute must be specified for the
img
and

elements.”) An
img
without an
alt
will cause your page to flunk when passed through a validator. For most of us, skipping an
alt
here and there was a way of life for years, and this new strictness is a bit of a pain at first. Then again, every authoring tool prompts you for an
alt
, and if you’re typing out code by hand, adding a single attribute is not exactly onerous.
The next step up the ladder
You can add another attribute on the
img
element to improve accessibility:
title
Although it is not widely known, in fact the
title
attribute can be applied to virtually anything in HTML. Further, the purpose and function of
title
are quite broad (you might say vague): The actual World Wide Web Consortium definition reads “This attribute offers advisory information about the element for which it is set.” In other words, anything goes.
You’ve probably run across
title
s without even knowing it. If you use a graphical browser, you may have witnessed a “tooltip,” or small pop-up windoid, appear when you hover your mouse over an image, a link, or even a chunk of text. The windoid shows the text of the
title
attribute. Unfortunately, some versions of Netscape 4 and certain early Internet Explorer versions also display a tooltip for
alt
text, a phenomenon World Wide Web Consortium guidelines do not authorize; conversely,
W3C
guidelines do not require that
title
be displayed any particular way (or at all: Netscape 4 ignores it, and such behaviour is legal). Accordingly, it is also legal for iCab on Macintosh and Opera on several platforms to display
title
text in a status bar, as they in fact do.
In image accessibility, you can use the
title
attribute to load up an
img
element with helpful but optional details; to expand on an
alt
; to warn about unusual browser behaviours; and to have a little fun. Using the markup

as an example, you could add one of the following
title
s:
title="Darling Harbour, Sydney, October 2000, Olympic cleanup underway"
title="Darling Harbour Sunset. Click for larger image (800x400)"
(though arguably that one should reside on a containing

element, as it refers to a link)
title="Darling Harbour. Got rid of the Americans, but not their garbage"
title="Darling Harbour Sunset. Full-size version opens in new window"
As you’ll see later,
title
falls between
alt
and
longdesc
in degree of descriptiveness:
alt
gives you minimal, absolutely essential information;
title
adds useful information and can add flavour;
longdesc
(to be examined shortly) provides for rich, expressive documentation of a visual image.
You don’t have to be dry and uptight in writing
title
texts. In fact, feel free to add some verve. If you’re presenting a photo album (of a vacation, a conference, a day in the life), you can use an
alt
to describe the basic setup of a photograph and
title
to explain the photo’s significance in the big picture, as it were.
alt="Cabot Trail, Monday"
title="When I was growing up, everyone visited the Cabot Trail but us. I would have been too young to appreciate it anyway"
alt="Cusack, Oscars 97"
title="John was ROBBED AGAIN at the Oscars, not even getting NOMINATED for Grosse Pointe"
alt="Medical examiner"
title="The medical examiner, John Butt, inside Hangar B, where he spent three months identifying victims"
alt="Left ventricle"
title="I had bypass surgery in 1994, but this is from my double bypass in 1997. Here Dr. Otinsky prepares to insert a shunt"
What do you do when you don’t have anything special to add to your
alt
text? Adding a
title
is optional. There’s no harm in making the
title
text identical to
alt
. I recommend consistency in coding: If you use
title
anywhere on a page, use it everywhere on that page. If you can write an
alt
and a
title
that are respectively different for three out of four images on a page, for the remaining image the
alt
and
title
can be the same. The result is a page that provides
title
text for
all
images rather than some of them. If you opt to provide only
alt
s for an entire page, stick with that.
If you hate
title
s, by the way, you can suppress their display in graphical browsers by using
title=""
(empty
title
, analogous to empty
alt
, coming up shortly). To be thorough, you’d have to add it to every image on the page. Worth your while? I doubt it.
However, if
alt
and
title
have the same text, enclose the
title
in brackets
[ ]
like so:
alt="Sunday picnic" title="[Sunday picnic]"
. That way you will know for sure which of the two otherwise-identical texts your browser or device may be displaying. We wouldn’t have to bother with this if Netscape and Microsoft had not defied the HTML specification and popped up
alt
texts as browser tooltips. (To reiterate,
alternate
texts are replacements, not additions.) It does no harm to write all your
title
texts this way if you wish.
Here in the real world, individual pages are upgraded faster than entire sites. If only a few of your pages have
title
s while the rest (mostly older pages) do not, it is not something to worry about. Consistency within a page is more readily achievable and more important.
I can think of one rather unusual exception: Drop caps, as described later, do not need a
title
, and it may be viable to code a graphic acting as a drop cap as the only
img
element on a page without a
title
even if the other images do have them.
Compatibility
Screen readers have access to
title
s and may read them out loud if the user requests it. I may be describing an idealized case here, since occasional reports I’ve seen hold that certain screen-reader versions under certain conditions cannot read
title
s. Even if that is true, it is not your problem as a Web designer or developer; we have to expect software manufacturers to provide support for basic HTML.
Lynx, the leading text-only browser, displays
title
s if and only if the image is also a link or imagemap; press
or
for List of links.
No version of Netscape Navigator or Communicator ever displayed
title
text before Netscape 6; that version, and any Mozilla build current with the release of this book, both pop up a tooltip for
title
s.
iCab on Macintosh and Opera on several platforms display
title
text on a status line.
I have never seen a version of Internet Explorer on either Macintosh or Windows platforms that did
not
display a tooltip for any kind of
title
anywhere on a page, including
title
s on images.
As you’ll see throughout this book, you can slap a
title
on virtually anything in HTML. In fact, the only tags where it is apparently illegal to include
title
are:


base
meta


(inside

basefont
(“deprecated” in XHTML anyway; use stylesheets instead)
param
(inside

and

Waxing poetic: Long descriptions
When
alt
and
title
are insufficient to embody the visual qualities of an image in words, HTML offers an access feature at a higher level of complexity:
longdesc
longdesc
is a
long description
of an image. How long? The sky’s the limit.
longdesc
is meant for pictures worth more than a thousand words (or 1,024 characters). The aim is to use any length of description necessary to impart the details of the graphic. It would not be remiss to hope that a long description conjures an image –
the
image – in the mind’s eye, an analogy that holds true even for the totally blind.
Unlike
alt
and
title
, which are included in the
img
element and are always available for rendering in a browser or screen reader, a
longdesc
is a separate file. You would normally write a valid (albeit small) HTML file for each
longdesc
. Your browser or screen reader has to support
longdesc
, and very few do.
Here’s how you add the
longdesc
attribute to an
img
element:
title="Darling Harbour, Sydney, October 2000, Olympic cleanup underway"
alt="Sunset over Darling Harbour" longdesc="sunset-LD.html" />
The naming convention I suggest is to use the same filename as the image file plus the characters
-LD
; remove the extension used for image files (
.gif
, .
JPG
.png
, or any other) and replace it with whatever extension you use for HTML files. Since a
longdesc
is an HTML file, it uses the same filename structure as all your other HTML files. If you use
.html
or
.htm
as a filename extension for other files, stay consistent. Preserve any hyphens, underscores, and extended characters in the original image filenames.
This way, in alphabetical file listings in your operating system, the graphic file and the
longdesc
will be right next to each other; the use of capitals in
-LD
makes the
longdesc
files easier to spot, and, if you’re consistent in your file naming, you can search for and manipulate all
longdesc
files easily. Another advantage: The character sequence
-LD
is not likely to come up very often in filenames – certainly not when followed by
.html
or
.htm
. Example filename pairs:
src="photo6.gif"
and
longdesc="photo6-LD.html"
src="map-europe_2.JPG"
and
longdesc="map-europe_2-LD.htm"
src="S%8Bo%20Paulo%206.jpg"
and
longdesc="S%8Bo%20Paulo%206-LD.html"
(where
S%8Bo%20Paulo%206
is the character encoding for
São Paulo 6
, complete with accent and space characters)
Use fully-qualified directory addressing in your URLs if necessary. Should you keep
longdesc
files in the same directory as images? Probably. I suspect the only likely reason to keep them separate is to make allowances for the day when you will run batch operations on, say, every graphic or every long-description file. But I’m sure your software is clever enough to manipulate only files of a certain type; they’re readily differentiated by filename and extension, and of course by type and creator codes,
MIME
type, or whatever other metadata your system stores for every file. In any event, the following examples are equivalent save for file structure:
src="/img/png/cavernosum-6.PNG"
and
longdesc="/img/png/cavernosum-6-LD.html"
(same directory)
src="/img/png/cavernosum-6.PNG"
and
longdesc="/longdesc/cavernosum-6-LD.html"
(different directories)
File structure
What does a
longdesc
file look like? Like any other HTML file. But you might as well keep it small. Now
is
the time to write the simplest, plainest text-only page. You want nothing to stand in the way of reading the long description; we’re already loading a separate file here, which takes a certain time to do, so we might as well make the
longdesc
file as compact as possible.

At dusk, the sun’s rays turn the wispy clouds over Darling Harbour, Sydney, brilliant orange and red. A ferry, distantly visible, crosses the harbour from right to left. The deserted remnants of the Sydney 2000 Olympic rowing facilities are visible in the far distance. A small clump of people, some with cameras strapped around their necks, stand at the right of the picture peering and snapping photographs.

Back to the photo album.

Let’s consider the structure of the file.
As is recommended practice (see Chapter 5, “The structure of accessible pages”), use a
DOCTYPE
declaration so the browser or screen reader will know which level of HTML you’ve employed.
All HTML files begin with

, require a

(in which you must include a
elements): “Long description for
filename
” is short and to the point.
In the
body
itself, write the long description. Use any accessible and legal HTML features you want (including, in this example, non-ASCII punctuation like
’
for an apostrophe), though it might be a tad recursive to use images.
Links back to the original
The last paragraph in the above example is a nice touch that isn’t strictly necessary but will be helpful in real-world usage. In it, I’ve added a link back to the previous document just
past
the point where the graphic image occurs. The visitor can simply keep on reading from that point. I used a page anchor – the characters after the
in the

link. Different circumstances may warrant different usage.
If the source page, as in the case of a photo album, shows the image by itself with little or no additional text, just give a plain link back to the page.
If you’re dealing with a longer source document that includes intermingled graphics and text, add an anchor to the text immediately following the graphic you are describing. In this case, place

around the first few words of the subsequent text. (Example:
When evening came, we headed off to Darlinghurst for a quick bite
.) Other naming techniques (like adding
name
and/or
id
to the

element surrounding the text) are sometimes viable, but browser support varies.
If your page uses frames, I have no foolproof method to offer. I suppose placing an anchor link inside the frame that contains the image being described is the obvious course of action, but coding the URL of a specific frame may cause only that frame to load in the browser. (A number of JavaScript techniques – all of them, as the saying goes, beyond the scope of this book – are available to ensure that surrounding frames are reloaded whenever a browser requests only a single frame. This does tend to work at cross-purposes to your visitors’ ability to load a single frame in the first place.) Or it may suffice to use the URL of the page enclosing the entire frameset, with appopriate added anchor. I can only counsel experimentation and debugging in sites that use frames.
If your site uses a content-management system that assigns a filename only when source code is uploaded or saved, you will not know the filename to which to
append
the anchor link until the original file is uploaded – in the example above, you may know that you’re using an anchor called
sunset
but not that the filename is
photoalbum.html
. In practice, this is not much of an impediment, since you’re surely going to perfect the main page first and work on long descriptions later.
How to write descriptions
If your background is in computer programming, you may find it intimidating to write concise, evocative descriptions of pictorial imagery. If you’re a visual designer, prose is not likely your forte. (If it were, you’d be a writer, not a designer.) Even if you have a lot of writing experience, you still won’t find it very easy. Because it isn’t. Writing descriptions, however, is a skill that becomes less difficult with exposure and experience.
Exposure, however, remains a problem. There are very few examples of
longdesc
s on the Web today, meaning there are few models to emulate. This book does not contain sets of images with long descriptions from which to learn. It was my plan all along to include such a collection, and I put a great deal of work into preparing it, but in all honesty it turned out to be impossible to complete such a task, which amounts to writing half a second book. It is possible, though, that I may be able to offer a learning resource of this sort in the future; take a look from time to time at joeclark.org/book/ for news. I must apologize for letting you down here, but in practice there is only so much a single book can cover.
I can, however, provide rules of thumb that will guide you on what to mention and how. With experience you will develop your own style.
The cardinal rule of description is “Describe what you see.”
To get you in the right frame of mind, imagine you’re talking on the phone to one of your good friends. It’s one of those phone calls where you’re just shooting the breeze. Imagine you’ve casually mentioned that you have just gotten your photos back from the developer, or you’re working on a portfolio downloaded from your digital camera. Now imagine telling your friend you especially like this certain picture. “Oh?” your friend asks. “What’s it look like?” “Well, it’s a picture of...” A picture of what? The way you’d finish that sentence is pretty much the way you’ll write a description.
Here’s another approach: What words would you use to describe the photo to clearly distinguish it from another photo – from
every other
photo there is? Does it show a person, as opposed to an airplane? Is it an indoor or an outdoor photo? Daytime or nighttime? Is it actually a line drawing rather than a photograph? Are there mountains in the photo, or a canoe on a lake?
With personal image collections, it can be quite helpful to explain nice little details about how the photo came about, particularly if the text of the original page mentions it. You could add, for example, “Jim still has his cast on at this point; it came off the next day.” That kind of folksy tone is unlikely to be appropriate in a business site, for example, but, as with the fun you can have with the
title
attribute, a colourful writing style can jazz up an otherwise dry description, actually fulfilling the goal of rendering the essence of the image in words.
Mention the point of view or position of the camera or observer, if only implicitly: “A black Labrador retriever sniffs the beach sand nearby. Farther down the road, an elderly man leans over and waves a leash.”
Definitely mention colours. All blind and visually-impaired people understand the social significance of colour: Everyone knows red is the colour of blood and connotes passion; the sky is blue, and blue is peaceful; green, the colour of grass, represents nature. Brown eyes are common, blue eyes unusual, green or grey eyes very unusual. Keep in mind that most blind people either now have or used to have some usable vision; even people blind from birth have a conversational understanding of colour.
Point out details that would be unexpected based on common knowledge of the visual world.
“On top of Marge’s head sits a two-and-a-half-foot-tall column of blue hair with a rounded tip. Her eyelashes are prominent and she wears a blue dress, round earrings, and a choker with big white stones. Like all the Simpsons, her hands have four fingers, and her skin colour is dull yellow.”
“Salif Keita sings into a microphone onstage, his backup band playing drums, guitars, and congas behind him. Keita and his band are all black guys, but Keita is also albino, with very pale, pinkish skin and translucent hair and eyebrows.”
There’s no such thing as a graphic with nothing to describe.
An image in which not much seems to be going on – a simple snapshot of a person, for example – gives you the opportunity to describe what the person looks like. Tall or short? Curly brown hair, long blond hair, shaved head, reddish sideburns? Make-up? Flannel shirt, leather jacket, silk blouse, striped tie, tuxedo? How would you describe the facial expression?
If the graphic is a drawing of an object, what does the object look like? If it’s a guitar, is it acoustic or electric? What colour? Tell us the shape of the guitar. If it’s a bass guitar, say so, and maybe mention how few strings there are. Is it plugged into an amplifier? (If a cord is plugged into the guitar but you can’t see the amplifier, the answer is no: “A patch cord is plugged into the guitar’s jack.”)
If the photo shows Nick poking his head out from behind a palm tree, what does a palm tree look like? How tall is it? What do the leaves and trunk look like? (Feel free to make a comparison: “Unlike pine trees, with branches nearly all the way up the trunk, palm trees concentrate their long, rubbery leaves at the very top.”)
Use tight, evocative adjective phrases: “long, furry tail with two matted brown burdock burrs near the tip”; “bright-red earphones half the size of a grapefruit”; “navy-blue cargo pants, with Velcro-flapped pockets on the sides of both legs and an elastic waistband”; “hundreds of wide concrete steps lead to the massive wooden doors two storeys up”; “low-hanging, dull-grey clouds almost touch the church spire in the near distance.”
You don’t have to include every single detail (like how many flowers are in a vase), but exceptions should be mentioned: “The vase holds a few dozen roses, all red except for a single yellow one in the centre.”
Browser complications
While there isn’t a browser you could name that doesn’t support
alt
, and most modern browsers support
title
, at time of writing there’s virtually no support whatsoever for
longdesc
. Even screen readers generally ignore the attribute altogether. It’s an issue of chicken vs. egg: Browsers and devices have to support
longdesc
before developers use it consistently, while makers of browsers and devices are in no hurry to support
longdesc
until it is in wider actual use. Even so, given that
longdesc
is
intended
for blind and visually-impaired visitors and has been part of HTML 4 since late 1995 (for frames), it is scandalous that every screen reader updated
since
that time does
not
directly support
longdesc
In fact, only iCab, the Macintosh graphical browser; Mozilla and Netscape 6 on all platforms; and the Jaws screen reader (version 4.01 and later) all have access to longdesc.
To view a long description:
In iCab,
Control
-click on an image. In the resulting contextual menu, look for Description under the Image submenu. iCab will open a new window displaying the
longdesc
file.
In Mozilla and Netscape 6, bring up a contextual menu for an image (by right-clicking or
Control
-clicking, or whatever technique your operating system requires). Select Properties. The link to the long description will appear.
So-called standards-compliant browsers, like Internet Explorer 5 for Macintosh and Explorer 6 for Windows, allegedly support
longdesc
, but do so merely by passing on the presence of
longdesc
to some unspecified separate program (i.e., they pass it on through the DOM, or document object model).
It is certainly open to question why graphical browsers should provide an interface that lets sighted users read a
longdesc
at all. Unlike the
summary
attribute on

, which the World Wide Web Consortium specifically states is limited to “user agents rendering to non-visual media such as speech and Braille,” the
W3C
makes no recommendations on limiting access to
longdesc
. That in itself is sufficient reason to make it available to all users. I can, however, see a few other reasons:
Standards compliance: If browser makers want us to believe they take compliance with HTML standards seriously, they cannot pick and choose which features to support. That, of course, is exactly what they do at present, but the practice is to be discouraged.
Testing: Providing even a hidden interface for
longdesc
lets developers test their accessible pages.
D-links
To get around these incompatibilities, well-meaning experts (most prominently, the Web Accessibility Initiative itself and the WGBH Educational Foundation) have promoted the use of
D-links
– the use of the letter
for Description (rendered any way you want to write it –
[d]
[D]
D.
d.
, whatever) as a visible, explicit link to the long description of the image.
The idea is that you will somehow figure out a way to place a tag like
D.
somewhere alongside your actual image. This link works exactly the way
longdesc
itself does and points to the exact same file.
It’s a noble idea, really. But unless your software creates them automatically for you, don’t bother. Reasons:
I promised at the outset of this book that I would advise you to make visible alterations to your layout only if necessary. Here it is
not
necessary; we have the
longdesc
attribute for this task.
D-links look awful.
It is often difficult or impossible to associate them unambiguously with the graphic they refer to. (Don’t believe me? Think of a photo gallery with three rows of five photographs. Just where do you add the
s?)
The fact that
longdesc
is poorly supported is not really your fault, or even your concern. A great many accessibility features of HTML are poorly supported, even by adaptive technology. But there are virtually
no
access features that are entirely
un
supported. There’s always
some
population out there that can use what you code, including long descriptions. If it is incumbent on you the designer or developer to code according to standards, it is even more incumbent on makers of browsers and adaptive technology to
support
those standards. To solve the dilemma of chicken and egg, somebody’s got to volunteer to be one of them.
If, on the other hand, the use of
longdesc
caused actual bugs or catastrophic failures (the way

does in some versions of Netscape 4), then a case could be made against its use. But there are no such bugs or failures. It’s either supported or it’s not. Nothing undesirable happens in either case.
While I do not
strictly
adhere to the usability dictum “Make link texts self-explanatory,” I do feel that links along the lines of
Click here!
are trite, stick out like a sore thumb from the surrounding text, and don’t give us enough information to figure out where we will end up once we “click” the link. I would place D-links in this same category, but much worse: A page with three or four D-links, all of which look the same and differ only by the
href
URL, is just asking you to make mistakes. (Which
goes where? Which
goes with which image?)
If including
longdesc
on the
img
element adds a wee bit of extra work (excluding the task of writing the description file itself, which you’d always be doing anyway), the D-link technique requires essentially double that effort. You will end up using the
longdesc
attribute anyway
and also
set up an entirely separate hyperlink, with careful attention paid to URL and positioning. It ain’t worth it.
I do know of one software package that can create D-links automatically – PopChart [D] by Corda (
corda.com/d/
), which automatically summarizes numerical charts and graphs, produces a long description using
longdesc
and
sets up a D-link. If you like that package, use it.
Also, the University of Toronto’s A-Prompt utility (described in Chapter 14, “Certification and testing”; available online at
APrompt.ca
; and included on this book’s CD-ROM
in the Extras folder
) can produce D-links for you.
If, in some imagined future, DreamWeaver, GoLive, and the like all automatically create D-links, you could use those, too. But D-links remain pug-ugly, and entering D-links by hand simply is not worth it.
Page descriptions
Similarly, well-meaning access advocates have suggested using a D-link to describe
the overall appearance of a page
. I see this advice as a form of displaced liberal guilt of the sort William Hurt exhibited in
Children of a Lesser God
, in which his character, James Leeds, suddenly feels guilty about playing LP records because his girlfriend, Marlee Matlin as Sarah Norman, is deaf. Funnily enough, this guilt trip never hit him during all the years he was a teacher at a school
for
the deaf. In any event, Sarah rightly tells him to stuff it. The fact that she cannot hear says nothing about the fact that he can. Use what you’ve got. If you can enjoy music, go ahead; you should not be impeded by the fact that someone else cannot (and in this case cannot be accommodated, since LP records, unlike music videos, cannot be captioned).
I suppose it is possible that some blind or visually-impaired person here or there might be interested in the specific graphic-arts details of your page layout, but just what does that add? Page descriptions are in no way comparable to audio or text descriptions of artworks like paintings, photographs, plays, television programs, and films, where appearance cannot be separated from enjoyment, meaning, and understanding. Online, we go to considerable lengths to do just that. Stylesheets separate presentation from structure, for example. The bulk of the techniques explained in this book make it possible to use Websites without one of the five human senses.
I assume, at this point in your understanding of Web accessibility, it will not hurt your feelings to be told that the specific appearance of your site is not really important; while we will not sacrifice appearance for accessibility unless we have to, it remains true that your site’s
meaning
is important, not its appearance.
And anyway, how would you link to such a description? I guess we’re supposed to double up page descriptions and image descriptions on those ill-advised D-links. So does the D-link refer to the nice big central graphic or to the whole page?
Here is an example page description from WGBH.org:
Five selectable images appear at the top of the page. From left to right they read: “Television,” “Radio,” “Web,” “Learn” and “Members.” Below is the WGBH logo, the words “media access” and “‘GBH is the birthplace of technologies that make TV and other media more accessible to disabled people.” Additional selectable images are “CPB/WGBH National Center for Accessible Media (NCAM),” “Descriptive Video” and “Captioning.”
Most of the phrases in quotation marks above are live hyperlinks in the original. Accessible images (including imagemaps) would give the blind visitor
direct
access to each of those items on the original page in question. How many levels of abstraction are we dealing with here? Do we want the page itself accessible, or do we want a description of the page accessible?
Don’t waste your time with page descriptions. They’re a misguided idea and are not worth the trouble.
Problem cases
As you build Websites, you’ll find a range of image types that present a few problems. How do you summarize problem graphics like these?
Before delving into an excruciating degree of detail, I will provide an overriding principle: Be specific. Do
not
give us something generic, like “Ad” or “Bullet” or “Arrow.”
Advertising
Graphical advertisements are a big enough issue to warrant their own section.
Ordinary GIF and JPEG images used as advertising are not difficult to make accessible.
By far the most important task: Keep marketing propaganda
out
of the
alt
text. Cut, as they say, the crap. Give us
the bullet
: Use a concise, self-explanatory
alt
text that explains the benefit or purpose of the ad. Imagine you are transforming your visual ad into a slogan used as a sponsorship credit on a television program. How would you sum up the
message
of the advertisement? Or imagine you are boiling down the advertisement to a classified ad where you pay by the word. What is the irreducible minimum message?
Do not bother attempting to epitomize the visual appearance of the ad. Remember, the
alt
text encodes the
function
of a graphic. With animated GIFs, it is better to pretend the GIF is static rather than animated and treat the ad no differently from others.
Include the word “Advertisement” (in brackets or parentheses) somewhere in the
alt
text. Such a disclaimer is not required on all Websites for the
visual
manifestation of an ad, but then it isn’t always necessary; as in newspapers, a disclaimer, if not used in all cases, is used where an ad may be mistaken for editorial copy or illustration. But
alt
texts are not visual, except inasmuch as they can be seen in graphical browsers under certain unusual circumstances. You must imagine the screen-reader or Braille-display user whose experience of a Website is one of subtly-differentiated text streams. A blind or visually-impaired visitor cannot determine at a glance that your ad actually
is
an ad because, of course, such a visitor cannot necessarily cast a glance. I would use
alt="(Advertisement)"
or
alt="[Advertisement]"
followed by a space and the rest of the copy.
Sponsor advertisements are used somewhat differently from banner ads. You can still click them and visit the actual sponsor, but they approach is usually more low-key. We often see a column of sponsor logos labeled as such (e.g., “Please visit our sponsors”). It would not hurt to use
(Sponsor)
or
[Sponsor]
inside your
alt
rather than
(Advertisement)
or
[Advertisement]
Do not use “Click here!” or any conceivable variant of it inside an
alt
or
title
! We know that it’s an advertisement already (you marked it as such after reading the preceding advice), and we’ll “click” if we feel like it.
You can add whatever brief, tightly-written marketing copy you wish inside
title
. I’m leaving this intentionally vague; my overriding concern is that you keep marketing copy
out
of the
alt
text. I suppose the advice I could give is “Boil down the marketing pitch from the site to which the ad links into a couple of sentences and add them in a
title
.”
Text-only ads, as seen on Google.com and Metafilter.com, self-evidently do not need any kind of special markup
unless
they include little images here and there, as with pictures of text reading “Textad information.” Use an
alt
text (
alt="Textad information"
), possibly also a
title
Copious examples are provided in the section entitled “Special ‘Advertising’ Supplement”
(not available in HTML; see
limitations
. Have a look at those.
Multimedia advertising
Now, then. The current scourge, as I write this, is the use of Flash and other animations in advertising, as though by annoying us even more we will somehow finally give in and buy the damned product. If you use the

element to mark up the Flash advertisement, you can include alternative texts and images right inside the element, a technique described at length in Chapter 13, “Multimedia.” You have no such options with the
embed
element. Accordingly, if you want to build an accessible Website, don’t use anything inside
embed
This advice will of course be unworkable if you are required to make your site function in Netscape 4, which tends to choke on the

element, or if your client simply demands to use Flash. Something’s got to give. I know perfectly well what will give in most cases, but you must acknowledge that it is my job to tell you the right way to do it even if I expect you actually will not.
The iframe solution
The little-known

element lets you set up a frame that floats “inline” (hence
frame) within your page. We should really add “iframe” as a generic term to our Web vocabularies alongside “frame,” since in some ways iframes are much more useful and are a far better idea than frames per se.
If you include an animated advertisement in an

element (used, for example, at NYTimes.com), you have ample opportunity to provide a wide range of equivalents. A generic but valid

tag, this time for a Saab car advertisement, resembles the following (though many other attributes are available):

Now, the source here (
src
) is typically an entire, self-contained HTML document, which in practical use will include a Flash movie or some other desperate and overwrought attempt to get the visitor’s attention. You can include a
title
, as with essentially every other HTML element. But

directly supports
longdesc
the way
img
does. I would strongly encourage using it.
What is little known is the fact that, rather like

, everything you place between

is
the alternate markup for any device that cannot understand or display the
src
file.
You thus have the best of all possible worlds:
You may use absolutely any form of presentation whatsoever in the iframe’s
src

itself carries intermediate and advanced access features (
title
and
longdesc
).
You have essentially unlimited space to provide multiple forms of accessible alternative content directly between

In the previous example:
The iframe
src
could link to a Flash animation documenting the glories of the Saab 9
sedan and wagon.
You could fill in
title
and
longdesc
You may use a QuickTime movie (with captions and descriptions if you want), and/or a GIF or JPEG still image with standard alternative texts,
and
any length of hyperlinked, styled, rich body copy within the full-fledged HTML document contained inside the

element.
Everybody’s happy. It’s a pretty good system. And yes, I quite insist you go to all this trouble. Iframe-based advertising is a lot of work already; it has the highest production values of any advertising form regularly encountered online (well, apart from self-contained sites that do nothing but advertise) and amounts to coding a whole other Website just to sell something. Budgets are generally quite high. As such, in the terminology used by this book, iframes are an advanced-level construct. Advanced HTML requires advanced accessibility. In any event, the accessible alternatives suggested here are inexpensive to create – particularly if you stick to still images and marked-up text.
Long descriptions
I will suggest you go ahead and use long descriptions in advertisements if you wish. I just hope you will use that facility for its intended purpose – to elucidate the visual appearance of an image, not to directly sell something. In the iframe example, the
longdesc
would explain what the advertisement
looks like

content would try to sell you the car.
Pop-ups and pop-unders
Pop-up advertising windows (that sit, by definition, on top of the window you really want to read) are actually less egregious than pop-under windows for a screen-reader user, but both of them cause undue complication.
Nondisabled visitors have to get rid of a pop-up ad before reading the actual desired window it obscures. This takes half a second, but is annoying.
Blind visitors cannot glance at the screen and instantly understand that a windoid has popped up. A screen reader may dutifully alter focus to the frontmost window, which in this case is an advertisement.
Accordingly, you absolutely must follow my instructions here and use an
alt
text that includes the word “Advertisement” in some form.
title
is virtually mandatory here just to make what’s going on understandable. Long descriptions are certainly not wrong. A screen-reader user will figure out that a new window has appeared; that part you cannot control or even assist with. What you must not do is make it difficult to figure out
what the window is
Pop-under ads are a bother for nondisabled surfers because they get in the way
later
: They sneak up on you when you’re trying to clear away unwanted windows. A screen-reader user is not disadvantaged at all in this context. Everyone is equally inconvenienced,
if and only if
the window content is accessible.
A low-vision person may well be able to figure out what’s going on with pop-up and pop-under windows without assistive technology.
alt
and
title
are still useful for this group.
A person with a learning disability like dyslexia may well be
especially
confused by the plethora of windows, with their attendant colour and possible animation, alongside standard “content” pages with their own text, graphics, and/or animation. I doubt you particularly care about this group, particularly since the only way to accommodate them with pop-up and pop-under ads is to cease their use.
See “
Spawned windows
” later in this chapter.
accesskey
values
The
accesskey
attribute, used to assign a keystroke to various elements, is exhaustively explained in Chapter 8, “Navigation.” It is not helpful to list the
accesskey
value inside an image
alt
text.
accesskey
helps mobility-impaired people more than blind people, and most mobility-impaired visitors will not have access to the
alt
text. The issue of making
accesskey
values actually understandable and usable to visitors is not easy in the first place, but this is the wrong way to do it. (See Chapter 8, “Navigation.”)
Animated GIFs
Use an
alt
that reflects the most representative frame – possibly the last (
alt="Children on the ferris wheel")
. Your
title
can mention the animation:
title="Kids enjoy a full revolution of the ferris wheel"
. A
longdesc
can describe the complete animation.
Arrows
Arrows, when displayed in text sizes, are a bit of a bother online because they are small and hard to work with. HTML actually contains character entities for arrows in four directions –
←
or
←
for left arrow
↑
or
↑
for up arrow
→
or
→
for right arrow
↓
or
↓
for down arrow
– but they are poorly supported. Knowing this, designers resort to little images instead. Your alternative text can use the HTML entities if you are brave, or you can swallow your pride and use ASCII-art-style equivalents,
alt="<-"
for left arrow and
alt="->"
for right arrow. Or you could just use less-than and greater-than signs.
ASCII art
If you’re an oldschool Usenet geek or an hepcat and like to make pictures out of printable characters, you must add a [Skip] link before the ASCII art. Otherwise screen readers will dutifully pronounce every damned letter. And we don’t
want
that. (See Chapter 8, “Navigation.”)
Background graphics and patterns
Page or table backgrounds do not need an
alt
text; it’s not part of the HTML standard. Do not even attempt it.
Borders, rules, and other meaningless graphics
Any graphic that actually means nothing requires
alt=""
. Examples include borders (including images jimmied together to form tabbed navbars); rules; images of rounded corners used to make a rectangular box look nicer; and repetitions of either meaningless or meaningful graphics (if your page features five occurrences of the same logo, handle the first one appropriately and make the rest of them disappear with
alt=""
). This is admittedly one of the tougher judgement calls to make, and you have to be ruthless with yourself. If heard in voice through a screen reader, in all honesty, do you need to know that particular graphic exists?
Bullets
Some Web designers use little graphics in place of true typographic bullets in itemized lists. My first advice is: Don’t!
True to this book’s espousal of full standards compliance, you should mark up lists as lists – in this case, unordered lists

. Just as you should use a heading code (

through

) rather than piling up a sequence of font tags to
simulate
the large type commonly used for headings, you should not code a sequence of paragraphs preceded by bullets that will typographically masquerade as a list.
Using cascading stylesheets, you may specify the appearance of unordered lists. Let’s consider the case where you the designer are
not
using an image as a bullet but are relying on the browser’s built-in list rendering. Stylesheets give you three options for visible bullets:
disc
(canonically, a filled bullet),
circle
(an outline bullet), and
square
(a filled square). You may write a stylesheet declaration of this sort:
ul { list-style-type: disc }
Typically, graphical browsers default to the equivalent of
list-style-type: disc
anyway, but it does not hurt to declare it explicitly, and it is a good idea for other reasons to be described momentarily.
If you want or need to use a decorative image bullet in your lists, cascading stylesheets make it possible. Use a style declaration along these lines:
ul { list-style-image: url(
image-URL
) }
According to Håkon Wium Lie and Bert Bos’s book
Cascading Style Sheets: Designing for the Web
(Addison-Wesley Longman, 1997), “If for some reason the browser is unable to download or display the image, it will use the
list-style-type
again.” Hence, to combine visual appearance, safety backup in case of a graphical-bullet file that cannot be located,
and
accessibility, use a style declaration like so:
ul {  list-style-image: url(
image-URL
); list-style-type: disc }
Or you may combine the declarations –
ul { list-style: url(
image-URL
) disc }
– which tells the browser to use the
image-URL
file by preference and a filled circle if necessary.
Even if you’re using
list-style-image
, the list retains its HTML structure as a list and can be read by adaptive technology. One notes that the HTML specification lacks any means whatsoever of assigning an
alt
text to the bullet replacement image, which surely is a failing, though one we can do nothing about. Also, paradoxically, you may use
list-style-image
with ordered lists

, which makes no sense at all. (Why order list items if they are not actually enumerated?)
If you absolutely must misbehave and engage in what I feel should be legally prohibited behaviour by using cutesy bullet-like characters in standard paragraphs, you are obliged to use an
alt
text. (You are so obliged with every
img
element, as you know well enough by now.)
Here you want the
alt
text to refer to the function of the graphical bullet, not its appearance. By convention, the
alt
text for graphical bullets is
alt="*"
(asterisk). If an asterisk is hard to type on your keyboard, use
alt="*"
or
alt="*"
You could experiment with encoding the actual bullet character, using
alt="•"
or
alt="•"
. Newer browsers will display the bullet character if the graphical bullet is unavailable, but screen readers may read out the word “bull” or the number “8,226.” Under no circumstances should you use
alt="[Bullet]"
alt="CIRCLE"
, or anything that attempts to describe the looks of the graphical bullet, like
alt="A small, 3D, spherical, red bullet"
(an actual example).
alt
texts encode
function
or
purpose
, not appearance.
Think about it: If you’re not loading graphics, instead of a tidy surrogate for a real bullet (the asterisk:
), you’re stuck with a whole word like “bullet.” A screen reader will actually read the word aloud, getting in the way of the structure of the itemized list.
Charts and graphs
I don’t have a lot of good news when it comes to charts and graphs that attempt to bring graphical form to numerical data. It is difficult to make the case that such illustrations cannot be rendered in text; most of the time they
derive
from numbers, which
are
text. But we use illustrations to make the numbers
more understandable
. We are undoing that process by rendering charts and graphs in words even if that is necessary for anyone who cannot see the illustration to understand it at all.
However, like packing, unpacking, and repacking a suitcase, once some numbers are rendered graphically, it is not always easy or straightforward to re-render that graphic in numbers (and words).
The first-level approach is pretty obvious: Use
alt
to tell us what the chart or graph is.
alt="HIV incidence among males 18 to 34, 1996"
alt="Sulfur emissions by state"
alt="Litres of water per capita (Africa)"
Do
not
, as ever, give us anything generic, like
alt="Chart"
or
alt="(graph)"
The only really useful advice I have for you is to load up the
title
attribute with the important or salient information the illustration is supposed to impart. In many cases, this will be impossible; the chart or graph attempts to visually impart many streams of interrelated data that resist distillation to a few words. But in a surprising number of other cases, the graph or chart is used to communicate a central idea, and you will usually be able to sum that up in a sentence or two inside a title:
title="13.6% spike in MSM cohort vs. 11.5% average spike"
title="Overall reductions, strongest in Ohio (down 3.6%) and Indiana (3.3%)"
title="Max: Republic of Congo (298,963); min: Tunisia (439)"
What about long description? Charts and graphs are in many ways the canonical use for
longdesc
. But as we’ll see in Chapter 11, “Stylesheets,” what the pie-in-the-sky working groups at the Web Accessibility Initiative think is possible and what is actually usable in the real world are two separate universes. An actual
WAI
example
(with an original error in URL corrected):

In
sales97.html
: A chart showing how sales in 1997 progressed. The chart is a bar chart showing percentage increases in sales by month. Sales in January were up 10% from December 1996, sales in February dropped 3%....
Apart from its clumsy repetitiveness, note that the authors conveniently avoid the dirty work of listing every single month’s sales through the mechanism of an ellipsis. The Web Accessibility Initiative cannot even be bothered giving us a full example showing all the work they want the rest of the world to do.
If you feel like being super-extra-thorough, yes, of course you may use
longdesc
to describe, in ravishing detail, the numerical or other factual and data underpinnings of your chart or graph. Just keep in mind that the typical “user” here will be stuck listening to all that data in sequence, or reading it via Braille display. To set it all up properly, you will have to use accessible table markup, a task so daunting it takes up nearly an entire chapter (10, “Tables and frames”).
As discussed
elsewhere
in this chapter, PopChart [D] by Corda (
corda.com/d/
), which automatically summarizes numerical charts and graphs, can produce a long description using
longdesc
and
set up a D-link.
Relatively uncomplicated charts and graphs can be handled with long description, but there are practical limits.
Comix
Comic strips – to use the hipster orthography,
comix
– are another of those seeming dealbreaker graphical forms that seem to be impossible to make accessible. In fact, it’s not hard: Just use the same techniques you would adopt in writing long descriptions.
In fact, you can write out the setting and dialogue in a
longdesc
, through
alt
s and
title
s, through imagemap area declarations, or any combination. In this example from Doonesbury, map coordinates are faked, but the approach works fine.
alt="Today’s strip" title="[Today’s strip]"
longdesc="todays-LD.html" usemap="#todaysmap" />

No, it’s not all that easy to read due to the absence of linebreaks in
alt
and
title
, but it’s passable.
Then you can make a separate
longdesc
file if you wish, named
todays-LD.html

Zonker and BD regard Ground Zero.

ZONKER: Wow... so this is it.

BD: Yup...

BD: I feel privileged to be serving here. Most of the guys got reassigned, but I’ve been here the whole time, battling looters!

ZONKER: Uh... battling looters? Really?

BD: OK, eating donuts. But people know – you loot here, you’re going down!

(Consistent with the advice given in Chapter 11, “Stylesheets,” and Chapter 13, “Multimedia,” I’ve used style declarations to mark up scene-setting and character dialogue. Optional but helpful.)
Moreover, if you’re handy with XML, you can make use of Jason McIntosh’s ComicsML set of document type definitions, available at
jmac.org/projects/comics_ml/
Company logos
Opinion is mixed on the right approach to a company logo. Here I’m referring to a decorative or identification logo that is not a link: It’s present just for “branding,” as the marketing types say. You can use
alt="
Company name
or
alt="
Company name
logo"
. For example,
alt="Kwik-E-Mart"
or
alt="Kwik-E-Mart logo"
. For a screen-reader user, there is modest added value in knowing that the item is a logo; there is no downside to including that single word.
Exploded, X-ray, phantom, or cutaway drawings
If, like me, you believe the best thing about cars is not in fact driving them but gazing in agape fascination at cutaway drawings of them, are you ever in for a disappointment in Web accessibility. As with charts and maps, the richness of visual information in what are variously known as exploded, X-ray, phantom, or cutaway drawings cannot be conveniently recapitulated in words. Generically, you could use
alt="Cutaway drawing of firefighter boot"
or equivalent. If you’re actually concerned with one detail of the illustration, you can point that out:
alt="Cutaway drawings show concealed tether anchorages (1997 model) and visible anchorages (2002 model)"
Graduated ratings schemes
If you use a thermometer, graduated color rankings, a rectangle that fills with colour to denote a proportion of a possible rating, or a fixed-size graphic whose colour changes in direct proportion to a rating assigned to it, use something simple like
alt="Ratings bar"
plus a plain text of the actual rating.
RottenTomatoes.com
and
Metacritic.com
use such systems, and handle them properly.
Now, if you’re a proud designer and you deliberately set up your page so that ratings are an analogue visual presentation only (just a partially-filled graduated rectangle with no associated number), this may be another case where you have to visibly modify your content. You must be able to articulate the graduated ratings allotment in words. If you aren’t doing that already, you’re going to have to start.
A more sophisticated approach: Add the actual rating value in the
alt
text, as
alt="Rating: 86%"
. You may or may not have a sophisticated enough back-end system to autogenerate such
alt
text. Then again, if your system can autogenerate the plain text I asked for in the preceding paragraph, why can’t it do the same in
alt
text?
The text equivalent of your visible rating allocation doesn’t have to be numeric.
alt="Warm"
"Hot"
"Cold"
"Tepid"
are imaginable possibilities. If your ratings system is somewhat cutesy (like a pink teddy bear with a ribbon in its “hair” who smiles or frowns her ratings), you are certainly entitled to come up with equivalently cutesy words:
alt="Blossom the Wonder Bear frowns with horror!"
"Blossom the Wonder Bear smiles quietly to herself!"
"Blossom the Wonder Bear gazes impassively!"
Hitcounters
You can download little pseudoprograms that count how many hits your page has received and display the number. Only a few are accessible through the
alt
attribute. The
right
way to do it is to produce an
alt
that renders the actual number, either by stitching together a set of
img
files with
alt
s (
alt="3" alt="3" alt="7" alt="9"
) or intelligently reading the number and serving up a single text (
alt="3379"
). Under battle conditions, we can live with
alt="Hitcounter"
. (
alt=""
would be wrong because a hitcounter is not a spacer or some other meaningless image.)
Only a few hitcounters
can
be accessible in the first place. Why? The code you use on your little homepage to produce one might actually be a Java applet that cannot be made accessible as easily as adding an
alt
to an
img
. (Java accessibility is one of the few topics I do not cover in this book. As explained early on, I know nothing about JavaScript and was not willing to fake it.)
Anyway, I mailed the owner of each and every English-language site in the Open Directory Project’s
listing of hitcounter providers
asking if their hitcounters were accessible in any way at all, even with
alt="Hitcounter"
or equivalent. Look at these sites for at least halfway-accessible hitcounters:
Web-Stat.com
, and
Freecounts.com
Identical
alt
and subsequent words
If the
alt
text of an image would duplicate words that immediately precede or follow the image, you may use an empty
alt
text. A typical example of this is an About Us page that shows little thumbnail photos of staff next to their names:

Ian
It is redundant and serves no accessibility purpose to write out the full
alt
(and indeed
title
) of the image using the same words that immediately follow:

Ian Northcote-Smith, shop steward, Local 217
It might be better to do something like this:

Ian Northcote-Smith, shop steward, Local 217 (empty
alt
and
title

Ian Northcote-Smith, shop steward, Local 217 (empty
alt
, but a bit of detail in
title

Ian Northcote-Smith (loading up extraneous information in
title
This approach is by no means wrong, and is, moreover, morally defensible under the Web Content Accessibility Guidelines. Checkpoint 1.1 says “Provide a text equivalent for every non-text element (e.g., via
alt
longdesc
, or in element content).” The “element content” bit refers to a case like

or

that can encompass alternative forms within themselves, but surely the same principle holds here: An
img
element (which cannot encompass anything or have “element content” because it is not paired) that sits right next to clear text that says exactly what an
alt
text would say has to be considered a valid text equivalent. If
alt=""
can be a correct text equivalent (it can), then
alt=""
followed by readable words has to be, too.
Images as links
Users of adaptive technology can tell what’s a link and what isn’t. It is generally redundant to preface an
alt
text with words like “Link to” (“Link to portfolio,” “Link to résumé”). Merely write an
alt
text as though the image weren’t a link.
Long
alt
There is no official size limit to an
alt
text, but convention holds that 1,024 characters (1 K) should be the maximum. In some browsers and under certain circumstances (e.g., Netscape 4,
encore et toujours
), a full
alt
text may not be visually displayed, or may not be displayed at all. Some other such circumstances:
The
alt
text is wider than the graphic. Netscape is often too stupid to wrap lines inside a graphic placeholder. (iCab on Macintosh attempts to show the
alt
in full on the status line if it is too wide for the allotted space.)
No size was specified for the graphic. An
alt
may not appear at all.
In Explorer version 4 and later under Windows, you can set preferences to display a full
alt
text in every case, though even then the browser will not necessarily show an
alt
text if it cannot fit inside the bounding box no matter how its text is wrapped.
Fonts are huge. If a visitor uses very large type sizes, even a few words may not fit in the bounding box. That’s why system-wide adaptive technology that magnifies everything is better than dialing up extra-big type; it’s likely that any visitor who can’t read a full
alt
text because fonts are too big is not actually visually-impaired but simply finds the body copy on the site too small.
Maps
Maps – not HTML imagemaps; maps in the conventional sense, as geographical maps, blueprints, floorplans, and the like – have remained an unsolved access mystery for decades. Blind people cannot see them, and Braille or raised or tactile maps are very rare and somewhat unwieldy; people with learning disabilities may find the density of lines, colours, and words incomprehensible. Some efforts have been made in using the accessible Scalable Vector Graphics (SVG) format to produce maps. Such efforts tend to do little more than crash this author’s browser. I must wearily conclude that typical maps cannot really be made accessible to the blind. A map of Europe that sighted readers are intended to use for general, undirected reference (i.e., “Look anywhere you want on this map for whatever information you’re looking for”) will probably be inaccessible until some sexy new technology comes along to solve the problem. Even in these cases, though, you must use markup along these lines:
alt="Map of Europe"
alt="Australia (geographical)"
alt="Map of the World (Mercator projection)"
alt="Map: Nunavut"
alt="Two views of Germany before division" title="Map shows East and West Germany in 1955 (left) and 1985 (right)"
This isn’t anything remotely like making the information in the map accessible, but you can’t just leave the
img
tag empty, now, can you?
On the other hand, more focused and topic-specific maps – like a map showing you where a small country like Malta or Andorra is in comparison to a larger known country – can be made reasonably accessible through
alt
and
title
alt="Malta is an island directly south of Italy in the Mediterranean Sea"
alt="Map of Andorra, France, and Spain" title="Andorra is nestled between France to the north and Spain to the south and east"
Now, what if your geographical or other map is also an imagemap? (For example, a map of districts of a city used to look up restaurant inspection records – an actual example here in Toronto.) Use standard imagemap accessibility techniques, and pat yourself on the back for having gone to all that trouble.
Mismatched languages
If you run a multilingual site or one with many variations in different languages, text equivalents must be translated. Some exceptions come to mind – product names and trademarks; phrases borrowed from some other language (
alt="Big Brother"
can be appropriate even in a French-language site if that is the name of the French-language show) – but they are unusual. Failure to translate text equivalents –
alt
title
, and
longdesc
, of course, but also content within

and

tags, for example – is an amateur error committed all the time by the world’s biggest, richest, smartest, and very often most American companies. Don’t let this happen to you.
Organizational and genealogical charts and flowcharts
Any organization whose hierarchy is extensive enough to require an actual chart probably has a hierarchy that cannot be adequately conveyed in words. As with charts and graphs generally, there’s a reason we’re using illustration, and the reason is we would spend the rest of our lives writing out relationships that can be immediately apprehended, in all their complexity, through a visual illustration.
The same applies to flowcharts, whether for an industrial process or information architecture or anything else. (See Jesse James Garrett’s “
visual vocabulary
” of IA iconography at JJG.net/ia/visvocab/.)
Outlines and hierarchies
The visual structure of an outline (e.g., topic threads in Usenet or another discussion forum) is rather difficult to make accessible. How do designers approach this problem in general? Commonly, designers attempt to show the levels of discussion hierarchy through indention: First post at flush left, first reply indented slightly, reply to
that
reply indented further. There are other indention styles, but the pattern is essentially identical.
These indentions are indicated by more than mere whitespace. Typically, we see little icons, like horizontal and vertical lines, to explicitly indicate the hierarchy.
If you’re using ordinary HTML text, like vertical bars and dashes of whatever sort, to create the outline structure, there is no accessibility problem because you aren’t using images, though there is something of a usability problem because a screen reader will dutifully read out text like
|---
as “bar dash dash dash dash.” Consider using styled HTML lists instead. This is not a vastly superior approach, I must admit.
If you’re using little
images
of arrows and vertical and horizontal lines (properly called “rules”), there is no obvious alternative to duplicating the appearance of the lines with
alt
texts containing vertical-bar and hyphen characters –
alt="|"
alt="-"
. I suppose you could use em dashes, namely
alt="—"
(imperfectly supported by browsers) or
alt="—"
(well supported, even by Netscape 4), but that may be over the top. Usenet old-timers will be aware that underscores and equal signs were also used to simulate horizontal lines, but I would tend not to use
alt="_"
or
alt="="
. We should stick to the convention that horizontal lines are approximated by hyphens.
I’ve never seen a case where the designer uses customized sets of images showing horizontal or vertical rules of specific lengths – one image file for single-character width, a second image file two characters wide, and so on. Instead, designers place uniformly-sized graphics next to each other to create a cumulative visual appearance. Of course, this means a number of identical
alt
texts sit alongside each other, which is a bother to deal with via adaptive technology. Each image may trigger a discrete audible rendering, one after another after another. A sequence like
alt="|" alt="-" alt="-" alt="-" alt="->"
may be read as “image bar image dash image dash image dash image dash greater than.”
There is a very slight theoretical advantage to using customized images of specific lengths because then you’re dealing with a single
alt
text even
if
it contains exactly the text of all the individual
alt
texts put together. Thus
alt="|---->"
may simply be read as “image bar dash dash dash dash greater than.” Not hugely better, but slightly so. Of course, this approach essentially requires you to program logic into your system that will substitute specific graphic files for each level of hierarchy, but on the other hand your system is
already
keeping track of the levels of hierarchy and substituting
multiples
of graphic files. If it is possible to put this option into practice, give it a try. Frankly, I expect you will be first in the world to do so.
Phonetics and mathematics
There is no practical way to make phonetic symbols or mathematical notation accessible. There does technically exist an XML-derived markup language for mathematics,
MathML
(see W3.org/Math/), which is quite poorly supported. In old media, there is such a thing as Braille for mathematics. I suspect more blind people interested in mathematics read Braille math than rely on MathML to understand online math. It’s rarely a good idea to reinvent the wheel; MathML exists and can be perfectly accessible to browsers and devices that understand it, but that is indeed the problem because so very few browsers and devices actually do understand it. Mozilla allegedly understands MathML, but in practice does not in my testing. And even if we had a Web browser that understood MathML, would a screen reader or other adaptive technology be able to turn the math into voice? (It’s hard enough for a nondisabled person to read math aloud in an unambiguous and understandable way.)
I suspect it will be some years before online math presentations become genuinely accessible. My sole recommendation is to use MathML where necessary. If you must include a math equation as a GIF (as a picture of text), you have a few options for alternate text. If the equation is lengthy or you just can’t be bothered, you can simply name the equation:
alt="Quadratic formula"
, which probably works better in the real world than
alt="(−b &plusminus; sqrt(b^2 − 4ac))/2a"
. If the formula is short, you can try typing it out in text:
alt="E=mc^2"
. It becomes a tad ridiculous, however, in short order, and you end up using spreadsheet-like functions that are themselves abbreviations or symbols.
Phonetic symbols – that is, International Phonetic Alphabet (IPA) or the many half-arsed variants used in American dictionaries – have no genuinely viable online presentation in the first place. Only professional linguists and lexicographers have phonetic fonts installed on their systems, and character mapping becomes a serious issue, so it isn’t sufficient to use whatever Unicode character entities may exist because they will almost never end up being rendered or presented correctly. If you use pictures of text, you are then stuck with the problem of writing a comprehensible
alt
text, which you essentially cannot do because that’s why we invented phonetic alphabets – to avoid writing “high back unrounded vowel” or “voiced pharyngeal fricative” for the rest of our lives. Nor can you epitomize IPA symbols in truly understandable ASCII text, though linguistics mailing lists do give it the old college try.
Photocomix
I am again using the hipster orthography. Comix made entirely of photographs are a bit of an acquired taste and are rather rare even in the print medium. But for a visitor who cannot see the photographs, the fact that they are indeed photographs may be irrelevant. Treat the page exactly as if it were composed of drawn or illustrated images.
Certainly a case can be made that photocomix are different from the expected norm, and that’s the sort of thing I’ve suggested you notate. So here’s a nice additional touch: Surround the photo layout in a
div
tag that explains the content is in fact photographic:
div title="(All images photographic, not hand-drawn)"
Pictures of text
Some designers set words in type using Photoshop or moral equivalent and save those words as graphic images (
pictures of text
). Sighted visitors can read them; screen readers and browsers that don’t display graphics cannot. In these cases, an
alt
and a
title
must be provided.
For small amounts of text (typically, text rendered as graphics is used for navigation buttons), enter the complete text into
alt
; you can add explanatory details to
title
if you wish. (Example:
alt="Contact" title="Contact information, job listings, and feedback page"
.) Accessibility purists may hate this entire approach, but I simply do not see any harm whatsoever in limited bits of text rendered as graphics since it is dead simple to make those graphics accessible. I use pictures of text myself.
If you use a graphic image as a drop cap at the outset of a paragraph, use the tiniest
alt
text possible – give us nothing but the character rendered by the drop cap, like
alt="C"
. If your drop cap is actually a sentence or a phrase (e.g., a dateline) or a couple of characters, include those verbatim, but a drop sentence or drop phrase of this sort barely resides in the same category as a true drop cap.
You may wish to emulate the case of the original graphic for verisimilitude: If a dateline on a news article reads “REGINA” in uppercase in the graphic, use
alt="REGINA"
. If the word
is used, you may wish to include a space or non-breaking space (
 
) in the
alt
text to signify it is a separate word:
alt="I "
or even
alt="I "
If your drop cap includes a visible quotation mark, encode it inside the
alt
using either
"
or
"
(for a tacky neutral quotation mark) or a numeric or literal entity, like
“
or
“
for
or
‘
or
‘
for
Understand, though, that screen-reader users will be inconvenienced by the use of a drop cap. It simply breaks up a word. The following do not have the same effect:
The word
Bread
The sequence
read
Quite obviously, adaptive technology cannot read the latter example as a full word because it consists of an image followed by a series of letters. The visitor will end up hearing something like “bee reed” (keeping in mind that “read” has two pronunciations), and indeed there may be some other audible signal that an image has been encountered, producing an audible sequence like “[
Click
] bee reed” or “image bee reed.”
A visitor with a Braille display may be much less inconvenienced; the sequence may be rendered as “b read,” which is not great but not so bad, either.
Don’t use a
title
on a drop cap, unless, I suppose, it’s more of a drop sentence or a drop phrase. A
title
on a one- or two-character drop cap is gilding the lily;
alt
already fully explicates the function of the graphic.
Extensive
text rendered as graphics is another story. Using graphic images to typeset large blocks of text is a miserable idea. For large blocks of text, experiment with either filling
alt
and
title
with the verbatim text or summarizing the text briefly in
alt
and listing it verbatim in
title
longdesc
is at best marginally useful here since it is poorly supported and requires you to load a whole new page. The best approach is to slice up your graphic with its extensive text into subgraphics with more manageable quantities, providing
alt
and
title
for each.
There is no need for an exact match between the image blocks and the text used in
alt
s. You can create convenient rectangular slices even if you split a sentence in half. You can place the text of the whole sentence in one of the two
alt
texts and/or
title
s. A reasonable correspondence is in order, but you don’t have to make the visible picture of text and the computer-readable alternative text exactly the same – as long as, when all alternate texts are read, they correspond exactly to the text available in pictures.
Another option, one that is legal in HTML but rather oddball, is to use the
area
element typically found in the creation of imagemaps. In that typical case, you associate URLs with specific regions through an
href="
URL
attribute. But it is possible to associate an explicit
lack
of URL with a specific region using
nohref="nohref"
; that region can simultaneously carry an
alt
and a
title
. (This technique, when employed at all, is normally used to carve a hole or link-free region out of an imagemap.)
In this way, you can use a large single image divided into an imagemap that will pass through multiple
alt
s and
title
texts to a browser or device – not that it’s worth the trouble in the first place. In the following example, we will attempt to render the following mass of text (an actual example taken from Descartes.com) as a GIF image:
In response to globalized trade and increased competition, organizations have chained together processes for faster times to market and lower customer costs. This new business model is built from:
Supply-chains
Logistics-chains
Demand-chains
Value-chains
Customer-chains
Even Profit-chains!
Descartes calls them nChains, where the “n” means whatever the organization wants it to mean. To be competitive, organizations need to more effectively manage their nChains by managing events and critical moments between trading partners. This is a complex process – hundreds of different trading partners, with different ways of communicating and data formats. Only a network can effectively, privately and securely handle it. Our collaborative network helps organizations manage their business processes to their plan, while identifying and proactively handling the divergent off-plan events. It’s called nChain Event Management.
Note the complexity of the task, and how ill-suited the use of text rendered as graphics really is. As in the pure-text rendering above, the copy cries out for multiple paragraphs and an unordered list, all of which is easy to do in HTML, easy to visually simulate in a graphic, but next to impossible to duplicate using
alt
and
title
. I’m hoping this example, taken from the real Web, will prove so unpalatable that you will never attempt to render this much text as a graphic image.
On with the show. In the HTML syntax below, all numerical values are simulations and will not actually work. You will get the idea nonetheless, I’m sure.


Note that I had to fake the unordered list by stringing its components in a phrase divided by vertical bars – one of many strikes against this technique. Frankly, the whole exercise of rendering extensive text as graphics is so much trouble I don’t know why anyone would bother. Styled HTML text is quicker, easier, and more accessible for long segments of copy. Use it.
Stylesheets give you considerable control over the appearance of text; the use of actual fonts on the visitor’s computer may make for a better appearance anyway (antialiasing will likely be turned on); text rendered as bitmaps is invisible to search engines and enormously difficult to update. (What if you misspell a word? Or at least mistype one?)
Porn
I’m not exactly in a position to ignore “adult” Websites since I do in fact have my own personal favourites. For all navigational, design, and identity graphics, there is no alteration in accessibility practice. For the actual photographs and illustrations of interest, I advocate treating the page like a portfolio site (see advice for that application). I suppose this advice applies mainly to commercial sites.
If you’re running a ratings site of the “
Am I Hot or Not
?” variety (HotorNot.com) but more explicit – two examples are
RateaRod.com
and
RateaRear.com
– then the
alt
text for submitted photos may end up being inane and/or annoying, like
alt="Rate this member!"
Porn cannot always be taken seriously. Accessible porn may end up being even slightly more ridiculous.
Now, if your porn page carries on a kind of narrative (either in a photocomix style or in a sequence of written segments and pictures), you are in for a tough slog. You have to make the narrative work comprehensibly in text alternatives (I would certainly use
title
and
longdesc
at this point); if the page is a mix of paragraphs and pictures, you have to avoid repeating yourself in text equivalents for the images. In essence, if you select a photograph because it communicates something that words cannot, or if you are setting up an antiphonious relationship between words and pictures, you’re going to have to devise a way to make everything work in words.
(If you think this is extraneous, please don’t. In a
survey
of attitudes and responses to audio description of TV and video, the American Foundation for the Blind found that some respondents would indeed like to watch audio-described X-rated films. In one poll as part of this single survey, 9% of respondents voiced that preference; in another poll, 22%. Men wanted described adult films more often than women. The mind fairly boggles as to how this would actually be done, but the desire is there. And certain broadcasters in the United Kingdom are required to audio-describe a portion of their programming; “adult” programming is not, in fact, exempt, so all this may actually come to pass!)
Portfolios, stock photos, clip art, typefaces
What if you are an artist showing off your portfolio of photography, graphic design, illustration, sculpture, Web design, or anything else?
What if your company is in the business of selling stock photos or clip art or typefaces – or anything else graphical?
In extreme cases – like the near-duopoly of American stock-photo agencies, Corbis and Getty Images – designers and programmers are faced with making hundreds of thousands of images accessible. This constitutes undue hardship under any sane interpretation.
However: A site with a few dozen or even a hundred or so images can be made quite accessible, and even the extreme cases have certain options.
In all these cases, you can simply use something like the following for all sample images:
alt="Sample photo"
alt="Sample"
alt="
Font name
sample"
(for typeface showings)
Rudimentary. Possibly even undesirable in a strict interpretation of accessibility. But far better than an image with no alternate text at all. Any content-management system worth its fees should be able to automatically populate such quasi-generic
alt
texts through the images of a site. It may be practicable to insert them only when they are called up from the database rather than methodically thrashing through the database and adding them in advance.
Now, if, upon sober and realistic self-evaluation, you know perfectly well that you do not have
so
many sample images that you can’t do them justice, I encourage you to use more specific and descriptive
alt
s,
title
s, and
longdesc
s. After reading this chapter, you already know how to write them. It merely becomes an issue of slogging through all the available files. And when you add new samples,
always
include accessibility.
As in other facets of making sites accessible, you can phase in retrofitting of this sort. You can work on one page a week, in decreasing order of popularity according to your Web server logs. Or you could convert all your most popular pages immediately and pick away at the rest according to a schedule. (Do keep to a schedule, otherwise you will procrastinate and nothing will get done.)
In every case, make
all
images on a page accessible. If, for example, your three most popular images are spread across three separate pages, then you must retrofit those entire pages to make them accessible. That should come as no surprise by this point.
If you really feel you cannot make your many portfolio or sample images accessible, understand that you will incur my scorn, which will in turn be leavened if you make very sure that every
other
part of
all
your pages is accessible. This is not particularly difficult to do given that typical portfolio sites are created with page templates; when pages are handrolled, they are usually so few in number that fixing them by hand cannot be considered an undue burden.
Long descriptions are clearly applicable to portfolios and samples, but the labour involved is a deterrent.
Font samples are a special case, I think, due to the many levels of specificity at work (typeface family and variant; differentiation from other fonts; individual characters). For complete alphabet showings,
alt="
Font name
sample"
is quite functional. When comparing one font to another, say so:
alt="Univers vs. Helvetica" title="Univers (top) has a point on its lowercase t. Helvetica (bottom) does not"
. When giving closeups of individual characters, tell us as much:
alt="New Century Schoolbook Q"
Rating stars
If your site reviews cultural works or anything else and uses the rating-star system of the print world, you have a few options:
alt="[Star]"
alt="*"
(or the usual character entities for the asterisk,
alt="*"
or
alt="*"
alt="[Rating star]"
I suppose I am being slightly inconsistent here given that I am suggesting you use brackets in your
alt
text. I tend to advocate that practice only for
title
s when
alt
and
title
have the same text. My reasoning here is that a rating star is one step removed in abstraction from an asterisk used as a genuine asterisk or a bullet. I suppose this is not an airtight case.
The best way to do it? Reprogram your system so that you use individual graphic files for each level of rating: A one-star film uses a single graphic showing one star, a five-star film uses a single separate graphic showing five stars, a three-and-a-half-star film has its own graphic, and so on. Then use equally specific
alt
texts:
alt="One star"
alt="5 stars"
(use numerals if you wish)
alt="Three and a half stars"
Or, if you’re using stars in the first place, why not just use asterisk characters in plain text?
Repeated graphics
Another judgement call: If a page (not a site, a page) shows the same graphic several times, it is usually wisest to deal with the first or most important instance appropriately (with a descriptive
alt
text or with
alt=""
) and treat the rest of them as extraneous (with
alt=""
). The same advice applies to graphics that differ by unimportant details – for example, blue logo at top, green logo at bottom, both of which are intended to mean the same thing, or a picture-of-text logotype at top giving the full name of your site and another logotype at bottom reducing the name to an acronym.
Rollovers
All states of a rollover must be accessible. While editing this very chapter (actually, while procrastinating
before
editing this very chapter), by pure chance I happened upon a page at Doonesbury.com in which all of the following were true:
Even with graphics-loading turned on, the top-of-page banner ad was missing. The server could not find the image file.
That banner had no
alt
text.
The
rollover
for that banner could not be found either, but it
had
an alt, which, brilliantly enough, merely read “Click here to find out more!” (Wow!)
It was thus possible to cause an
alt
text to appear and disappear by moving the mouse onto and off the rectangle that, through incompetence or error, failed to display an advertisement.
How’s
that
for stupid?
Every image requires an
alt
text. “Every” really means “every,” including rollover states.
Rules and dividing lines
HTML offers an element for horizontal rules,

---

, which you can format in varying thicknesses and colours using cascading stylesheets. Since

---

is an actual element, use it in preference to any other technique; adaptive technology can read the presence of the rule and interpret it properly. (Don’t let anyone tell you horizontal rules provide no structure. Of course they do. Once you hit a

---

element, you suddenly have a dividing line between Before and After or Above and Below.)
If you really must, you may use graphic images for horizontal or vertical rules – usually done for a “better” appearance. For horizontal rules, use
alt="--"
so it will resemble a horizontal line in a graphical browser and be read as a line in a screen reader. Limit yourself to two or maybe three hyphens; don’t just hold down the hyphen key on the keyboard and fill up the full width of your editing program’s text window.
There seems to be an issue of scale among
alt="-"
alt="--"
, and
alt="---"
. I suppose you could selectively deploy each of those depending on the width of the horizontal rule you are attempting to encode.
Vertical lines have a different structural intent, usually encoded in HTML tables or frames and rendered by default in graphical browsers. Let the tables or frames embody that structure (see Chapter 10, “Tables and frames”); it is possible, with a great deal of fiddling, to control the display of table and other borders via stylesheets.
Otherwise, use
alt=""
for other vertical rules. If you look critically at vertical rules as used on real-world Websites, they are generally optional; some other structural cue (like columns, as expressed in all-stylesheet layouts or table cells) will nearly always remain in place even if you remove the rule. Frankly, most vertical rules added to a page through the
img
element have no meaning unto themselves.
Don’t use a
title
or
longdesc
. Exception: If your page is all
about
rules (if you’re giving them away in the form of graphic files, for example, or teaching designers how to use them), then use
alt
title
, and, if absolutely necessary,
longdesc
to explain the visual differences between the graphics.
Search and login fields
If you use a graphical button next to a type-in textarea in your search function – you know, the kind that says “Go” or “OK” in a picture of text – obviously that image needs an alt text. There are certain peculiarities with button types that are documented in Chapter 12, “Forms and interaction.”
Secret passcodes
To thwart spammers and the like, some sites provide secret passcode numbers (they’re almost always numbers) in graphical images. You are expected to look at the number, understand it, and retype it into a certain field. This practice
relies
on inaccessibility – on the fact that images are not machine-readable. It’s got to go. It isn’t sufficient to provide a little message saying “If you are unable to view this passcode, send E-mail to technical support.” That isn’t equivalent access, and it is quite simple for a spammer to simply dispatch an automated E-mail reading “I’m legally blind and I can’t access your site. Can you give me the passcode in clear text?”
On the other hand, the solution I offer, while only marginally more resistant to misuse, at least qualifies as an accessibility provision: Split the passcode up into one image per digit and give the
name
of the digit in the
alt
text:





(You could also use numerals inside the
alt
text.)
The
alt
text is of course computer-readable, leaving you open to spam. But reasonable security provisions are provided here: You can store large numbers of identical numerical images with different and unpredictable filenames and serve them up randomly. A spambot would have to spider your site at unfeasible length in order to learn them all, requiring too much programming time for many penny-ante spammers. If you set up your Web server’s file permissions to prohibit mass downloading of entire folders, a spammer would also be unable to read in all your digit image files and develop a database to crack this system.
For numerical passcodes, you can also save
alt
texts that represent variable lengths of digits: You could render
37935
as “three seven nine-thirty-five,” “thirty-seven thousand nine hundred thirty-five,” “thirty-seven nine thirty-five,” or any other combination.
For alphabetic passcodes, I have no solution. I suppose you could write the names of letters phonetically (ay, be or bee, see, dee, ee, eff, gee or jee, aitch, eye, jay, kay, el, em, en, oh, pee, kyoo, are, es or ess, tee, you, vee, doubleyou, eks, why, zed or zee), but let’s not turn Web accessibility into the delirious mutterings of the Katzenjammer Kids.
Self-captioning photos
A newspaper site may run an editorial photo whose caption or cutline fully explains the contents of the photo. In those cases, it is redundant to use anything beyond a basic
alt
text:
alt="John and Joan Cusack"
is sufficient when the photo cutline, marked up as an ordinary paragraph or table cell, reads: “Knockout brother-and-sister one-two punch John and Joan Cusack pose for photographers on the runway outside the Dorothy Chandler Auditorium. John Cusack’s feature comedy,
Grosse Pointe Blank
, was shut out of this year’s Academy Awards.”
Sliced graphics
Authoring programs let you divvy up a large image into an interlocking jigsaw of smaller rectangular slices. Less is more here. Select a single slice that will epitomize the entire image. Use
alt=""
for every slice but that one, which you will treat differently.
If you were viewing the page under difficult conditions and could load only one slice to understand the meaning of the entire graphic, which would it be? Take
that
image and give it a full descriptive
alt
and
title
(even a
longdesc
, if desired) that describes
the whole assemblage of all slices
. The Chosen Slice is a proxy for the entire image.
If you are tempted to strew marketing slogans in every
alt
text but the Chosen One, don’t; the alternative text has to be genuinely related to the image. Nothing, save for the constraints of good taste, stops you from doing that with
title
s. By the way, I suppose it is possible that a very complex sliced graphic could require more than one slice with full
alt
and other text equivalents, but don’t overdo it.
Spacers
Because it is so difficult to control horizontal and vertical spacing in Web pages (yes, it’s still difficult even with stylesheets), a standby technique designers rely on is the use of very thin graphics files to provide the appearance of spacing on a page. They’re usually saved as transparent GIFs (or in rare cases, as the same colour as the background) and thus appear invisible – as they should, given that they’re meant to represent space. Nonetheless, as graphics, they require
alt
texts, and there’s only one option here:
alt=""
. Yes, an empty
alt
text.
Why not just leave the
alt
text out? Because then your visitor will be faced with the filename, either visually or audibly. With
alt=""
, a graphical browser that can’t load the image will show nothing but a placeholder. (If the designer included
height
and
width
attributes, the browser might end up showing the right amount of space.) A screen reader will skip the image completely or will, at worst, indicate an image is present; I suppose it is hypothetically possible that this might confuse the blind visitor, but you will have gone to some length to avoid
actual
as opposed to hypothetical confusion.
For the purposes of this book, incidentally,
alt=""
will nonetheless be considered an
alt
text. Using an empty
alt
text can be and is appropriate in
img
elements; omitting an
alt
text is never permitted. (It’s akin to the distinction between having no money in a bank account and having no bank account at all.)
In using empty
alt
s, an issue comes up: Placeholder icons. I have never met a graphical browser yet – and I’ve been using them since the first versions of Mosaic and Netscape version 0.9 – that did
not
use a little placeholder icon to represent a missing image. But in my experience, browsers use that same icon for all the following cases:
No
alt
alt=""
(empty)
alt=" "
(space – indeed, any number of spaces)
alt=" "
(non-breaking space – indeed, any number of them)
The only difference I could find is vertical positioning of the visible manifestation of the placeholder icon (the little
in a red box, for example) within the space allocated for the image, which is too subtle to notice most of the time.
If you’re testing your pages with graphics loading turned off, you may be misled by the appearance of placeholder icons. You may be tempted to conclude that those graphics lack
alt
texts. That is not necessarily true; you need to examine the source code. It follows, then, that when evaluating the accessibility of other people’s work, you cannot rely on the appearance of a site in a graphical browser with image-loading turned off. Even perfectly legal techniques like
alt=""
have essentially the same appearance as illegal techniques like missing
alt
texts. Consequently, do not fire off angry E-mails to site authors accusing them of foisting images without
alt
texts on an unsuspecting public purely on the basis of a site’s appearance with image-loading turned off.
Spawned windows
Just as a general principle, warn all visitors when a new window will open.
If an image that is also a link opens in a new window (by adding
target="_blank"
to the

element), then warn us in advance:
alt="Sunrise at Darling Harbour (larger image opens in new window)"
. Depending on your personal style, it is not impermissible to use a
title
instead to explain that the link opens in a new window.
Status bars
Similar to graduated ratings indicators, a graphical status bar that indicates where you are located in a process through imagery must be translated into plain text.
alt="Your order status: Being assembled"
is sufficient. A
title
or long description could explain all the possible steps. Really, what you’re interested in is where you sit now, not what the entire range of options might be.
Thumbnails
It’s good practice to provide bite-sized versions of large photographs and graphics. As seen in online photo galleries and albums, thumbnails are very often links to full-sized illustrations, making them another example of images-as-links. Write an
alt
text that sums up the image
and
tells you it’s a link to a larger version, as with
alt="Sunrise at Darling Harbour (link to larger image)"
or
alt="Sunrise at Darling Harbour. Click for full-sized version"
Web bugs
Late in the previous century, a quasi-sinister new technique emerged to track the loading of Web pages. A minuscule graphic, like a single-pixel GIF, triggers a cookie that is sent back to another server (usually an advertiser’s or an advertising broker’s). As a BBC report explained, “The HTML code hidden in the image can request additional information from that computer or the past visits to that site. The Web bugs can mine information about who owns the site you are surfing from as well as details about your computer such as what data is held in the Windows registry [if applicable].” Is it fair to speculate that designers with no ethical qualms about including Web bugs are not all that concerned with standards compliance or accessibility? Nonetheless, if you are somehow required to make such a page accessible, treat the Web bug as a spacer image and use
alt=""
Webcams
Webcam software isn’t smart enough to be accessible. Ideally, you should be able to attach
alt
s to images transmitted at different times of the day:
alt="Me at my desk"
alt="I’m away at lunch"
. In an ideal world, you could link a different
alt
to every frame, but that would be above and beyond the call of duty.
Until Webcam software wakes up to accessibility, if you have any ability to rewrite the coding inserted by the Webcam software, use an
alt
and a
title
longdesc
may be rather too much to hope for. Engage the same rules as ever:
alt
sums up the function,
title
tells you more, and
longdesc
attempts to document the full appearance of the image, which in this case could describe the
kind
of Webcam image a visitor would see. For example,
alt="Daily Webcam" title="Webcam is on all day while I’m at my desk"
A long description could run like this:
My Webcam runs all day when I’m at my desk – a typical cubicle here at Wonderworks in Fredericton. I have a black Æron chair (an ergonomic chair with nylon netting for upholstery) and a flatscreen PC on my desk. If you see a pale blur in the image, that’s me – I’ve got blond hair and fair skin and I tend to wear a white T-shirt to work unless we’re meeting a client or something. I also have a Webcam

at home

If your Webcam software lets you hack its code to include an
alt
and/or
title
, do it. If not, then your Webcam could be the only image on your page that is inaccessible. I suppose the options then are to live with it (antithetical to the purpose of the exercise), switch software (requiring the nontrivial task of chasing down an accessible alternative), or pester software makers until they upgrade the program.
What about Scalable Vector Graphics?
In 2001, the World Wide Web Consortium ratified a “recommendation” on Scalable Vector Graphics or SVG, a Flash-like graphics format that includes a raft of features for accessibility. SVG objects can include a range of text and other equivalents. You may be wondering why I’m not documenting this raft of features. Simple: As with JavaScript and PDF, I know essentially nothing about SVG, and I won't pretend to be able to learn it all quickly to do a proper job in this book.
More importantly, support for SVG in real-world devices, even something as simple as the browser that ships with a nondisabled person’s brand-new computer, is so poor as to be essentially nonexistent. For the time being, SVG is vapourware.
Bottom-Line Accessibility Advice
Basic accessibility
Use
alt
texts on absolutely every image without exception.
Intermediate accessibility
Add
title
s to images in increments no smaller than a page: Either all graphics on a page contain
title
s or none.
Advanced accessibility
Write long descriptions for the rather more intricate images.
Previous
Contents
Next