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