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). Copyright © 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:

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:

<img src="sunset.gif" width="400" height="300" />

The parts are:

In this inaccessible example:

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:

<img src="sunset.gif" width="400" height="300" alt="Sunset over Darling Harbour" />

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:

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 <area></area> 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 titles 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 <img src="sunset.gif" width="400" height="300" alt="Sunset over Darling Harbour" /> as an example, you could add one of the following titles:

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.

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 alts for an entire page, stick with that.

If you hate titles, 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 titles 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 titles 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 titles. 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.

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:

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.

A 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:

<img src="sunset.gif" width="400" height="300" border="0"
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:

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:

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.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="en" lang="en">
<head>
<title>Long description for sunset.gif</title>
</head>
<body>

<p>At dusk, the sun&#8217;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.</p>

<p>Back to the <a href="photoalbum.html#sunset" title="Photo album">photo album</a>.</p>
</body>
</html>

Let’s consider the structure of the file.

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 <a></a> link. Different circumstances may warrant different usage.

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 longdescs 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.

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:

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 <table></table>, 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:

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 D for Description (rendered any way you want to write it – D, [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 <a href="imagename-LD.html" title="Long description of image">D.</a> 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 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.

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 <object></object> 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 <object></object> 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 <iframe></iframe> element lets you set up a frame that floats “inline” (hence iframe) 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 <iframe></iframe> element (used, for example, at NYTimes.com), you have ample opportunity to provide a wide range of equivalents. A generic but valid <iframe></iframe> tag, this time for a Saab car advertisement, resembles the following (though many other attributes are available):

<iframe src="95ad.html" longdesc="95ad-LD.html" width="160" height="600"
title="3.9% APR on all new 9-5 sedans and wagons till November 2002">
</iframe>

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 <iframe></iframe> directly supports longdesc the way img does. I would strongly encourage using it.

What is little known is the fact that, rather like <object></object>, everything you place between <iframe> and </iframe> is the alternate markup for any device that cannot understand or display the src file.

You thus have the best of all possible worlds:

In the previous example:

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; <iframe></iframe> 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.

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 –

– 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="&lt;-" for left arrow and alt="-&gt;" 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 <ul></ul>. Just as you should use a heading code (<h1></h1> through <h6></h6>) 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 <ol></ol>, 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="&#42;" or alt="&ast;".

You could experiment with encoding the actual bullet character, using alt="&bull;" or alt="&#8226;". 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.

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:

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):

<img src="sales97.gif" alt="Sales for 1997" longdesc="sales97.html">

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 alts and titles, through imagemap area declarations, or any combination. In this example from Doonesbury, map coordinates are faked, but the approach works fine.

<img src="http://images.ucomics.com/images/doonesbury/strip/dailydose/images/todays.gif" border="0"
alt="Today’s strip" title="[Today’s strip]"
longdesc="todays-LD.html" usemap="#todaysmap" />

<map name="todaysmap" id="todaysmap">

<area shape="rect" coords="0,0,100,250" href="nohref"
alt="Zonker and BD regard Ground Zero. ZONKER: Wow... so this is it. BD: Yup..."
title="Zonker and BD regard Ground Zero. ZONKER: Wow... so this is it. BD: Yup..." />

<area shape="rect" coords="101,251,200,500" href="nohref"
alt="BD: I feel privileged to be serving here. Most of the guys got reassigned, but I’ve been here the whole time, battling looters!"
title="BD: I feel privileged to be serving here. Most of the guys got reassigned, but I’ve been here the whole time, battling looters!" />

<area shape="rect" coords="202,502,300,750" href="nohref"
alt="ZONKER: Uh... battling looters? Really?"
title="ZONKER: Uh... battling looters? Really?" />

<area shape="rect" coords="303,753,400,850" href="nohref"
alt="BD: OK, eating donuts. But people know – you loot here, you’re going DOWN!"
title="BD: OK, eating donuts. But people know – you loot here, you’re going DOWN!" />

</map>

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:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en">
<head>
<title>Today’s strip</title>
</head>
<body>

<p class="scene">
Zonker and BD regard Ground Zero.
</p>

<p class="dialogue">
<span class="zonker">ZONKER</span>: Wow... so this is it.
</p>

<p> <span class="bd">BD</span>: Yup...
</p>

<p> <span class="bd">BD</span>: I feel privileged to be serving here. Most of the guys got reassigned, but I’ve been here the whole time, battling looters!
</p>

<p> <span class="zonker">ZONKER</span>: Uh... battling looters? Really?
</p>

<p> <span class="bd">BD</span>: OK, eating donuts. But people know – you loot here, you’re going <em>down</em>!
</p>

(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 alts (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:

<img src="ian.JPG" />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:

<img src="ian.JPG" alt="Ian Northcote-Smith, shop steward, Local 217" title="[Ian Northcote-Smith, shop steward, Local 217]" />Ian Northcote-Smith, shop steward, Local 217

It might be better to do something like this:

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 <iframe></iframe> or <object></object> 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 alts

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:

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:

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:

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 <object></object> and <iframe></iframe> 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="&mdash;" (imperfectly supported by browsers) or alt="&#8212;" (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="(&minus;b &plusminus; sqrt(b^2 &minus; 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 I is used, you may wish to include a space or non-breaking space (&nbsp;) in the alt text to signify it is a separate word: alt="I " or even alt="I&nbsp;".

If your drop cap includes a visible quotation mark, encode it inside the alt using either &quot; or &#34; (for a tacky neutral quotation mark) or a numeric or literal entity, like &ldquo; or &#8220; for “ or &lsquo; or &#8216; 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:

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 alts. 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 titles. 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 alts 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:

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.

<img src="../images/nchain.gif" width="400" height="500" alt="nChain Event Management" title="What are nChains?" usemap="#nChainmap" />

<map name="nChainmap">

<area shape="rect" coords="31,266,188,294" nohref="nohref"
alt="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:"
title="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:">

<area shape="rect" coords="31,295,188,322" nohref="nohref"
alt="Supply-chains | Logistics-chains | Demand-chains | Value-chains | Customer-chains | Even Profit-chains!"
title="Supply-chains | Logistics-chains | Demand-chains | Value-chains | Customer-chains | Even Profit-chains!" />

<area shape="rect" coords="31,323,188,350" nohref="nohref"
alt="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."
title="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." />

<area shape="rect" coords="31,351,188,378" nohref="nohref"
alt="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."
title="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." />

<area shape="rect" coords="31,379,188,406" nohref="nohref"
alt="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."
title="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." />

</map>

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:

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 alts, titles, and longdescs. 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:

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 titles 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:

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:

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, <hr />, which you can format in varying thicknesses and colours using cascading stylesheets. Since <hr /> 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 <hr /> 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:

<img src="num207.gif" alt="three" />
<img src="a318.gif" alt="seven" />
<img src="hur_1.gif" alt="nine" />
<img src="num207.gif" alt="three" />
<img src="l33t.GIF" alt="five" />

(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 titles. 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 alts, 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:

The only difference I could find is vertical positioning of the visible manifestation of the placeholder icon (the little X 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 <a></a> 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 alts 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 <a href="http://www.nbnet.nb.ca/bruceg/cam/" title="Webcam at my personal site">at home</a>.

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 titles to images in increments no smaller than a page: Either all graphics on a page contain titles or none.

Advanced accessibility

Write long descriptions for the rather more intricate images.

Previous   ¶   Contents   ¶   Next