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 stri