Navigation

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

Web designers, information architects, usability experts (or, as I like to call them, “usabilitistas”) – everybody’s got an opinion on navigation, the simple act of getting around on the Web. I will bite my tongue and attempt to remain descriptive rather than prescriptive in this chapter, which will teach you how to make the navigation systems we find in real Websites accessible.

If making images accessible is more than half the battle (as claimed in Chapter 6, “The image problem”), accessible navigation takes care of another disproportionate chunk. Since the Web is a system of interconnections, the fact that navigation systems on commercial sites are so often based on graphic images means that making the images accessible usually makes the navigation accessible right away.

All your navigation has to be accessible. Getting to that point with oldschool HTML is often clumsy, while the use of newfangled HTML that was defined specifically for accessibility brings up incompatibilities. The coding process of accessible navigation, if not the actual result, is quite often unbeautiful and adds another level of complexity. But we’re all grownups here. We deal with unbeautiful HTML every day of the week (our coding is seldom as compact and elegant as something like E=mc2, is it?), and you knew all along that accessibility added new wrinkles.

Philosophy lesson

I suppose this is as good a time as any to broach the intractable philosophical distinction between usability and accessibility. Certainly, thousands of Gitanes have suffered smouldering deaths as bands of intellectuals, wearing dramatic rectangular eyeglasses and sporting just the right handbags and mock turtlenecks, spend countless hours debating the fine gradations of differences between one discipline and the other. (Can you imagine being stuck at the adjoining table, forced to listen?)

What, then, is usability? It is the practice of designing Websites so visitors can do what they wish without undue impediment. (Some impediments are necessary, like typing in personal identification numbers to look at your bank statement. Other impediments, like indulgent Flash intros, are rather quite unnecessary.) You can see a clear kinship between usability and accessibility, given that we are trying to lessen the effects of the impediment of disability.

Usability is a good predictor of accessibility, since usable sites are put together by intelligent, thoughtful people (not necessarily paid experts), and that is exactly the group that pays heed to access without being pushed and prodded. But we should not expect a one-to-one relationship. Usable sites can be inaccessible (e.g., an E-commerce site where every navigation button is an image without a text equivalent). Conversely, accessible sites can be unusable – e.g., Jakob Nielsen’s Alertbox.com, which is so outlandishly undesigned as to make it hard to find anything, not to mention dozens or hundreds of pages at the World Wide Web Consortium itself, where we similarly drown in accessible data.

The scales of usability and accessibility, while kindred spirits, are not fully interdependent. There is no genuinely predictable cause and effect between them.

Further, we are forced to expand our conception of usability here. Is your site fully and conveniently usable by sighted people but an exercise in tedium for the blind?

If so, is it still “usable”?

There’s only one realm where usability noticeably suffers at the hand of accessibility (and vice-versa), and that is navigation. This is one of the rare instances where you may have to add a visible indicator to your pages to make them accessible.

Goals

In this chapter:

The basics

Note: If you’re already familiar with basic HTML, you can skip this section.

On the Web, you can zip from page to page (“external” navigation) or from point to point within a page (“internal” navigation).

You already know how to skip from one page to another: You use a hyperlink of the form <a href="http://www.example.com" title="Example.com homepage"></a>. (I’ve added the optional but helpful title metadata.) Your external address can be another file on the same site (as in <a href="/news2001.asp title="2001 News Roundup"></a>); it is “external” as viewed from the vantage point of the current page.

You can, of course, link to other URL types, including FTP sites (via ftp://ftp.example.com address encoding), E-mail links (via mailto:address@example.com encoding), and a few others that rarely come up. (Remember gopher://?)

Within-page or internal links, on the other hand, rely on named anchors. You must decide in advance the location where your visitors will end up and give it a name (or, in XHTML, an id, or sometimes both) that begins with a letter. The destination is otherwise known as the anchor. Whenever you think of anchors, think of destinations.

The name and id attributes are known as fragment identifiers and are unreasonably complicated for such a simple concept. We’ll learn the intricacies in two steps – by focusing first on destinations and then on the links used to send visitors to those destinations.

Coding the destination

The HTML syntax used to mark the destination looks confusingly similar to an actual hyperlink: Surround all or part of the destination with <a> and </a>. But you must use a different attribute on the element: Instead of href, use name and/or id to identify the anchor.

Why must you use “name and/or id”? Because name is oldschool HTML, tolerated in XHTML Transitional. id is used in XHTML 1.0 Strict and XHTML 1.1, where name is actually forbidden. It’s a tad complicated. The coding you choose depends on the DOCTYPE you have specified.

The examples in this book will generally assume XHTML Transitional coding and include both name and id. Sometimes I will use only id.

If you wish to use a heading as a destination (e.g., the section titles in a long document), you could name the destination breakdown and mark up the entire heading text:

<h3>
<a name="breakdown" id="breakdown">Cost breakdown, Europe/Mideast/Africa, Q2 2000</a>
</h3>

(The <a></a> element sits inside a block-level element like a heading.)

An image can be an anchor.

<a id="map7" name="map7">
<img src="/map/7.jpg" alt="Map 7: Europe/Mideast/Africa" title="Territory Map 7, covering Europe, the Middle East, and Africa" height="322" width="550" />
</a>

Even a fragment of text, or nothing at all, can be a destination. You can use an empty <a></a> element that is plunked down in the middle of a document somewhere.

In the latter case, you can deposit such an empty anchor after, say, a horizontal rule (either a graphic image or the HTML code, <hr />) or at the very top of a table cell.

But those were the easy examples. Theoretically, in XHTML it is possible to apply an id attribute to essentially any tag. It then becomes possible to treat such a tag as an anchor. The two previous examples could be rewritten thus:

The text-fragment approach can be modified: You may add an id to a paragraph tag, yielding, in this example, <p id="compound">With year-over-year revenues compounding by 2% in the E/M/A region (and continuing on with the rest of the paragraph, ending in </p>).

As the saying goes, browser support for the technique of using ids on generic markup varies, but I have managed to get it to work in reasonably standards-compliant browsers – even Lynx – on opening element tags as diverse and improbable as blockquote, cite, code, dd, dfn, dl, dt, h1, li, ul, and var. If I can make it work there, you can make it work anywhere.

Coding the hyperlink

To actually send your visitor to the anchor, use the trusted <a href=""></a> link, but use a number sign (for pedants, an octothorpe – either way, it’s #) followed by the exact, unaltered text of the id or name. You can add a title to <a></a>, if you wish; indeed, as per Chapter 7, “Text and links,” if any links on your page have titles, they all must do.

Some browsers – Netscape 4, where are you? – are case-sensitive in interpreting anchor names. (World Wide Web Consortium guidelines technically require case sensitivity.) For those browsers, #e3b and #e3B are different. We shouldn’t have to worry about such minutiæ. Nonetheless, it is easier for human beings to keep things straight in their minds if they stick to all-lowercase anchor designations when writing pages, particularly since nearly everything else in XHTML is lowercase already.

Evergreen issues in internal navigation

Since the overlap of usability and navigation has been broached, I would be remiss if I did not point out that the more dour and orthodox of usabilitistas have tended to frown on internal navigation, using noble but passé reasoning.

Early browsers badly bungled the interplay of anchors and the Back and Forward buttons. If you hit an anchor link and decided you wanted to retrace your steps, selecting the Back button brought you to the previous page, not the previous position on the current page. This misbehaviour, long since cleared up (even Netscape 4 does it right), remains a source of stigma for some netters with long memories.

Critics offer the æsthetic complaint that anchors are ugly. Admittedly, a URL like http://store.newriders.com/products/clark/#bio has a face only a mother could love, but URLs are typically hidden from real-world users. (Using a title on your <a></a> tags further distracts people from the status line where URLs are displayed in most graphical browsers, unless of course you use a JavaScript function like onload="window.defaultStatus='text'" to hide the URL completely.)

It has even been suggested that anchors are not “proper” or standards-compliant HTML, which is untrue.

None of those objections, then, holds water. Here are a couple that do:

It is unrealistic to expect Web authors to create separate files for each and every conceivable subdivision of a page merely to overcome the modest usability defects of anchors. Just think of a résumé: Do you really want the Education, Work Experience, and Career Goals sections to appear on different documents? Such an arrangement defies centuries of information design in the print medium, of which the Internet is merely an extension, not a refutation.

Besides, the problem of locating specific passages is in fact a holdover from print: Reference books (particularly in law, but think also of canonical works like religious texts) will list not only page number but also column and paragraph numbers to lead you to an exact target. HTML anchors are stepchildren of that practice.

And have you ever tried to locate a specific scene on a home videotape or find a few words on an audiocassette? How about locating a specific lyric in a song on a compact disc? The inconvenience of sequential access has antecedents in oldschool electronic media.

It remains unrealistic, moreover, to expect Web authors to cease using anchors because screen readers have a tough slog in grinding through unstructured text. There are some things we simply cannot do online, and providing random access to the contents of a Web page through speech or Braille is one of them.

Use anchors where necessary. It’s that simple.

External navigation

Now that we’ve gotten the rather special case of within-page navigation over with, let’s consider the kind of navigation that dominates the net: Between pages, wherever they may be hosted.

Terminology

There may be a few terminology issues here. Some phrases in current use:

We’re also dealing with the confusion caused by a single word with more than one meaning, and that word is tabs. I will often refer to the Tab key on a keyboard (note the capital letter). Tabbing refers to repeatedly pressing the Tab key. The term is used generically here, as “click” is used even if the visitor selects with a keyboard, not a mouse. Tabbing also encompasses the very inconvenient switch access, whereby a mobility-impaired person wades through sequences of possible actions and selects one at a time.

However, tabs as a navigational user-interface feature on a Website refer to Amazon-like graphical trapezoids, rectangles, or ovals that overlap or abut like shingles or simply sit there in a row and, when selected, take you to the section specified by their legends. Where necessary, I’ll refer to these as “navigation tabs.”

Another relevant concept is focus. An element on a Web page is said to have focus if it is selected or active or if the next action taken will apply to it. When you click a link, it has focus. When you tab onto a link but do nothing to it, the link has focus. If you select text in the browser window, that text has focus. If you merely click inside the browser window, it gains focus.

If you then move up to the address bar and type in a new URL, the address bar has focus. All very clear-cut examples. But sometimes it isn’t so obvious. For example, if you select a Website from your graphical browser’s bookmarks, its address will appear in the URL field and the page contents will display in the browser window as selected text. OK. So what happens if you press the spacebar? Will you replace the selected URL with a space character or will you scroll the contents by one screenful? Where is the focus?

Some browsers, like iCab on Macintosh, assume you want to scroll and force you to re-select the URL field if you really want to manipulate it. Others, like Explorer, retain the “selected” state of the URL text but explicitly alter the focus to the content area; click in the URL field again and you’ll see that the full text is still pre-selected.

The issue of focus, then, is actually quite familiar. It just doesn’t come up too much in everyday Web-surfing. In accessible navigation, you can’t get away from it.

By the way, software tends to keep track of focus by tracing the location of an internal cursor or caret, a word you may recall as the name of the circumflex character in ASCII, ^. There may be more than one caret at any given time: The browser may place its focus in one spot, a plug-in (like Acrobat Reader) in another, and a screen reader in a third. Or there may be multiple possible carets, only one of which is in effect at any given moment.

Inconvenience and usability

It is somewhat inconvenient for a screen-reader or Braille-display user to contend with extensive navigation, like top or left-hand navbars with dozens or hundreds of links. The inconvenience stems from having to listen to the links in sequence; they cannot be skipped over or scanned visually.

The same scenario is massively inconvenient for a mobility-impaired person, particularly one using switch access. It takes a great deal of physical effort (exactly what is at a premium for someone with such a disability) to skip unneeded links.

It is bad accessibility practice to assume that your site is perfectly accessible merely because all images are accessible (always the biggest issue) and your site seems to meet every requirement. If there are a great many links or other intervening items to skip over between the top of the page and where the visitor actually wants to go, accessibility here overlaps significantly with usability. A hard-to-use site becomes an inaccessible site even if every other issue has been taken care of.

Years from now (see Chapter 15, “Future dreams”), Websites may be automatically self-reconfigurable to do things like shunting all the navigation to the end of a page. (All you the visitor would need to do is set a preference, which could be saved in a cookie.) The Composite Capabilities/Preferences Profiles Working Group at the World Wide Web Consortium (CCPP.org) is trying to make all this happen.

But we do not live in that idealized future. At present, we are forced to retrofit existing Website concepts like top and left-hand navigation.

How and why to skip navigation

It is time, then, to bring up one of the rare cases in which you may be forced to add a visible element to your page to make it accessible. It isn’t all that onerous, and you may be able to use an HTML accessibility code in addition to this mechanism or instead of it, though there are many provisos.

Let’s start out by discussing the worst-case scenario – using plain-Jane HTML and visible added elements for accessibility. Later, I’ll show you how to do the same thing with access-specific HTML, and finish with advice on which of those approaches to select.

Note that if your graphical browser lets you tab from item to item on a page (Netscape and Explorer on Windows let you do so, as do Explorer on Macintosh and Opera on all platforms, though Opera uses different keystrokes), then you can test the plain-Jane-HTML techniques yourself without any adaptive technology whatsoever.

Left-hand navigation: Too many links

Left-hand navigation has become the norm among commercial sites online. While some designers use frames, piling dozens or a hundred links in a <td></td> appearing early in a table row is an accepted practice. There’s nothing wrong with it, no matter what some design purists would have you believe.

Here is the problem, though. With certain browsers and with certain older screen readers, you are stuck reading table cells in a linear order, rather like tiling a floor: Odds are you’ll start at the upper-left cell, move across the first row a cell at a time, and then restart at the extreme left of the next row down. That’s how tables are linearized.

For an all-stylesheet layout, dumber devices will read out page contents in the exact top-to-bottom order in which divs appear in the source HTML.

If you’re using left-hand navigation, someone reading tables in a linear fashion will be presented with the entire contents of the cell, which in this case means dozens of links. And I really mean dozens of links: The homepage at ChicagoTribune.com presents me with 99 navigation links on what would be the left side of the screen in a graphical browser.

Visitors who cannot readily skip all those links must either page through them (as with Lynx, a text-only browser), or move the cursor to select each link in turn (as with some mobility-impaired people using any kind of browser), or attempt to skip the links using software commands, if that is even possible. But in doing so, visitors may skip links they actually want along with those they do not.

As a veteran Lynx user, let me tell you how it works. When presented with dozens of navigation links, I press the spacebar over and over again to bypass them a screenful at a time. If the first link of any resulting screenful happens to be a text field (e.g., a search box), I have to move the cursor off the field with the Downarrow or Tab keys, then keep on paging through the links. Or I can guess how many screenfuls of links are present and skip beyond that screenful: Typing 5p (p for page) brings me to the fifth screenful.

But I have it easy. While some mobility-impaired people do in fact repeatedly press the Tab key to move around a page, some people with more severe disabilities use adaptive technology that runs through a sequence of possible actions (“switch access”). You have to wait until the keyboard action comes up, then home in on the Tab key (which itself could take many steps), then actuate it. How would you like to go through that 99 times just to skip navigation?

Then what if the link you really want is actually near the bottom of the page?

How long would you put up with that, if you don’t already?

The table hack

If you use tables to lay out your page – and there will be no reason to stop doing so outright until most people online use browsers that can reliably render all-stylesheet layouts – you can take advantage of absolutely the cleverest trick in the brief history of Web design, the table hack. I credit Mark Pilgrim (a technical editor of this book; DiveIntoMark.org) for the idea, but he traces it back to Lauri Harpf of the Website APromotionGuide.com.

Our problem, you will recall, is that the top left cell in a layout table contains dozens of navigation links. Actual “content” appears in the cell immediately to the right (in a typical layout). Schematically, it looks like:

<tr>
<td rowspan="height-of-full-table">Navigation links</td>
<td>Content</td>
</tr>

In the table hack, the top-left cell is replaced by a spacer GIF. But the next cell in the same row is unchanged: It’s the “content” cell. The following row’s first cell contains the navigation. You make it all work visually with colspan and valign attributes.

When read serially, it goes like this:

And the HTML looks like:

<tr>
<td valign="top"><img src="spacer.GIF" alt="" width="1" height="1" title="" /></td>
<td rowspan="2" valign="top">Content</td>
</tr>
<tr> <td valign="top">Navigation</td> </tr>

The rowspan="2" attribute merely makes the content cell twice as wide as the other cells under discussion, one of which already measures a mere one pixel in height and width – unnoticeable in typical layouts. (You can futz with cell backgrounds if necessary to make it unobtrusive.) The navigation cell seems to sit at the far upper left to a sighted visitor; nothing looks different because the one-pixel spacer GIF is unnoticeable. But when experienced serially, you get the content first, navigation second (with, in some cases, a small screen-reader indication of the existence of a graphic, as through a beep or notification sound; it’s up to the screen-reader user to deal with those details, not you).

Astonishingly, even shockingly simple, isn’t it? It’s a “Why didn’t I think of that?” idea. Devilishly clever. And something I hadn’t though of myself or had ever heard about until very late in the day.

Now, in subsequent sections here, I’ll teach you the labyrinthine and painful procedures for skipping not merely left-hand navigation but anything else “extraneous” on the page, but nothing is going to approach the simplicity of the table hack. If you are forced to present enormous numbers of navigation links and if the only page element you wish to make easy to skip is that collection of links, then stick with tables and hack away!

Bypassing navigation

Now that we’ve learned the easy method, the fun is over. How do you code a Website to skip navigation if you’re not using the table hack?

The gratuitous use of Flash on Websites – “Flashturbation” – has single-handedly spawned a new Internet buzzword: skip intro. Now I’m teaching you something else we sometimes need to skip – extensive navigation links. In certain cases, you will need to add an entirely visible hyperlink, a navigation-skipper, to your pages.

Link format

We’ll consider the link first and the anchor locations later. The link should look like this:

<a href="#body" title="Skip navigation">Skip navigation</a>

You can use whatever terminology you like for the title and link text. Feel free to add a little zing.

Keep them visible!

Well-intentioned developers who already use page anchors to skip navigation will go to the trouble to set the anchor text in the tiniest possible font in the same colour as the background, rendering it invisible to graphical browsers (unless you happen to pass the mouse over it and notice the cursor shape change).

Or they’ll use an invisible graphic (like a single-pixel GIF) with an alt text reading “Skip navigation” or equivalent. Here’s an edited, but genuine, example from CNN.com:

<a name="top_of_page">
</a>
<a href="#ContentArea">
<img src="1.gif" width="10" height="1" alt="Skip to main content" align="right" /></a>

An image ten pixels wide by one pixel high is essentially invisible. It’s entirely invisible if its colour matches the background and it lacks a border, or, of course, if it’s a transparent GIF.

This example, from the Sydney Morning Herald newspaper site at SMH.com.au, is super-minimalist:

<a href="#skip"><img src="/media/core/1x1clear.gif" alt="[skip navigation links]" width="1" height="1" /></a>

Individual pixels (in this case, a 1-by-1-pixel GIF) can be distinguished: Liquid-crystal displays often saddle you with a noticeable dead pixel or two. But in that case you’re staring at the screen all day, and the dead pixel doesn’t move. On a Website, a single pixel is fleeting. And besides, GIFs can be transparent. Even if the page background were black and the 1-by-1 GIF were white, nearly everyone would miss it nearly all the time. Nobody would think to click it. And only seasoned neurosurgeons would have enough hand–eye coordination to actually hit a single pixel with a mouse. This entire chapter is designed to accommodate people who lack neurosurgeon-calibre hand–eye coordination.

Moreover, in late 2000 a nefarious use of 1-by-1 GIFs was discovered: Web bugs. Advertisers embed them in HTML-formatted E-mails and in Websites; once loaded, they register that your net connection is active, and permit the advertiser to place a cookie on your machine, read your E-mail address, or do something else without your knowledge. Reliance on single-pixel GIFs for navigation-skipping may be benign, but this subsequent use has cast suspicion on the entire practice.

Trading off disabled groups

In any event, the theory here is that, since Lynx users require a navigation-skipper, and since there is no such thing as small or invisible text with Lynx, and since alt texts are always displayed in Lynx, a hidden link serves Lynx adherents without inconveniencing anyone else. Similar reasoning applies to screen-reader users: The screen reader will enunciate the link, which the visitor can then select, skipping over the audible reading of up to 83 link titles.

Like a lot of kludges, this actually works quite well. But blind visitors are not the only ones inconvenienced by too many links in a navigation area. Recall that a mobility-impaired person with poor adaptive technology might be stuck tabbing through that morass. But, unless that person is also using Lynx or a screen reader (not impossible, but exceedingly rare), the skip-navigation link will remain invisible.

Why? A graphical browser with image-loading turned on (as is the norm) will load the essentially-invisible image, and the visitor won’t notice it. With image-loading deactivated, the image is too small to display the alt text in its bounding box. Although some browsers expand the image space to display the alt, there are limits to the size of such expansion. You can’t rely on it. Sometimes the visitor has to run the mouse over the image to see the expanded alternative text. But you won’t run your cursor over something you don’t know is there, and this mobility-impaired group isn’t using a mouse in the first place.

Even if you place the navigation-skipper high up on the page and assume the visitor will tab onto it quickly, there is no reason to think the visitor will notice the link (it’s too small), let alone understand its function. (Try it yourself. Even if your browser highlights successive links with a coloured border, can you spot a coloured border slightly bigger than ten pixels wide and a single pixel high? How about a coloured border surrounding a single dot? The purpose of the link is unclear, isn’t it?)

We’re not done yet: If you helpfully add a title to the link so that a tooltip will pop up in a graphical browser explaining the link’s purpose, keep in mind that tooltips are tied to mouse movement. Navigating links by keyboard does not trigger a tooltip in any browser currently available. (Arguably, that needs to be fixed. Keyboard and mouse operation should be equivalent.)

You’re not going to like this, but to make a lengthy list of links accessible, your “Skip navigation” link must be visible. It doesn’t have to be intrusive, but it has to be apparent and self-explanatory in all browsers.

Most of the time, it’s enough to build the word “skip” or equivalent into the header of your navigation. Yes, I know, I promised I would make accessibility less of a pain in the arse. I’ll have to make it up to you somewhere else.

Anyway, I would suggest a few model approaches:

Cries of woe at polluting your magnificent Web design with the single visible word “skip” ring somewhat hollow here. We’re talking about a huge column of links, something that isn’t exactly as beautiful as Liz Taylor in Cleopatra. Even if you use a beautiful imagemap, it can’t be that beautiful and will not be rendered that ugly by shoehorning in four wee characters.

Text, not icons

More philosophy:

Visualists embrace the utopian ideal that concepts can be boiled down to pictographs, transcending specific languages, which, the theory holds, inevitably someone will come along and fail to understand. The impression is that pictographs, through their “universality,” are pure and noble, while specific languages, with their intimations of the Biblical tale of Babel, are sullied and improper.

Well, here’s a newsflash for all the philosopher-kings and -queens out there: The range of concepts that can be reliably evoked in little pictures is about as wide as a fly’s wingspan. Words come first, then pictures, not the other way around.

It is unwise to attempt to shoehorn complex ideas into stick-figure pictographs. There aren’t a lot of pictographs that actually are universally understood on the Web. You might think that a little graphic of a house deployed to mean “homepage” might be one of them. To my chagrin, sites written in languages other than English have adopted it, which staggers the imagination given the gulf in meaning between “house” and “home” in the original English. It shouldn’t even work there, let alone in other languages, where the English concept of “home” is often untranslatable and where the word “homepage” has a specific translation already in that language. Does your Website actually have a “housepage” if you use that navigation icon?

It will come as no shock to you that I strongly urge you not to attempt to dream up some kind of half-arsed pictograph for the concept “skip navigation.” What are you going to use – a (leap)frog? a kid on a pogo stick? an arrow encircling a blob?

The solution is to use a word like “skip.” Don’t try to draw us a picture. But nothing says you cannot render the word in legible but discreet graphic form (a picture of text), with appropriate alt and title.

A final no-no: Don’t try to double this function up with unrelated graphics. Do not, for example, turn the company logo into a navigation-skipper – unless you’re also willing to add the words “Skip navigation” to the logo.

Where should the link end up?

Now that we have scrutinized the entrails of coding a navigation skipper, just where should you end up when you select it?

The easy answer is: At the first point on the page that follows whatever you’re skipping and represents actual content.

That point could be anything: A headline; a block of text; an image; a “slug” (listing of the current date and time, or an article byline); or – get this! – even more navigation.

In evaluating your sites for accessible navigation, you will need to make intelligent decisions about landmarks on your pages. Like a frog leaping across a pond from lily pad to lily pad, you are obliged to imagine which parts of your page can be skipped and which can be destinations.

Basic coding

Let’s consider the simple case in which there is a clear distinction between navigation and “content” on a page. Here you’d need a simple anchor at the top of the content section.

<td><!-- Start of real content (DO NOT DELETE) -->
<a name="body" id="body"></a>

If you’re using Web-design software or, worse, a content-management system, vigilance may be required. You don’t want your software doing your thinking for you and nuking your anchor tag. That may be especially true if you take the modern approach and simply add an id attribute to any arbitrary tag; your authoring program may nuke it behind your back.

That may be the simplest case, but the technique is transferable. You can set up as many anchors for navigation landmarks as you need. As you know already, your “skip” link would point to this anchor. In fact, the examples listed in the “Link format” section would immediately work here.

More than one navbar

What if you’ve got more than one navigation area on your page? It’s a pretty typical design, thanks to E-commerce sites like Amazon: A graphical navbar up top (maybe with tabs you can click) bolstered by left-hand navigation, quite likely in the form of simple text links.

Top and left navigation represent separate modules in appearance and function. It would be presumptuous to assume that a disabled visitor would want to skip both in their entirety. If you want to provide access through navigation-skipper links, don’t force people to overshoot the mark by zipping from top navbar directly to page content, bypassing left-hand navigation.

There is no single solution to the problem, and you are hereby empowered to make intelligent judgement calls on which approach to take.

If your top navbar has only a few links (fewer than ten Tab keystrokes’ worth, say – put yourself in the position of someone using only the keyboard) but your left-hand navigation has many more, you could probably get away without a “Skip navigation” link up top. Yes, you’re expecting your visitors to page through those fewer-than-ten links, but that’s tolerable if and only if you let people skip the mass of left-hand links. In this case, your table structure might look like this:

<table>
<tr><td>Company logo, or blank</td>
<td>Top navbar</td></tr>
<tr><td><a href="#top" title="Skip to content">(Skip)</a><br />Left-hand navigation</td>
<td><a name="top">Regular page content</a></td></tr> </table>

For a top navbar with a plethora of links (like a set of navigation tabs), provide a navigation-skipper link on that top navbar. The destination of that link should be the top of the next navigation group (e.g., left-hand navigation). Don’t use the first content cell as target.

Why?

A visitor can use any of the top navbar’s links. Or the visitor can skip that navigation and end up at the beginning of the left-hand navigation region, making use of any of those links – or none of them, by skipping that group entirely. Remember, the whole purpose of this exercise is to spare people the necessity of tabbing through dozens of links they do not want without isolating them from links they do want.

Your HTML might look like this:

<table>
<tr><td>Company logo, or blank</td>
<td>
<a href="#left" title="Skip to next navigation block">(Skip)</a> Top navbar
</td>
</tr>
<tr>
<td><a name="left"></a><a href="#top" title="Skip to content">(Skip)</a>Left hand navigation
</td>
<td>
<a name="top">Regular page content</a>
</td>
</tr>
</table>

It is legal to place empty <a></a> tags alongside one another. Targets must precede links. (You don’t want an overlap.) You may, if you wish, use a non-breaking space character, &nbsp;, as a kind of placeholder within <a></a>, but my testing shows it to be unnecessary. Empty <a></a> tags work fine. So does adding id to any arbitrary tag.

If your top navbar doesn’t sit in a table (if it’s one big image, or two side-by-side), the approach is unchanged. If you’re using stylesheets for positioning rather than tables, the approach is also unchanged, keeping in mind that dumb devices will interpret and present to the visitor the contents of divs in the strict top-to-bottom order in which they are found in your source code. While that seems to solve the problem, here in the real world about the only device that does not understand stylesheets is Lynx; remember that screen readers sit on top of browsers, and nearly all those browsers interpret stylesheets.

Targeting search

Search functions merit a certain wary or begrudging respect and are important enough to demand special treatment.

Amazon’s search-box placement, at top left, has become a standard – a standard, but not the only one. I’ve seen search boxes at screen top, screen bottom, both (which I often use), and on the right. Since there are only four sides to a computer monitor, that pretty much covers the options. (How often do you find a search field smack dab in the middle of a page? Occasionally, I suppose – on pages that do nothing but provide a search facility.)

If your search box is located at left or up top in a table-based layout, it will appear high up in a linearization of that table. While this is desirable, we mustn’t forget all the other links that stand between the very top of the page and the search box. Will you need to provide a navigation-skipper?

Possibly. You can figure that out yourself at this point. But what you must not do is skip the search. If you’re stuck tabbing through links on a page, search is a target of interest, not filler or an impediment. Make sure any search function that might otherwise be skipped is actually the target of the immediately-preceding navigation-skipper. If your left-hand navigation sits on top of your search box, your code could look like this:

<table>
<tr><td colspan="2"><a href="#left" title="Skip to next navigation block">(Skip)</a>Top navbar</td></tr>
<tr><td><a name="left"></a><a href="#searcher" title="Skip to search">(Skip)</a>Left-hand navigation
<a name="searcher">Search fields</a>
<a href="#top" title="Skip to page contents">(Skip)</a></td>
<td><a name="top">Regular page content</a></td></tr>
</table>

In this example, navigation-skippers move the cursor from top navbar to left-hand navigation to the search mechanism to the page content, by selecting your nav-skipper links in that order.

If your search box sits on top of your left-hand navigation (the converse of the previous example), you could write HTML like so:

<table>
<tr><td colspan="2"></td><td>Top navbar<a href="#searcher" title="Skip to next navigation block">(Skip)</a></td></tr>
<tr><td><a name="searcher"></a>Search facility
<a href="#top" title="Skip to content">(Skip)</a>Left-hand navigation</td>
<td><a name="top">Regular page content</a></td></tr> </table>

What if your search facility lives on its own separate page? In other words, what if a visitor has to select a link to call up a separate page where he or she can run a search? This is unusual and certainly unwise (don’t make people search for search!), but if you insist on this practice, make the link to the search page a destination in the skip order.

(This approach is unrelated to a search box that provides a basic text field right then and there and a link to a separate page for advanced searching. There are no specific access issues in that case. Normal cautions about adding text equivalents for graphics apply.)

Other landmarks

What other navigation landmarks are so important that you shouldn’t skip them? What objects should become landmarks?

Page extremities

At the very end of your page content, you may use a “Back to top of page” link. For mobility-impaired people with no mouse access, there may be no immediately-evident reason to make that link a destination for navigation-skipping. Why? Some people with a mobility impairment relevant to Web accessibility are already using the keyboard. How many keyboards don’t have a Home key, or at least PgUp? It would not be flagrantly presumptuous to code your page for the majority with standard keyboards.

(To be fair, a few keyboards lack those keys, particularly on Macs, given Steve Jobs’ twenty-year hatred of typing and his unending stream of keyboard designs intended to impair expert touch-typists – like me, I must add. Or hardcore Unix sysadmin types may use the Happy Hacker Keyboard, with roughly the surface area of a FedEx waybill and severely limited function keys. Or, as on a laptop keyboard, you may have to hold down a so-called Fn key to produce those keystrokes, which isn’t the sort of thing you want to have to hassle with if you can barely move your hands in the first place.)

Moreover, scrolling to the top of a document does not deposit the cursor there, requiring another keystroke or action. And remember users of the laborious adaptive technology known as switch access: Moving through a Website is an exercise in frustration for them. It is incumbent on you to alleviate that frustration.

Accordingly, then, not only is it always wise to make a Back to Top link a landmark on your page, perhaps all your pages ought to carry them, though the latter is just a suggestion.

Now let’s consider the other extremity. At the very top of a page, the first item that actually does anything – like a link or a search field or a button as opposed to text or an image – should not be a search box (a text-input or textarea field). Why? Lynx users will find their cursors stuck in that search box because Lynx always selects the very first link or actionable region on a page.

The Lynx cursor is never invisible unless the page has no actionable items whatsoever; the cursor always sits on something. By contrast, graphical browsers hide the fact that they have a cursor at all, unless your browser responds to pressing the Tab key to move from item to item, at which point this cursor (or caret, or focus) pops out from behind the curtain and becomes apparent after all.

One way to fix the problem, if you happen to use a graphic image at the very top of a page, is to make that image a link back to the homepage of the site, a technique that I suppose will not work for the actual homepage. It is an imperfect solution for what is admittedly a minority concern.

Right-hand navigation

What if you’re a free-thinker who locates side navigation on the right rather than the left? (Or just a part of the navigation, like a search box?)

This is where the training wheels come off. You will need to consider the layout of your page and come up with a logical tabbing order that includes navigation-skippers where necessary. But remember how such layouts would be linearized: Page content would likely appear before your right-hand navigation. Is that really the order in which people should interact with your site? Remember, nondisabled people can ignore the left-side content and skip immediately to the right-hand navigation links, but at this juncture we are not designing for nondisabled people.

It may make sense, then, to devise a skip sequence that puts the right-hand navigation segments before any page content even if that is not how they are coded in the base HTML.

I can envision a few scenarios:

If you have a top navbar and right-side navigation, let people skip from the top navbar to the right-hand navigation to the content. Make a pit stop along the way for search if necessary.

If you have a top navbar, left-hand navigation, and right-hand search, you may wish to skip from the top navbar to the search function, then to the left-hand navigation and finally to the content.

With no top or left navigation and nothing but a header, content, and right-hand navigation, things become conceptually complicated, because tabbing to the next element on the page may take you to a heading or a link within the actual content. But a mobility-impaired visitor may wish to skip the screenfuls of content and use the right-hand navigation. Ordinarily, you would embed a skip link in one block of navigation which, when selected, will send you to the next block. But here the first navigation block in the right-hand navbar is actually your destination, isn’t it?

The solution may be to place a skip-navigation link before or after your header, making it the first link on the page. With any luck, that will be the first item selected when tabbing. It will surely be the case if you’re using an ordinary browser that moves from link to link to link, bypassing everything else, but a visitor’s adaptive technology may select the header (if it’s in an img element). Still, it only takes one command to move off that header, which is not an unreasonable additional step by any stretch of the imagination.

Your job worsens if you are working in a language written right-to-left, at which point what we are calling right-hand navigation here has the same role as left-hand navigation save for the fact that HTML is written in left-to-right English. You the visitor may read a Hebrew Website from right to left, but its underlying code has a left-to-right order, particularly where table cells are concerned. Such a dilemma, however, is a tad recherché; I would surmise that designers working in right-to-left languages, now armed with the concepts explained in this chapter, can make intelligent choices.

Do I have to do all this?

Do you actually have to go to all this trouble? Just to recap, the answer is “Only if your navigation includes so many links they would be tedious to tab through.” If not, the use of navigation-skippers is quite optional.

Alternatives with accessible HTML

Having endured the hazing ritual of HTML gymnastics to skip over extensive navigation, you may now matriculate to the full-fledged use of two HTML accessibility tags, accesskey and tabindex. They are widely applicable to online navigation, but are somewhat poorly supported and bring along their own problems. On the other hand, they’re simpler.

Taking over your keyboard

What if you could set up a Website so that whenever we hit a key something happened? It can now be done – at the level of HTML rather than the browser, which already gives you certain keyboard control over Website content, as when you press Control- or Command-leftarrow to go Back one level.

Two tags let you take such control:

At this point, you’re muttering “Why didn’t you say so in the first place?” The answer: Because the tedious and overt navigation-skipper approach works in any browser, while support for accesskey and tabindex is variable.

Keyboard navigation

You might consider accesskey and tabindex as akin to the ball and peen on the end of a handle. Together they make up the tool we know generically as a hammer, but you wouldn’t want to mix up the two functions.

accesskey moves you directly to somewhere and does something right then and there. tabindex moves you past something and requires another step before doing anything.

In a moment of unexpected clarity, the World Wide Web Consortium documentation of the accesskey attribute is understandable and self-explanatory:

This attribute assigns an access key to an element. An access key is a single character from the document character set.... Pressing an accesskey assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the <a></a> element, the [browser or device] generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.

The following elements support the accesskey attribute: <a></a>, area, <button></button>, input, <label></label>, <legend></legend>, and <textarea></textarea>.

(Well, there is a wee ambiguity in the definition, but I’ll cover that in due course.)

You simply add accesskey="" as an attribute on your element, inserting the character of your choice between the quotation marks. In page navigation, some examples might be:

Or your left-hand navigation, if it is not too extensive, might use a letter or number on every link:

<a href="/home.jsp" title="Company homepage" accesskey="1">Home</a><br />
<a href="/about.jsp" title="Company background/Job opportunities" accesskey="2">About</a><br />
<a href="/prod.jsp" title="Products" accesskey="3">Products</a><br />
<a href="/ret.jsp" title="Where to buy" accesskey="4">Retailers</a><br />
<a href="/phone.jsp" title="Buy by phone" accesskey="5">Shop by Phone</a><br />
<a href="/shop.jsp" title="Buy online" accesskey="6">Shop Online</a><br />
<a href="/contact.jsp" title="Phone numbers and email and postal addresses" accesskey="7">Contact Us</a><br />
<a href="/priv.jsp" title="What we do with your personal information" accesskey="8">Privacy Policy</a>

In this case, all a hypothetical visitor need do is press a number on the keyboard to actuate the link. The effect is exactly the same as clicking the link with a mouse or tabbing onto it and pressing Return: The link is activated and you immediately go to the destination page.

When to use it

accesskey is the delinquent teenager of accessible HTML. It is difficult to make accesskey work.

The delinquency is mitigated somewhat if you limit your use of accesskey in the first place. Your mental model should be keyboard shortcuts in software. Typically, it is frequently-used functions to which we assign keyboard shortcuts in software – save, print, quit, cut, copy, paste. For rarely-used functions, menus and dialogue boxes are satisfactory.

accesskey is for all practical purposes a keyboard equivalent, though with all too many provisos. Apply accesskey only to very important areas of your page navigation – links that seldom change, if ever. Hit the high points only: It is rarely necessary even to attempt to assign an accesskey to every single link. (If you have very simple navigation, you certainly may do so. But adding accesskeys to links inside the “content” of your pages yields rather limited real-world results.)

What’s wrong with this picture?

accesskey is something of a secret for nearly every Web-surfer.

True, Internet Explorer on Windows supported accesskey in version 4.0. You can hold down Alt and press the accesskey and it will work. Support was downgraded in IE 5 and later. According to a Microsoft source, “IE will support the accesskey attribute only on elements that you can get to via normal keyboard navigation (by tabbing). To do otherwise would be inconsistent.” It’s another case of Microsoft’s reinterpreting World Wide Web Consortium standards, which specify exactly which elements can take accesskey with no “inconsistency” whatsoever.

What’s the catch? (You’ve learned to expect a catch, haven’t you?) The visitor does not know what the specific accesskey is. Explorer provides no visible indication that an accesskey even exists. In effect, Explorer plays Rumpelstiltskin, demanding that you say the magic word without knowing what it is.

Oh, but we’re not done yet. We’ve hardly begun to list the incompatibilities. To continue with this example, some accesskeys may conflict with existing Explorer or Windows key commands, like Alt plus the first letter of a menu name, very much including F for File, E for Edit, and H for Help. In that case, by convention but not by any requirement, the accesskey wins out. (The same conflicts come up with Mac OS X 10.1 if you turn keyboard navigation on.)

This is a wee problem. Lots of people use keyboard commands to actuate menus. Keyboard fetishists like me do it all the time, and we’re not disabled. And so do a lot of blind people, who are keyboard fetishists by necessity. Use accesskey to help out mobility-impaired people and you get in the way of blind people.

Such a conundrum could have been avoided if browser makers had ever interpreted the accesskey spec correctly. (I don’t know of any who do it right.) The problem with accesskey is its name: It’s really an accesscharacter, and you may use absolutely any Unicode character for that function. It all sounds very grand and internationalist.

Yet you still have to type the character. And the only time typing a character is an easy process is when you have to press only one key to do it. While it is obvious to everyone that 7 and e and # are all distinct characters, keep in mind that a and A and å and à are all different, too. In other words, case and accents make letters different. Accordingly, all of the following should be distinct and none of them interchangeable:

In my testing, English-language browsers interpret upper- and lower-case accesskey letters as exactly the same and ignore most accented characters, even if the operating system makes them easy to type. Of the last four items in the list above, the first pair are treated identically (a and A) and the last pair are widely ignored (å and à). Of the seven items above, only three work properly.

accesskey="e" and accesskey="E" are in fact separate but are treated as interchangeable. Yes, on a Latin-alphabet keyboard you must actually press Shift to produce a capital letter, meaning that real-world accesskeys might end up being three-key combinations in Windows Explorer (Shift-Alt- letter ). But if case were distinguished in interpreting accesskey, then at least accesskeys could be distinguishable from system-level commands (in this case, Shift-Alt- letter vs. Alt- letter ).

This means, of course, that you can introduce your own conflict on a page by using two accesskeys differing only by case.

Nice.

So when do things get better?

You can use numbers – plus, I suppose, punctuation. If you’re writing a foreign-language site and expect everyone to have a foreign-language keyboard, you can use an accented character, if it has a dedicated key and if the localized browser doesn’t simply replicate English-language behaviour.

However, even keyboards specifically designed to type languages that use accented characters do not always give an accented character a key of its own. French keyboards, for example, may give é its own key, because that is the only letter that takes an acute accent in French. You might also find a dedicated ç key; no other characters take cedillas in French. But even in French, grave accents, circumflex accents, and diereses (umlauts or trémas) require you to press two keys – an accent key (called a “dead key” in oldschool typesetting) and then the character you want it to appear on.

On such a keyboard, you could make accesskey work with é or ç, maybe, but how do you make it work with Ï or ù?

If you wanted to enter such characters on an English-language keyboard, how would you do it? Among the litany of user-hostile features of Microsoft Windows is the punishing difficulty it poses in typing accented characters. How do you hold down Alt and also produce an é to trigger the accesskey when typing the accented letter itself requires you to hold down Alt and type 0233 on the numeric keypad?

Let us consider the Macintosh case, because typing non-English characters on Macs is quite simple. Here, you can just type Option-e e to produce an é. Nice and tidy. But will it work? Currently the answer is “probably not.” A browser that understands accesskey, iCab on Macintosh, really understands only US-ASCII accesskeys. (You don’t need to hold down a modifier key. As long as focus is placed in the browser window by clicking in it or tabbing to it, all you need to do is type the accesskey by itself.) iCab is also the only browser that actually displays the accesskey for you (in a superscribed sequence of <accesskey>; more details on display issues are coming up shortly).

If you use an extended character of any kind (non-ASCII punctuation or accented letter), iCab may or may not react properly when you type it and almost certainly will not display it properly. (The superscribed sequence is misdisplayed.) In iCab, some accented characters work as accesskey and some do not. Internet Explorer and Mozilla (hence also Netscape 6) on Macintosh ignore accented accesskeys (impossible to type anyway due to the requirement to hold down Control to trigger the accesskey).

On all platforms, browsers are not entirely to blame. Various Web Accessibility Initiative documents warn us to take care to provide input methods relevant to various modalities (keyboard, mouse, voice, whatever), but accesskey is nothing more than keyboard control of Websites in drag. You could imagine entering an accesskey by voice. But how, exactly?

The entire accesskey system is set up as a keyboard substitute. It only works in some browsers, and is limited to 26 unaccented all-American letters, ten digits, and a few noncontroversial punctuation marks.

If accesskey were really a character you could “enter,” then browsers would have to pop up a little windowette in which you could enter the character (using any input method you like, correcting any errors you make), and then press Return or click an OK button to actuate the accesskey. In other words, it would act something like the way Lynx handles numbered hyperlinks and form fields: Just type the number and hit Return and it happens. This, however, remains hypothetical, and massively inconvenient. Why bother? Shortcuts should not be more involved than the action they replace.

The show must go on

The poorly-thought-out accesskey attribute is severely compromised in practical application. I want you to use it anyway. You’ve got at least 36 characters you can stuff into the accesskey attribute, and that will surely be enough for you.

You need to consider accesskey an adjunct to your existing navigation system. Adding an accesskey to a link takes nothing away from that link. It will still work the way links have always worked.

Also, to reiterate, while accesskey can theoretically be added to every link on a page (or about three dozen of them, at least), that could be a case of too much of a good thing. Use accesskey for major page navigation landmarks – for only the highest-level or most important navigation links.

For instance, if your left-hand navigation included a list like the following –

– it would be apparent that the major categories are “Products,” “Dealer locator,” and “Contact us.” If any links were crying out for accesskey, those are the ones doing it.

In this limited example, with only four entries in the Products subcategory, you certainly could use accesskey. It wouldn’t hurt. But limiting the addition of accesskey to major landmarks only is easier and provides good added accessibility, all the many incompatibilities notwithstanding.

Overt listing of accesskey values

There’s another option, and I’ve seen it a few times. Either the page that uses accesskey, or a site help or FAQ page, or an accessibility statement, if there is such a thing (see Chapter 24, “Certification and testing”), can simply list all the accesskey assignments in plain readable text. It’s a rather brute-force method that would not be necessary were accesskey better-thought-out in the first place and better-supported by browsers and devices.

Skipping navigation

Let us cast our gaze back to the entire tortuous concept of letting mobility-impaired visitors skip huge masses of navigation links. While you can and should use the oldschool-HTML method, you can add accesskey to your bag of tricks.

Recall that accesskey can be added to the <a></a> element, which we usually use for hyperlinks in the form of <a href=""></a>. That is, as the source or trigger of a hyperlink. But remember <a id="" name="">, the named anchor or destination of a hyperlink? It’s still an <a></a> element, right?

Shouldn’t it be possible to give a name and/or id to navigation blocks and assign them accesskeys? Visitors could then select those regions via the keyboard, subject to all the usual accesskey constraints. Couldn’t they?

No, as it turns out, they could not. An accesskey merely actuates the element in which it is included. <a href=""> actually brings you somewhere upon actuation. But there is no particular meaning to the concept of actuation as applied to <a name="">. How do you actuate an anchor? (Testing shows it does not work.)

However, you can cheat a little bit in HTML. A link to an anchor can be placed anywhere in relation to that anchor. That includes the position of immediately preceding the anchor. This construct is legal HTML:

<a href="#zip_to_search" title="Zip to search"></a><a name="zip_to_search"></a>

The first <a></a> links to the second. They just happen to be butting up alongside one another. Since there is no link text, the first <a></a> is invisible; the second <a></a> would be invisible anyway. Selecting this link via keyboard or mouse would have no particular effect – indeed, it might be impossible. But what happens if we add an accesskey?

<a href="#zip_to_search" title="Zip to search" accesskey="S"></a><a name="zip_to_search"></a>

We have thus created a combo of link and anchor that will give itself focus when you press the S key, skipping absolutely everything else on the page.

Miraculous, isn’t it? We’ll come back to this technique later.

Another technique

If the objective here is to let people skip over extensive navigation by moving from module to module without tabbing through the intervening steps, we can combine accesskey with the jiggery-pokery of oldschool HTML.

Let’s add another trick. Just as two adjoining <a></a> tags are a bit odd and somewhat mind-bending but perfectly legal, it is also legal, if odd and mind-bending, to place some text or a graphic inside the first <a></a>:

Now we’re able to do more than skip over what we don’t want. We can directly select what we do want. We can refer to this technique as a link-accesskey-anchor combination.

In both the cases above, the sequence of events goes like this:

We can now do some entirely new things. Take this example:

<table>
<tr><td colspan="2"><a href="#topnav" title="Home, About, Products, Contact" accesskey="T">Top navbar</a>
<a name="topnav"></a></td></tr>
<tr><td><a href="#leftnav" accesskey="L">First item in left-hand navigation</a><a href="#leftnav"></a>
Other items in left-hand navigation
<a href="#searcher" accesskey="S">Search function</a><a name="searcher"></a></td>
<td><a href="#top" accesskey="C"></a><a name="top">Regular page content</a></td></tr>
</table>

Now we’re able to do more than skip over what we don’t want. We can directly select what we do want. How? By selecting accesskeys in the above example:

You no longer have to leapfrog over multiple modules to arrive at the module you want. You can bring it into focus immediately.

Display issues

At time of writing, only iCab on Macintosh automatically displays accesskey. It would be an understatement to describe the users of this browser as a minority.

Quite apart from every other roadblock stopping us from using accesskey, this is truly the killer: For users of nearly every browser, every accesskey on your page will be invisible even if their browsers support accesskey. Of course, this is not in any way maddening.

You can kludge together a couple of solutions that make the accesskey visible. One works better than the other.

If your accesskey is a letter (or, I suppose, a number) that actually appears in the text of the link, you can underline the corresponding letter. The el-cheapo way is to use the “deprecated” <u></u> element:

<a href="/index.htm" title="Homepage" accesskey="H"><u>H</u>ome</a>

Problems? Interposing a <u></u> element interrupts the word. “Home” is a pronounceable word; “H ome” isn’t. Once again, an access provision meant to make life easier for the mobility-impaired gets in the way of the visually-impaired.

Even if you use stylesheets, you still interrupt the word. A style declaration like this –

a:link { text-decoration: none }

span.u { text-decoration: underline }

– lets you underline arbitrarily-long sequences of characters, but you have to turn the underlining on and off with a <span></span> element. While not “deprecated” and thus kosher, you’re still breaking up a word:

<a href="/index.htm" title="Homepage" accesskey="H"><span class="u">H</span>ome</a>

Evolt.org uses this approach. Here, an accesskey="a" is mirrored in an underlined letter A, <u>A</u>rticles, all within table cells and using accessible form markup of the sort discussed in Chapter 12, “Forms and interaction”:

<tr><td colspan="2" class="side"><strong><label for="article_search"><u>A</u>rticles</label></strong></td></tr>
<tr>
<td class="side"><input type="text" tabindex="10" accesskey="a" name="keywords" id="article_search" value="" size="10" maxlength="50">
</td>
<td class="side">
<input type="submit" tabindex="14" value="Go">
</td>
</tr>

There may be a vaguely tidier solution: The p.initial:first-letter pseudoclass, to which you can apply whatever formatting you like:

a:link { text-decoration: none }

p.initial:first-letter { text-decoration: underline }

Then you can write your link text with confidence:

<p class="initial"><a href="/index.htm" title="Homepage" accesskey="H">Home</a></p>

Your confidence will, however, be shaken once you realize:

Further, 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.

Possible solution

If we accept the principle that you have to make your accesskeys visible, you might as well just add the accesskey after the link. We’ll call this an accesskey legend.

<a href="/home.htm" title="Homepage" accesskey="H">Homepage</a> <small>[H]</small> |
<a href="/cust.htm" title="Already a customer? Log in here" accesskey="L">Login</a> <small>[L]</small> |
<a href="/reg.htm" title="Register to shop" accesskey="R">Register</a> <small>[R]</small> |
<a href="/search.htm" title="Search" accesskey="S">Search</a> <small>[S]</small> |
<a href="/loc.htm" title="Store locations (and phone numbers) and opening hours" accesskey="H">Locations & Hours</a> <small>[H]</small> |
<a href="/cc.htm" title="Apply for a credit card" accesskey="C">Credit card</a> <small>[C]</small> |
<a href="/about.htm" title="About us" accesskey="I">Company info</a> <small>[I]</small> |
<a href="/faq.htm" title="FAQs" accesskey="F">FAQs</a> <small>[F]</small>

You can use whatever typography you like: <letter>, letter by itself, letter* with the asterisk as a link to a little explanation of accesskey.

You can add a title to the accesskey legend to explain the system you’re using to a nondisabled visitor, or a mobility-impaired person who can handle a mouse for limited periods, or a screen-reader user.

<span style="font-size: smaller" title="Press this key (on Windows, use Alt plus the key)">[S]</span>

<span title="Press to activate: S, Alt-S, or Ctrl-S"><small>[S]</small></span>

Now, since we have a multiplicity of keystrokes available to select an accesskey on our many browsers and platforms, we do not enjoy the luxury of a single keystroke to cite in the instructions above. So we end up stuffing the equivalent of a flowchart into our title. And it still might not work.

Are we done yet with the problems? No. For browsers that display accesskey (at present, only iCab), your explicit addition of accesskey legends will result in a double display of the selected accesskey. I suppose this is a lighter cross to bear than keeping the accesskey a secret.

Future plans

If you add accesskey, then, you are really coding for a future utopia where:

I feel honour-bound to provide two pearls of advice that almost nullify one another save for the fact that adding an accesskey is technically simple:

Tabbing, tabbing, and more tabbing

The tabindex attribute is next up to test our patience. When added to certain tags, tabindex determines the order in which those tags are selected with each press of the Tab key.

You can apply tabindex to the following:

The use of tabindex on <a></a> (that is, hyperlinks) will be of greatest interest here.

The attribute takes the form of tabindex="". You insert a number inside the quotation marks. You can use any number you want, really, between 0 and 32767. Do not use negative numbers.

There is no requirement to use a consecutive sequence; all that matters is that one number must be lower than the next number in the tabbing sequence.

tabindex="0" is the same as having no tabindex at all.

In a hypothetical example consisting of seven links on a page, all of the following would produce exactly the same result – tabbing through the links in the order in which the numbers below are respectively listed.

To rework a previous example:

<a href="/home.htm" title="Homepage" accesskey="H" tabindex="100">Homepage</a> <small>[H]</small> |
<a href="/cust.htm" title="Already a customer? Log in here" accesskey="L" tabindex="200">Login</a> <small>[L]</small> |
<a href="/reg.htm" title="Register to shop" accesskey="R" tabindex="300">Register</a> <small>[R]</small> |
<a href="/search.htm" title="Search" accesskey="S" tabindex="400">Search</a> <small>[S]</small> |
<a href="/loc.htm" title="Store locations (and phone numbers) and opening hours" accesskey="H" tabindex="500">Locations & Hours</a> <small>[H]</small> |
<a href="/cc.htm" title="Apply for a credit card" accesskey="C" tabindex="600">Credit card</a> <small>[C]</small> |
<a href="/about.htm" title="About us" accesskey="I" tabindex="700">Company info</a> <small>[I]</small> |
<a href="/faq.htm" title="FAQs" accesskey="F" tabindex="800">FAQs</a> <small>[F]</small>

In this case, pressing the Tab key would move you directly to the Homepage link, and then, with each successive press of Tab, to Login, Register, Search, Locations & Hours, Credit card, Company info, and finally FAQs.

Awesome power, awesome responsibility

tabindex has no overt visible form, nor should it. An indexed tab is not a destination; it is a waypoint in a journey. You learn by doing: You find out where you’re going by going there, by pressing Tab and watching what happens.

Now, it could be argued that this approach is not exactly optimal. You’re used to tabbing ploddingly from one link (or item) to another, and now all of a sudden your cursor goes where the page author has told it to go.

Such cursor behaviour may come as a surprise, but it should be a welcome surprise. It signifies that you the designer have taken care to make the page accessible to someone using serial access via keyboard.

But with this awesome power comes responsibility. You need to add tabindex judiciously. As with accesskey, in the context of page navigation (as opposed, say, to navigation within forms; see Chapter 12), you should stick to high-profile navigation landmarks when it comes to tabindex use. Adding a tabindex to every little link on the page rather defeats the purpose; people can tab through every little link already.

What happens when you run out of tags with tabindexes? If you keep pressing the Tab key, where do you end up? This brings up the issue of browser compliance.

If you click in the document at some specific location, certain browsers (Explorer 4 and 5.01 on Windows, for example) will start tabbing after the point you clicked, not from page top. This only makes sense, but is not universal.

What about screen readers? With such adaptive technology, we’re suddenly dealing with three levels of abstraction:

  1. The underlying HTML
  2. The browser
  3. The screen reader sitting on top of the browser

Screen-reader makers canvassed on this topic all stated that their devices defer to the browser. They don’t particularly bother or attempt to interpret HTML in this case. So if your browser flubs tabindex – if you can never move the focus off tabindexed links and onto all the rest of the links – you have a wee problem. Except that screen readers have built-in controls to move from link to link anyway, and tabindex is of greatest use to mobility-impaired people, not the blind.

Skipping navigation

Can we use tabindex to skip navbars, that bugbear of accessible navigation?

Yes, in fact. Just add tabindex to the first link in each navigation island: First link in top navbar, first link in left-hand navigation.

What about search?

You can add tabindex to form fields, including search fields. You can easily place the form field for your search function in the tab sequence. Be sure to give the submit button the subsequent tabindex value. Then you can tab right into the search field, type whatever you want, and then tab directly onto the button that will execute the search.

Here’s what I use:

<a name="search"></a>
<form method="get" action="http://search.atomz.com/search/">
<input size="20" name="sp-q" value="" accesskey="!" tabindex="20000" title="Search" />
<input type="submit" value="" accesskey="\" tabindex="20001" title="Start the search" />
<input type="hidden" name="sp-a" value="000500b5-sp00000004" /></form>

Note that I retain <a name="search"></a> as an anchor for any of several other purposes, including the tortuous oldschool-HTML navigation-skipping technique exhaustively documented in these pages.

So do you really need that tortuous oldschool-HTML technique after all? Unfortunately, yes, because it works in absolutely every browser.

You could, in theory, make a reasonable judgement call here. If your server logs show that almost no one is using a browser that does not support tabindex, you could migrate all your navigation-skipping to that method. But as of this writing it is laughably unlikely that any Website on earth would show such a pattern of browser identifiers. This reasonable judgement call turns out to be unreasonable in practice.

Since tabindex support is better than support for accesskey, use of tabindex does not signify coding for a future utopia. It is merely a feature some people can use and some cannot. But then again, so are titles on everything, which Netscape 4 ignores resolutely. I’ve already suggested adding titles hither and yon and they are imperfectly supported. This is no different.

Numbering

Quickie advice on enumerating tabindexes: You’ve got 32,768 slots to play with. Don’t bunch them all together. There is no reason in the world to use a sequence of 1-2-3-4-5-6-7. What happens if you add a link between 3 and 4?

Even a vast Website with 80 or more navigation links can get away with enumerating tabindex by the hundreds: 100-200-300-400-500-600-700. You can then add intermediate tabindexes as you like. And that sequence works as well as any other ascending sequence. Sequential numbering is not required, or even desirable.

I would stay away from the extreme values of 1 and 32767. It might provide a sort of Cartesian satisfaction to use the very lowest or very highest figure, but you never know when you’ll need to add a link to the top or bottom of your page. Even starting at 5 and ending at 32765 gives you some leeway. But there is no reason even to start numbering that low. Use increments of 100 and you can still apply 320 different tabindex attributes, more than anyone would actually want to tab through in the first place. And don’t forget that a tabindex of 0 is equivalent to no tabindex at all.

(Why, then, does the W3C bother to list 0 as an option? So that you can add tabindex to every single link on a page but reserve its actual function for only some of the links, providing authoring consistency.)

The database problem

Perennially in this book, we find that maintenance of accessible Web pages is a bother. Assets like accesskey and tabindex give us one more thing to keep track of. You can’t reuse accesskey assignments or tabindex numbers on a page.

There are advantages to maintaining consistent accesskey assignments or tabindex numbers on pages with equivalent content: Your navbars, if they are the same on multiple pages, should contain the same accessibility features.

So how do you do it?

There is no unified method as yet, but some solutions are no-brainers. If you use a server-side include to add common navigation elements to your pages, accesskey and tabindex can be tucked handily away in your <a></a> tags. Ditto with search boxes or anything else consistently served into pages generated from a database.

But what if only certain elements recur in your pages, joined by other custom page-specific elements that are served from a database? You are going to have to come up with a system to avoid accesskey or tabindex conflicts. There isn’t an authoring program on the planet that will keep these assets straight for you, though of course there ought to be.

Conflict-resolution tables

For accesskey, it may be as simple as maintaining a file in a common server directory that lists which keys are attached to which links and other items. Given that this can change for certain pages, a table or perhaps a spreadsheet could be used to keep these facts straight.

Set up such a table after the content of the navigational elements to be served has been decided on but before it goes into the database. Assign your accesskeys in your spreadsheet, commit them to the code, and save to the database.

(Given that you are advised to use accesskey sparingly, it will not be a heavy burden to maintain that spreadsheet. On your site, you may use accesskey for only ten or twenty out of thousands of possible links. Not a lot, but what if two of them are both assigned to the letter C? Conflict resolution, to coin a phrase, should become part of your production schedule nonetheless.)

To that spreadsheet you could add a quickie explanation of how to arrive at accesskey assignments, e.g., “Use the first letter of the link. If that letter is already taken, try the consonant after the first vowel in the link. Careers = C, Company Profile = M, Contact = N.” That sort of thing.

Naming schemes

Since I’m here to solve your problems, I might as well expand that example and give you a few naming schemes you could use for accesskeys.

tabindex techniques

For tabindex, you can use a spreadsheet to keep track of which links have which numbers. This task will quickly become even more tedious than sorting out accesskeys because you have thirty-two thousand possibilities at hand. Lessening the burden is the knowledge that only a certain limited range of links deserve tabindex.

Now, what happens if the contents of the link – what’s inside the href="" – change continuously, as in a database-driven Website? In your spreadsheet, how do you keep track of which accesskey and tabindex go where?

If a certain string of text within that link never changes, the problem solves itself: Identify the link by that string alone. Examples:

If, on the other hand, the full URL is autogenerated on the fly, and finding a pair of identical URLs is about as easy as matching up snowflakes, your conflict-resolution database may need to refer to the links by the database fieldname.

Since the prime use for tabindex is to provide stable navigation links, such autogenerated URLs may not really come up because autogeneration would not be used in those cases at all. (Why does the link to the Careers page or the search box need database backing? Does it need so much database backing that there is never a consistent string of characters in all variations of the URL?) Occasional examples are, however, possible.

If your site offers a section of, say, Five Most Popular Downloads, you may want to make them a tabbing target with tabindex. But the exact links will change, possibly every few hours.

Here, the Numbers 1, 2, 3, 4, and 5 Most Popular Downloads occupy their own conceptual categories. Naturally, people are most interested in Numbers 1 and 5 (top and bottom of the list), but if it appears on the list at all it will be of interest. Maybe people will track the rise or fall of an item. (That’s particularly true with a bestseller list, which will surely hold more than five items.)

The exact identity of the Numbers 1 through 5 Most Popular Downloads will vary from time to time, but the five categories are invariant. You may wish to assign an invariant accesskey to each item in the hit parade, and you may also wish to establish a fixed tabbing order through them.

Your coding could look like this:

<ol> <li><a href="database-generated-URL" tabindex="100">Number 1 most popular download</a></li>
<li><a href="database-generated-URL" tabindex="200">Number 2</a></li>
<li><a href="database-generated-URL" tabindex="300">Number 3</a></li>
<li><a href="database-generated-URL" tabindex="400">Number 4</a></li>
<li><a href="database-generated-URL" tabindex="500">Number 5</a></li>
</ol>

If the URL constantly changes but you want accesskey and tabindex to remain respectively unchanging, what do you do?

In cases like this, let us heed the advice of Rudy Limeback, Toronto Web and SQL consultant (R937.com, Rudy.ca):

My suggestion is to use a name (like Favourite1) that is stored in the database and which acts as the selector of the particular database record which is retrieved for this href.

The database should probably also store the accesskey and tabindex for each entry, so that these remain unchanged (or updatable if desired) across all pages that carry that link:

<a href="database-generated" title="database-generated" accesskey="database-generated" tabindex="database-generated"></a>

In other words, in database-backed sites, you need to add accessibility features to the roster of data you track via the database.

How you do it will depend on your specific system. You know I’m here to help, but I’m not an expert on everything, and one Web topic on which I am assuredly not an expert is database programming; working up executable code you can drag and drop into your back end is half a book in itself, and a coauthored book at that. (Assuming it were even possible. Commercial content-management systems use proprietary coding methods that, apart from being essentially secret, can vary from installation to installation.)

I did do my homework here, querying various vendors of commercial content-management systems, all of whom refused to help. I have, however, given you a set of algorithms you can implement yourself. Some work remains your own.

Navbars and imagemaps

Now that we’ve gotten that over with, shall we move on to something a bit sexier, like navbars?

The term is rather broadly defined. Any set or block of navigation links can be called a navbar. A few styles are well-known; the continuum is well-represented by the text-only links of Yahoo at the low end, the tabs of Amazon in the middle, and so-called DHTML (dynamic HTML) drop-down menus at the high end.

There aren’t a whole lot of accessibility issues in text-only navbars that you don’t already know about. They’re just links. You may wish to skip some of them, or assign accesskeys or tabindexes.

Things get interesting when we concern ourselves with graphical navbars. And that really means imagemaps.

The basics

Note: If you’re already familiar with basic HTML, you can skip this section.

An imagemap is a graphic image whose parts are selectable (which usually means clickable).

In a hierarchy of complexity, imagemaps sit one step higher than simple images. You can easily turn an image as a single unit into a single hyperlink: Just stick the <img> element inside the <a></a> element.

<a href="home.htm" title="Back to homepage"><img src="/img/home.gif" height="40" width="30" alt="Homepage" title="[Back to homepage]" /></a>

In this example, the visitor must select the image to get back to the homepage. The link is a picture. If the picture is absent or you can’t see it, the alt and title provide text-only analogues. No problem.

You can, however, subdivide an image so that certain parts are clickable (and, optionally, certain other parts are not). The selectable areas are hyperlinks that are kept logically separate.

To create an imagemap, you use the <img> element you have come to consider a close confidant, adding the map="#name" attribute. Somewhere else in your HTML document, you define a <map></map> with that same name; in almost every case, it will contain area elements that map out a set of selectable or clickable image regions.

In the simplest case, inside your <map></map> element you list the hyperlinks you wish to assign to each region of the image. You can define a region of any arbitrary polygonal shape, but nine times out of ten you’ll use a rectangular section, which you define using the x and y pixel coordinates of the top-left and lower-right corners. (Start measuring at the top-left corner.)

A basic example might look like this:

<img src="a.gif" width="92" height="89" alt="About us" title="Company information" usemap="#ona" />
<map name="ona">
<area shape="rect" coords="0,10,92,27" alt="Contact information" href="contact.asp" title="Postal and E-mail addresses, phone and fax numbers" />
<area shape="rect" coords="0,29,92,47" alt="Jobs" href="jobs.asp" title="Work for us" />
<area shape="rect" coords="0,49,92,67" alt="Privacy policy" href="privacy.asp" title="How we use your personal information" />
<area shape="rect" coords="0,69,92,87" alt="Copyright" href="copyright.asp" title="Copyright notice" />
</map>

It should be noted that you can include more than a hyperlink in a <map></map>. Any block-level element, like a list or a <blockquote></blockquote> or even a paragraph, can be encompassed within the element. Here in the real world, however, the only use of <map></map> you will run across is the creation of image-based hyperlinks.

Access techniques

Surprisingly enough, imagemaps aren’t hard to make accessible. HTML keeps the various components of an imagemap separate, and you can add access features to each of them. The results are usually quite pleasant.

Just as adding text equivalents to images is half the battle in Web accessibility in general, adding text equivalents to imagemaps is more than half the battle here. It’s dead simple: Just use alt and title on any area that is graphical in nature. (If for some oddball reason you’re using a text-only area, which I’ve never encountered in all my days on the Web, stick to title.)

You must use an alt on all graphics. It’s not optional. Graphics inside area are not excepted. title is of course optional but helpful.

Among other things, if you use alt and title on area, Lynx users will have meaningful access to your imagemaps. Typically, Lynx displays a placeholder for an imagemap. Exactly what you see as a placeholder varies: [USEMAP] if you haven’t specified an alt on your img link, or of course the actual alt if you have.

In either case, select that link and the otherwise-clickable URLs specified in area are presented as a tidy column of selectable links. That is, the URL is listed, in its full hideous spectacle, unless you have been thoughtful enough to give us a title on each of your areas. Which would you rather look at, a list of raw URLs or a nice tidy word?

(Note the asymmetry: For this specific purpose, you need an alt on the graphic that represents your imagemap and titles on all the selectable areas within it. So why bother with alt on those selectable areas? They’re required, first of all, in order for your page to validate as XHTML; otherwise, they are used in the traditional way, as substitutes if the graphic isn’t loaded and for assistive technology.)

MSNBC.com does it right on its homepage. Lynx makes it look like this:

TV News

MAP: http://www.msnbc.com/news/default.asp#ona

* Today show
* Nightly News
* Dateline NBC
* MSNBC Cable

Note that the four choices are listed in plain English.

Meanwhile, MSNBC does it quite wrong on the same page:

Navigation

MAP: http://www.msnbc.com/news/default.asp#nmMap

* http://www.msnbc.com/tools/nm/nm0.asp?c=N1
* http://www.msnbc.com/tools/nm/nm0.asp?c=N2
* http://www.msnbc.com/tools/nm/nm0.asp?c=N3
* http://www.msnbc.com/tools/nm/nm0.asp?c=N4
* http://www.msnbc.com/tools/nm/nm0.asp?c=N5
* http://www.msnbc.com/tools/nm/nm0.asp?c=N6
* http://www.msnbc.com/tools/nm/nm0.asp?c=N7
* http://www.msnbc.com/tools/nm/nm0.asp?c=N8
* http://www.msnbc.com/tools/nm/nm0.asp?c=N9
* http://www.msnbc.com/tools/nm/nm0.asp?c=N10
* http://www.msnbc.com/tools/nm/nm0.asp?c=N11
* http://go.msn.com/npl/msnt.asp

It is unreasonable to expect people to figure out what each of those entries means. The simple addition of title would have avoided this embarrassment.

In most graphical browsers, alt on area remains invisible unless the image is missing, while title on area pops up as a tooltip. It’s very useful, actually, and it adds fun and richness. Your imagemap can be made up of inscrutable icons or short keywords; title fills people in on where they’ll go if they select the link.

Writing imagemap text equivalents

Use the same principles applicable to creating alt and title for any other kind of graphic: The former sums up the function of the graphic, while the latter tells us more, in whatever manner you decide.

If your imagemap consists of pictures of text, your choice of alt is self-evident: Retype the words rendered in bitmaps.

Icons in imagemaps

If your imagemap is made up of graphic images, use alt to tidily summarize the function of the image (“Shop” for a shopping cart, for example). Hardly surprising advice at this point. You will be stupefied further by my advice to go nuts, if desired, with title.

And of course the dual approach must be considered: If your imagemap consists of little graphic icons and also accompanying pictures of text, then reproduce the text. Don’t try to describe the little icons. Indeed, you cannot add a longdescription to an area. It rather staggers the imagination to contemplate an imagemap graphic so complex it would require one.

Tabbing

The tapeworm and hookworm of Web accessibility, accesskey and tabindex, can be applied to the <area></area> element inside imagemaps.

All the usual principles apply: Use accesskey for significant and (in most cases) invariable navigational landmarks and tabindex for items you absolutely want visitors to tab through.

But there are added complications. Here in the real world, imagemaps are all graphical. How do you display the accesskey keystroke? At least with textual links, certain browsers would do it for you, or you could kludge up a solution that might make you feel tawdry and cheap afterward but would actually work. Here, what are you supposed to do? Add a little letter C or numeral 7, as the case may be, to each tiny graphic?

Actually, in some cases that wouldn’t be so awful. Nice big buttons could easily swallow up a tiny little character. You could position accesskey legends off in the corner or something. Rather conspicuous, but it could be done. For smaller images? Forget it.

And besides, what happens if the accesskey changes? (It could, you know.)

It may be practicable to make tabindex work with area in imagemaps, but accesskey remains impracticable.

You Are Here

As visitors move around your site by selecting destinations in its navbars, you’ll want to let them know exactly where they are. The standard approach is to highlight the segment of the imagemap that corresponds to their current location. If the default appearance of an imagemap is white type on a grey ground for unexplored areas, you could use black type on cream to indicate You Are Here.

It works very nicely for sighted people. But what about the blind?

The use of colour as the sole differentiator of two items is prohibited by the Web Content Accessibility Guidelines. Now, there are a few tricky cases, fully explored in Chapter 9, “Type and colour,” but in this particular example let’s assume that the disabled visitor cannot see your navbars at all.

A You Are Here location can be inferred from the state of the region of the imagemap: The current location ceases to be selectable; it ceases to be a link. (If you have set up your imagemap so you can select a link corresponding to where you are already, change it, because that makes no sense whatsoever. Among other things, there shouldn’t be a link called “Home” on the homepage or a link called “Contact us” on the Contact Us page. You can use plain text or a plain image to convey those words, but not a link. Seemingly obvious, but I do run across it from time to time.)

Screen readers, with uncommon exceptions, have no trouble differentiating a link from plain text. So this inference method can suffice if necessary.

But it won’t kill you to do more than the minimum. Try using a different alt and/or title for the You Are Here location. In other words, tell people explicitly where they are through the alt and/or title. We can call this a “You Are Here legend.” Some schemas to consider:

Should you put these legends on the alt or the title or both? Both. It’s important and you don’t want anyone to miss it.

But wait: The You Are Here segment of the imagemap isn’t a link, is it? I just finished telling you to make sure it is not. That means you can’t put it inside an area element. How do you add an alt or title, then?

Well, you can add a nonlink to area. We have the nohref="nohref" attribute for just that purpose. An example might look like:

<area nohref="nohref" alt="You are here: Store locator" title="You are here: Store locator" COORDS="60,40,100,60">

(In XHTML, attributes may not be “minimized.” In oldschool HTML, we could simply use nohref by itself, but in XHTML an attribute must always equal something. Here we set the attribute to equal itself, as in nohref="nohref". Some older browsers choke on this notation, but they are older browsers, and we cannot help the aged forever.)

Using this technique, you or your content-management system can switch between an <area></area> that brings you to the store-locator page and another one that reminds you that you are already there once you arrive. The former has an active hyperlink, the latter does not. It’s all fully legal HTML and is rather neat and tidy.

If you use breadcrumb navigation of the sort popularized by Yahoo, where the entire sequence of navigation steps from the homepage to your current location is listed, you may have nothing to worry about. I’ve never actually seen a graphical breadcrumb navigation system, which may indeed be conceptually impossible in the first place. It is generally obvious in breadcrumb-navigation schemes that the last entry in the list is the current location. In this example from Yahoo –

Home > Regional > Countries > New Zealand > Business and Economy > Business to Business > Health Care > Dentistry

– the only item that isn’t a link in the actual Web page is the word “Dentistry,” and it is evident even to screen-reader or Braille users that the last item represents the current location.

Now, it must be stated that breadcrumb navigation is meant to be scanned. Sequential access is inconvenient; it is a bother to have to listen to all the links read out or wade through them in Braille. But it is an unavoidable bother.

Hierarchies

What if your imagemap has two or more bands of navigation links, for example, city locations up top and services offered in those locations below? How do you communicate the visitor’s location as an intersection of those imagemaps?

In all the discussions below, we’re talking about marking up not entire navbars or imagemaps, but only the individual area elements that, when put together, tell visitors where they actually are. Imagine two rows of tabs on an E-commerce site: We’re making one tab from the top row and another tab from the bottom row accessible. It is this combination of tabs that tells the visitor where he or she is in the hierarchy formed by two levels of imagemaps.

The strongest approach is to code each band of navigation links in a separate imagemap. That will be more work for you. It is quick and easy to load everything into a single imagemap; authoring programs will do that for you automagically. To do it my way, you will have to slice your graphic into two or more pieces (though authoring programs will do that for you automagically, too) and set up separate imagemap coding sequences for each.

Nonetheless, all this remains an imperfect solution. Sighted visitors can see at once that an upper-level navbar connotes a higher structural level, with each navbar below occupying a lower level. Sighted visitors have random access to the entire screen and can subconsciously understand relationships even without staring directly at one object, then another, and deducing the relationship between the two.

But when interpreted serially, as screen readers and Braille displays must do, the separation is less clear. Solutions to this dilemma are imperfect, to be frank. You can use a You Are Here legend schema on both levels, which will result in screen-reader users’ being told where they are twice – once for the high-level or top or first imagemap, once again for the next.

While confusing at first blush, in the real world it is not particularly mindblowing to be in two places at once, at least if you expand your conception step by step through ever-larger degrees of detail. You can be in bed in your apartment; in Sydney in New South Wales; in the back seat in your car; in the waiting room of the doctor’s office.

Online, you can be in the Consulting section of the Services department, or the Permits subcategory of the Licences & Permits division. Hearing “You are here: Consulting. You are here: Services” isn’t all that confusing. It’s not very clear, either, for that matter.

Or you can be very clever. You can use different writing styles for the respective navbars. You could use “You are here” for the highest level and a custom-written category label for lower level(s). To recast the foregoing examples:

In other words, use a descriptive approach. Imagine you’re talking to a caller who was transferred from the main switchboard so many times that he or she is confused. “Who am I speaking with?” the caller asks. “It’s the Permits desk in the Licences & Permits department.”

There is another tack which, while radical and barely legal on paper, may be the most sensible. Add a You Are Here legend only to the lowest or most specific level in the hierarchy.

In the foregoing examples, the upper navbar would use alt="" title="". Lower navbars would provide alt and title along the lines of You are here: Services: Consulting or [Permits desk, Licences & Permits division].

In other words, tell people where they are at their final destination; don’t nag at them at every step along the way.

If you have a really extensive hierarchy of navbars (three or more – almost unheard-of and generally inadvisable from a usability perspective), then this approach makes the most sense. And it is not illegal to use alt="" title="" by any means. We use alt="" on spacer GIFs and other meaningless graphics all the time. It is true that a screen-reader user may become aware of an absence in the topmost navbar, but really, won’t it be only the superkeen screen-reader users who mentally compare one page’s navbar to another on a site who will ever notice? And does it particularly matter, given that the lower navbar’s legends are utterly clear and comprehensible?

By the way, this approach of splitting navbars into pieces may require the use of adjacent table cells with cellpadding="0" cellspacing="0" border="0", which adds manageable but unavoidable complexity. Suddenly the screen-reader user is manipulating not merely an imagemap but an imagemap in a table.

What if you use a cutesy navbar where the lower level is the main one (denoted, say, through larger type) and the upper level is the subcategory? (You might see this technique combined with a picture – big main navbar below the picture, smaller sub-navbar above.) Well, you may simply have to stop being cutesy. When these are interpreted sequentially, disabled visitors are going to hit the sub-navbar first.

What if some of the apparent hierarchy is actually an illusion? As an example, imagine a photograph bordered by graphical links at the top and bottom that are positioned for graphic effect and not because one set of links is more important. You may hope that people will see an order to the listing, but you don’t want to give the impression that one set of links is higher up the food chain than another.

DHTML: Don’t do it

What if you use one of those whiz-bang DHTML (dynamic HTML) drop-down navigation bars that mimic the menubars found in computer operating systems?

They’re increasingly common, they’re difficult to code (due largely to cross-browser incompatibilities), and in most cases they add needless complexity to Websites. They rely on the so-called Document Object Model, an amalgam of HTML, stylesheet, and JavaScript methods that is poorly standardized.

The knock against DHTML menus is their reliance on a mouse. Blind and mobility-impaired visitors cannot really use a mouse. There is currently no way to get DHTML menus to work purely via the keyboard. That makes DHTML menus nominally inaccessible.

There is one way to make DHTML menus work. Set up your pages so that the title of each menu – the word, image, or option that is visible even before the visitor attempts to explore or pull down the menu – is a plain hypertext link to a separate page that lists all the links inside the menu.

Imagine your DHTML menu displays the phrase About Us in its inactive state. When visitors click or simply mouseover that phrase, a list of menu options appears: Company Information, Jobs, Offices, Privacy Policy, Copyright. A nondisabled person could simply choose those options from the menu, and the hyperlink associated with the option chosen would be actuated.

In the accessible case, however, you must make the About Us region a plain hyperlink to another page that simply lists all the same options in ordinary hyperlinks.

Yes, this will require you to set up as many additional pages as there are headings or titles for your menus, but that is not exactly onerous. If the contents or URLs of menus change (as they might, especially on a newspaper site), then the contents or URLs must also change in the backup pages.

It is not good enough to fob off a disabled visitor to some kind of static navigation, like a fixed navbar or bottom-of-page links, when neither of those duplicates what the DHTML menu lets you do. In other words, you are not allowed to say “If you can’t handle the menus, you’re stuck with whatever other navigation is on the page, even if it doesn’t take you where the menus could.” That does not constitute equivalence or accessibility.

DHTML menus are an advanced Web technique and I am raising the bar in response to that fact. If you have enough programming skill to create DHTML menus in the first place, it is child’s play to set up ordinary backup pages. You may have to do some work to get your database or content-management system to propagate the same contents or URLs on those pages, but your fate was sealed in that respect the moment you decided to use drop-down menus and also make your site accessible.

There is no standard set of routines for keyboard handling in the World Wide Web Consortium’s specifications for the Document Object Model. They say so right up front: “The DOM Level 2 Event specification does not provide a key event set. An event set designed for use with keyboard input devices will be included in a later version of the DOM specification.” As of this writing, DOM Level 3 merely calls for keyboard handling as a future requirement: “The specification must define a set of key events to handle keyboard input. This key event set must be fully internationalizable.”

At some later day, if the World Wide Web Consortium ever bothers to come up with standard keyboard routines for the Document Object Model on which DHTML menus are based, then we might be able to cook up an accessible technique that does not require something as inelegant as backup pages. I doubt this will happen at any time within the next five years. If you insist on using DHTML menus, you must also use the technique I have described.

Bottom-Line Accessibility Advice

Basic accessibility

Intermediate accessibility

Use accesskey and tabindex attributes.

Advanced accessibility

Use skip-navigation links to allow easy focus movement from landmark to landmark on a complex page.

Previous   ¶   Contents   ¶   Next