Chapter 7: Accessible Navigation by Jim Thatcher

The previous chapter focused on creating accessible content—content that is compatible with assistive technologies and that provides alternatives to nontext elements such as images and audio. We discussed how web pages can be constructed more effectively and designed to be easily accessible by people with disabilities.

In this chapter, we will discuss the accessibility issues of getting around a given page, within the website and to other websites. The distinction between navigation and content is somewhat unrealistic. Several of the issues discussed in Chapter 6 certainly influence navigation. For example, if you don't provide text equivalents for images that are links, then people using screen readers or text browsers won't be able understand the links on the page as they navigate through them. Similarly, if you have not included alt-text for image map hotspots (<area> tags), then large portions of the page will make no sense at all to people using assistive technologies. Unrealistic though the distinction may be, this chapter will cover the navigation topics of reading order, headings navigation, skipping over navigation links, accessible frames, accessible image maps, layout effects on navigation, and accessible links. First, let's take a look at some of the obstacles that people with disabilities face when they try to navigate through a web page.

Navigation Considerations

Usually, when web designers or developers think about "navigation," it is navigation within the website—getting from section to section to accomplish some task like searching for an item, finding it, and going through the process of checking out and purchasing it. These web professionals are probably not thinking about navigating within a single page because that is not what a sighted user does.

Let's look at a sample page, the homepage of the U.S. Department of Agriculture (USDA), shown in Figure 7-1.

Figure 7-1

Figure 7-1. The USDA homepage.

The headlines for news items on the USDA homepage are listed in the center of the page, about an inch and a half down from the top. Since I can see the screen, those headlines are very easy for me to spot and read. But if I wanted to read those same news headlines with a screen reader, it would take a while. There are about 106 words before the section heading, In the News, and it takes around 51 seconds to listen to those words with the JAWS for Windows screen reader (at its default speech rate).

The difference between what a mouse user is able to do to focus on the news items and what a keyboard user must go through is really quite astounding. If you can see the screen and want to read the details of the first news item, you simply click the corresponding link, such as The Philippines Lifts Ban On U.S. Beef And Beef Products. It is so easy and takes less than a second. It is what most web designers and developers do and expect others to do. But if you can't use the mouse, you must use the keyboard (or another more cumbersome input device) to move the input focus from wherever it is on the page (if you can find it) to the link that you want to follow (of course, you may not be able to know what link you want to follow), and then press Enter. The USDA homepage has about 28 links before the first news item. If you are starting from the top, that is the number of times you must hit the Tab key to get there.

Many users can see the screen, but are not able to use a mouse. If you are one of those users, as you tab through the links towards your desired target, you must follow the focus rectangle in order to know where you are. That is often very difficult and even impossible. In Figure 7-1, input focus is on Newsroom (in the center of the horizontal navigation bar at the top of the page), but that certainly isn't obvious. If you are using a screen reader, at least you have the advantage of being able to hear each link as you go along.

Keyboard navigation of the web page is very important for many users, whether or not they use a screen reader. As a web author or web designer, you can do some simple things to make that process of page navigation much easier for your site visitors, especially those with disabilities. And there are important things that must be done if your page is going to comply with the U.S. Access Board Section 508 Standards for web accessibility or the Web Content Accessibility Guidelines (WCAG) from the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).

Reading Order

Whether you use tables or standards-compliant Cascading Style Sheets Version 2 (CSS 2) positioning (see Chapter 9) to lay out your page, a screen reader will find (speak) the page in the order of the HTML source code. The speaking order may have very little to do with the way you see the page, in the sense that blocks of text could appear in quite different positions than those apparent from looking at the page.

If the page uses tables for layout, you can have a general idea about the order in which items will be visited or spoken just by knowing where the table cells are. Linearization, as described in the discussion of layout tables in Chapter 6, is what happens when source code order is applied to a layout table. A table is spoken by starting with the first cell and speaking everything in that cell, including any nested tables. Then you go to the next cell in the first row, speak that, and continue until you finish the first row. Then on to the second row, and so on, continuing in this way through the whole table.

Table reading order becomes confusing or surprising when spanned rows come into play. In the table shown in Figure 7-2, the first row consists of a single cell spanning three columns and that is spoken first ("Sample Layout Table"); it is first in the source code order. The first cell of the second row spans two rows, but the content of that cell comes next in the source code, and so is spoken next ("Navigation link 1 Navigation link 2 Navigation link 3 Navigation link 4"). Then the second cell of the second row ("Banner ad") is spoken. Next, the screen reader speaks the third cell of the second row, which spans two rows ("Right Navigation 1 Right Navigation 2 Right Navigation 3"). The last part of this hypothetical layout table might be a main content area of a page. It is the second cell of the third row and last in the source code order ("Main content area with lots of text and content filling the center part of the window").

Figure 7-2

Figure 7-2. A hypothetical layout table

The only thing complicated about this idea of source code order is that you cannot know what source code order is by looking at the page. You need to look at the source code, which can be awkward at best! There are tools that can help. Figure 7-3 shows the CNN homepage modified using the Web Accessibility Toolbar (see Chapter 5). Use the Structure > Table Cell Order menu item to indicate the reading order of table cells.

Figure 7-3

Figure 7-3. CNN homepage showing the reading order of table cells.

If the site uses CSS positioning to present the page, there is no way you can be sure of the order in which blocks of content will be spoken—that is, which blocks come before others in the source code order. Again, there are tools to help with this. The WAVE tool (see Chapter 5) can be use to indicate the order in which a sections of a page will be spoken.

Figure 7-4 shows my homepage ( modified by the WAVE to highlight the "chunks" on the page (divs) and their position in the source code order.

Figure 7-4

Figure 7-4. Screen shot of using the WAVE to highlight reading order.

For CSS-based pages, I think it is much simpler to just view the page with CSS turned off. This is most conveniently handled with the Web Accessibility Toolbar. Use the CSS > CSS On/Off menu item. With Firefox and the Web Developer Extension toolbar, use the CSS > Disable Styles > All Styles menu item. Figure 7-5 shows part of my homepage, this time with CSS turned off. This is precisely the order in which the page will be spoken or visited with a screen reader.

Figure 7-5

Figure 7-5. Screen shot of with CSS disabled to view reading order.

Heading Navigation

Now you know that text will be spoken and links visited in order of the text in the source code. How can a user get around a web page conveniently with just the keyboard, without using the mouse? "Get around" means being able to read different areas and being able to follow links scattered through the page.

As you saw in the example of a layout table in Figure 7-2, it is possible that everything is spoken before the "main content." It is not that the information with that layout does not make sense, because it does. In this very simple mockup of a page, the main content takes up a quarter of the page. People who are listening to the page may need to wait through three-quarters of the words when what they really want is that main content. The problem of having to navigate through the navigation links in order to find the main content reoccurs, page after page after page.

In the late 1990s, I advocated a "skip navigation" link at the top of every page (discussed in the next section) because screen reader users were being overwhelmed with all the information that preceded the main content on the page. As Vice-Chair of the Electronic and Information Access Advisory Committee (EITAAC), empanelled by the U.S. Access Board to propose accessibility standards, I urged the adoption of a provision addressing this issue, and here is the result:

§1194.22(o) A method shall be provided that permits users to skip repetitive navigation links.

Even though it is far from perfect, it was very important that this provision became part of the Section 508 Standards for web accessibility. It raised awareness of the problems with keyboard navigation and now serves to encourage (or require) headings navigation.

It was disappointing that WCAG 1.0 hardly addressed this fundamental problem of keyboard page navigation at all. Two Priority 3 checkpoints in WCAG 1.0 are related to the issue of keyboard navigation:

13.5 Provide navigation bars to highlight and give access to the navigation mechanism. (Priority 3)

13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. (Priority 3)

But these checkpoints really do not address the problem. The Last Call current draft of WCAG 2.0 brings this issue to the forefront through Guideline 2.4 and its Level 1 success criterion:

Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it.

2.4.1 A mechanism is available to bypass blocks of content that are repeated on multiple Web units. [Level 1]

HTML has heading tags, <h1> through <h6>. Viewed as navigational features, when you use these heading tags, their presence can be programmatically determined. If you have "section headings" just styled with bold or certain background colors, their status as section headings or navigational features cannot be determined. Refer back to the USDA web page shown in Figure 7-1. I think it is obvious that Search, My USDA, In the News, and I Want To are section "headings," but they are not marked up that way. In fact, all of these sections headings are images. They have appropriate alt-text, and those images could easily be wrapped in heading tags to provide significantly improved navigation.

The reason this is all so important is that recent versions of screen readers allow a user to navigate the headings on a page by simply pressing the H key (Shift+H to go to the previous heading). If a page is well structured and the headings are marked up as HTML heading elements (h1 through h6), then a screen reader user can easily get a useful survey of the page content and useful access to that content by just navigating through (listening to) the headings on the page with the H key.

To satisfy Section 508 provision §1194.22(o), if the main content begins with a heading (which certainly should be the case), it is an easy matter to skip over repetitive navigation links to get to the main content.

Figure 7-6 shows the Green Methods homepage. This is an interesting site with several accessibility features, including headings markup. I have used the Web Accessibility Toolbar (discussed in Chapter 5) to mark up those places where heading tags are used. Note that all the section headings are, in fact, HTML headings as they should be, and a keyboard user can, with eight keystrokes, get a quick and comprehensive outline of the structure on the page, and begin to read the section of interest.

Figure 7-6

Figure 7-6. Screen shot of showing distribution of headings markup.

You might be concerned as to whether or not the U.S. federal government accepts headings markup instead of skip links for Section 508 compliance. The U.S. Access Board developed the Section 508 standards and provides guidance, technical assistance, and resources on accessible design. The Section 508 page of the Access Board site has no skip links and uses headings navigation instead. That should put that concern to rest.

You should use headings markup to address keyboard navigation of your page, in particular to be able to skip over repetitive navigation links and to get to the main content. Additionally, if you think about the sections of each page, and label those sections with headings, your whole site will be clearer and easier for everyone to use.

What about keyboard users who are not using an expensive screen reader? The Opera Browser provides headings navigation from the keyboard. Use the S key to move forward from heading to heading; use the W key to move through headings in reverse direction. Remember that with Opera, links are accessed with the A key instead of Tab, and the Q key goes through links in reverse direction, like Shift+Tab. At the time of this writing, only the first beta of Microsoft Internet Explorer 7 has been released to a small set of MSDN subscribers. I hope that headings keyboard navigation will be implemented in that version.

Skip Navigation Links

As discussed in the previous section, the correct way to deal with page navigation is to use headings. This section reviews techniques used to provide the ability to skip navigation links (you may still want to use that approach, in addition to headings). Then we will look at how skipping text blocks works with assistive technologies.

Creating Skip Navigation Links

Let's survey the techniques for skipping links. We will look at four methods for providing skip navigation links:

After reviewing these techniques, I will point out a serious issue with skip links and Internet Explorer 6 that applies to all in-page links—all links that go from one spot on a page to another spot on the same page.

Placing a Link in Normal Text

The simplest technique is to just place a text link at the top of the page. I believe that one of the first skip navigation links was that used by the American Council of the Blind (ACB). The ACB site has a link at the top of the page in a small font with link text, Skip Navigation Links, as shown in Figure 7-7.

Figure 7-7

Figure 7-7. The ACB homepage has a visible skip link.

When a visitor using a screen reader opens the ACB homepage, the first announcement is "Link skip navigation links." If users want to listen to the navigation links, they can just ignore this skip link, just as they can ignore any other link. On a first visit to the page, the user might indeed want to listen to those navigation links, but the presence of the skip link empowers the screen reader user with the choice.

The code for the skip link at the top of the ACB homepage looks like this:

<a href="#nonav"><font size="-2">Skip Navigation Links</font></a>

The ACB web developers placed the defining anchor with name="nonav" on the ACB logo image:

<a name="nonav">
  <img src="acob5.gif" alt="American Council of the Blind"...>

That means when the skip link is followed, the alt-text for the logo, "American Council of the Blind," is the next item to be announced.

The definition of the local anchor does not need to have content. The code <a name="nonav" id="nonav"></a> is valid and could have been placed just before the Welcome to the website for the American Council of the Blind text on the page (see the following discussion of in-page links). This is a very important part of the skip navigation idea. The target anchor does not need to enclose any content. As such, it can easily be placed in a template to be used for all pages based on the template.

The ACB site seems to take the words skip navigation links literally. Their skip link just skips over the two lines of text links at the top of the page and does not skip over the logo or the search fields. I would code the target of the skip just before the main content, starting with Welcome farther down the page.

A contemporary CSS-based page is the Guild of Accessible Web Designers (GAWDS) homepage. Part of that page is shown in Figure 7-8.

Figure 7-8

Figure 7-8. The top of the GAWDS homepage has three visble skip links.

Notice that there are three navigation links at the top of the page, offering jumps to the content, diary archive, and news feeds. This page includes 15 headings (one h1, three h2, and eleven h3), so heading navigation is well supported. The three navigation links provide access to key areas of the page in addition to heading navigation.

People with disabilities are best served when the skip navigation links are on-screen and normal text. Users who can see the screen but do not use a mouse will not be surprised when links appear or disappear. For example, on the GAWDS page, users can set about a task to read about RSS feeds by first tabbing to the Jump to news feeds link, activating that link, and then reading in the resulting section. When the links are hidden, as discussed next, their existence is a surprise and, on an unfamiliar site, a plan of action is hard to establish.

Creating a Link As Alt-Text on an Invisible Image

The CNN site, shown in Figure 7-9, has had a skip navigation link for a number of years. The CNN page has a top area, including a logo and a search field, and then a long list of navigation links down the left and right sides of the page. The left navigation is site navigation. The MORE NEWS navigation on the right changes from day to day and is local to the area of the site (U.S. in Figure 7-9). If you tried to use the Tab key to get to the main story (the main content)—in this case, 9/11 recordings, documents released—without using the skip link, you would tab about 28 times through the left navigation links. The surprising aspect of this site is that it has exactly one HTML heading: an h2 on the title of the main story. There are about ten other places on the CNN page that could use HTML headings; MORE NEWS is one that is visible in Figure 7-9.

Figure 7-9

Figure 7-9. has an invisible skip link.

An invisible GIF on the top-right of the CNN page is the skip navigation link. If you turn off images (for example, for Internet Explorer, under Windows, choose Internet Options > Advanced, check the Always expand ALT text for images option, and uncheck the Show pictures option), the link will appear far off to the right. Instead of turning off images, you can view the source code (View > Source Code in Internet Explorer), and here is what you will find, first for the image link, then the local anchor:

<a href="#ContentArea">
  <img src=""
    alt="Click here to skip to main content"
    width="10" height="1">

<a name="ContentArea"></a>

This local anchor, ContentArea, is just before the U.S. headline in red (which is actually an image with alt="U.S. News"). The anchor is in the template and above the content that changes hourly.

Let's summarize this method. At the top of the page, you place a link on an invisible image with alt-text such as "skip navigation" or "skip to main content" and with an href that points to a local anchor with empty content just above the main content. But do not say "Click here to ...", as on the CNN site; instead, just express the function of the link, "Skip to main content" (see the "Accessible Links" section later in this chapter for more on link text). This is a very practical method of providing a skip navigation link, satisfying the Section 508 provision without changing the visual appearance of the page or site.

The same technique is used on many sites, including IBM. Unlike CNN, which used one heading, IBM (at the time of this writing) uses no headings markup, and the only assistance for page navigation is that provided by one skip link.

This technique is designed so that the visual appearance of the page isn't changed at all. But what about keyboard users who are not using a screen reader? The accommodation of an invisible skip navigation link almost entirely leaves them out. I say "almost" because a keyboard user could, if desperate for keyboard access, watch the status area of the browser and notice the href of the skip navigation link appear, as shown in the example from Netscape 7.2 in Figure 7-10.

Figure 7-10

Figure 7-10. The href of the focused link shows in the status bar.

Using a Text Link Styled to Be Invisible

Figure 7-11 shows the top of the FirstGov portal site for the U.S. federal government.

Figure 7-11

Figure 7-11. The banner.

In October 2001, the banner was similar to what it is today. There were five links at the top of the page using very small text, which was the same color (white) as the background, styled like this:

<a href="#content">
  <font color="#ffffff" size="-6">Skip to content</font>

The skip links served as a kind of hidden table of contents, with a link to each of the main content areas of the page. They were Skip to content, Skip to Government search, Skip to Departments and Agencies, Skip to Reference, and Skip to Customer Survey. That table of contents was hidden from all users except those with a screen reader or those viewing the page with all styling turned off. Figure 7-12 shows the current page (as of this writing) with styling turned off using the Web Accessibility Toolbar (see Chapter 5).

Figure 7-12

Figure 7-12. Turn off CSS to expose the skip links on

Now there are twice as many skip links as before, ten of them at the top of the page preceding the banner, the search field, and the main navigation links: Skip to Main Content, Skip to Government Search, Skip to Bottom Nav, Skip to Top Nav Bar-Right Aligned, Skip to By Organization, Skip to Top Nav bar, Skip to Contact Your Government, Skip to Reference Center, Skip to Information by Topic, and Skip to Citizens: Get It Done Online!. The first skip link, Skip to Main Content, is a skip skip links link! These links are styled like this:

<a class="invisiblelink" href="#content">
<span class="invisiblelink">Skip to Main Content</span>
<a name="content"></a>

The style sheet includes invisiblelink styling:

.invisiblelink {
  font:bold 1pt Arial, Helvetica, sans-serif;
  text-transform:none; color:#ffffff;

These ten links are available (essentially) only to a screen reader user. How does this accommodation compare to using heading navigation (if headings had been coded on the page, which they were not)? There is no comparison. First, the many links added to the top of the page become a burden for a blind user with a screen reader. Second, if headings were used, then simple navigation keys can be interspaced with further line-by-line browsing, then continuing with previous or current heading. With the skip link table of contents, the user wanting to browse like that would need to go back to the top and step through the links again in order to skip to a different place.

Exposing the Link When It Receives Focus

A fairly new accommodation combines the idea of not cluttering the page with skip links and, at the same time, having links available to keyboard users who are not using screen readers. Figure 7-13 shows an example of a site that uses this approach. The figure shows the top part of the homepage of the Information Technology Technical Assistance and Training Center (ITTATC), which is funded to support Section 508.

Figure 7-13

Figure 7-13. The skip link on appears when it receives focus.

Three links at the top of the page are styled with a white font on a white background, until the link receives focus. Then the link becomes visible. In Figure 7-13, Jump to Main Navigation has input focus and is visible. The ITTATC skip link looks like this:

 <a href="#Content" class="InvisiLink" title="">Jump to Page Content</a>   

From the ITTATC style sheet, named ultimate.css, here is the style associated with the class InvisiLink:

A.InvisiLink {
  text-decoration: underline; color: #ffffff;
  font-family: Verdana, Arial,
    Helvetica, sans-serif, "MS sans serif";

For both pseudo class selectors :active and :hover, the style is slightly different.

A.InvisiLink:active {
  text-decoration: underline; color: #000000;
  font-family : Verdana, Arial,
    Helvetica, sans-serif, "MS sans serif";

The only change for the :active and :hover pseudo classes is to specify font color black (#000000), so that when you tab to the link or move your mouse over the link, it becomes visible.

A second example of this kind of accommodation is from my own site,, as shown in Figure 7-14.

Figure 7-14

Figure 7-14. The skip navigation link becomes visible on when focused.

Here, the skip link becomes visible when it receives focus, but is styled off-screen so it does not occupy screen space. The skip link looks like this:

<li class="skip">
  <a href="#cont" id="skpnav">Skip Navigation.</a>

In the next section, I will talk about the target of this skip link, which is a bit of a surprise.

Let's look at the styling of the class skip:

.skip a {
  padding: 0 0.5em; display: inline; z-index: 2; 
  text-decoration:none; position: absolute;
  width: 14em; left: -200em
.skip a:focus, .skip a:active {
  position: absolute; left: 0.5em; border: solid #333 2px;
  color: #fff; background: #555

With this styling, the inactive, unfocused skip link lies off-screen (left: -200 em) and is also available to a screen reader user. When the link receives focus using the Tab key, it is repositioned to be on-screen and is made visible.

The In-Page Link Problem with Internet Explorer 6

The target of the skip link on my website used to look like this:

<tr><td><a name="cont" id="cont"></a></td></tr>

Why a table? The answer is that there is a bug in Internet Explorer 6 that causes in-page links to not work from the keyboard. But when the target of any in-page link is placed at the top of a table cell, it will work correctly from the keyboard with Internet Explorer 6. What does work correctly mean? This description seems to be daunting for many web developers, who are so focused on and dependent on the mouse. Here is how to test any in-page link:

  1. Hide the mouse so you don't mess up this experiment.
  2. Use the Tab key to move to the in-page link that is to be tested.
  3. Press Enter. That will (probably) reposition the visual focus on the page so that the target of the in-page link is at the top of the visual window (if there is enough of a page to refocus).
  4. Now, and this is the key, press Tab again. This time, the Tab key should move to the first link below the target of the in-page link. Often, this is not what happens; instead, this Tab key press puts focus on the first link of the page, or generally some other unwanted place.

If you follow these steps with Netscape 7.2, Mozilla Firefox 1.04, or Opera 7.54 (substitute the A key for the Tab key in Opera), everything will work as you would hope and expect. This is not so with Internet Explorer 6.

For table-based sites like CNN and IBM (as of this writing), the skip links usually work because it is natural that the target is at the top of a table cell (td). For more contemporary sites like that of the WAI, for example, the in-page links do not work. Try the WAI homepage. Tab to the Skip to Content link and press Enter, and the visual focus moves, but when you press Tab again, the input focus is back at the top of the page. It should work, but it doesn't, at least as of this writing. This is true of many sites, and not just for skip links. For example, I have a short "table of contents" at the top of my comparison of Section 508 and WCAG. Though they are fixed now, up until recently, if you activated one of those from the keyboard, then tabbed again, you would be back at the top of the page.

What is the solution (read "work-around") for this problem? Through discussions on various mailing lists over several months in the spring and summer of 2005, the nature of the Internet Explorer 6 bug became clearer. In May 2005, Becky Gibson (of IBM) and Mike Scott (of MSF&W) independently recognized that when targets of in-page links were contained in elements "with width defined" (whatever that means), they generally worked from the keyboard. It was Terrence Wood who put it together with the hasLayout property.

When a link is activated, Internet Explorer 6 places input focus on one of the following:

The fact that table cells are in this list explains why in-page links usually work in table-based pages. The presence of body element explains why the input focus after an in-page link often goes to the first link on the page.

A Google search for "hasLayout property" will yield a Microsoft MSDN page at the top of the list that describes this property and methods for setting it to true; setting width and height is one such method. That same Google search will turn up a number or articles about in-page links and the Internet Explorer 6 bug.

With that said, here is the work-around that I use to ensure that my in-page links work from the keyboard with Internet Explorer 6. This is the coding for a typical target:

<span style="position:absolute;">
  <a name="content" id="content">&nbsp;</a>

The anchor element (a) is not empty, but contains a nonbreaking space, which is invisible because it is given position:absolute. Without that content of the anchor tag, it turns out that visual focus doesn't work correctly. I hope that the next version of Internet Explorer will have this fixed, but Internet Explorer 6 will be around for a while, and this work-around is not too offensive.

Skipping Text Blocks with Assistive Technologies

Unfortunately, many important websites do not provide any of the simple accommodations discussed in the previous sections to permit people who cannot or do not use the mouse to quickly get to the main content of the page and around the major sections of the page. As is typically the case, the assistive technology developers recognize this problem and make valiant efforts to solve it for users of screen readers and talking browsers.

Navigation with screen readers has become quite sophisticated with keys to move through (forwards and backwards) headings, tables, links, lists, form elements, frames, and "chunks."

In this section, we'll look at the commands to jump over blocks of links in Window-Eyes 5.0, IBM Home Page Reader 3.04 (two updates since 3.00), and JAWS for Windows 6.2.

Skipping Links with Windows-Eyes

Window-Eyes was the first screen reader to build in significant mechanisms for skipping over blocks of links, and now has about 20 different commands that have that effect. You can jump to more specific points in the document, such as to the next form control (C), the next link (L), next list (S), or next table (T).

You can also jump to the next block of normal inactive text (X). This next text jump can be configured as to how much text will be considered a block of normal text, so that a word or two, or a heading can be ignored. Settings for the number of characters and number of lines for the X jump are in the Window-Eyes Verbosity Settings (Ins+V). Choose MSAA > Miscellaneous > Next Text Minimum Line Length and Next Text Consecutive Lines. Both of these values default to 1, meaning that, in the default environment, any single nonactive word will be considered to be a block. The reason this jump might be important is the possibility of letting the screen reader jump over those "repetitive navigation links" all on its own, with no help from the web page designer.

With the default settings, from the top of the CNN homepage (Figure 7-9), you need to use about six next text jumps (X) to arrive at the main content targeted by CNN's skip link. If you change the Next Text Minimum Line Length to 25 text characters and the Next Text Consecutive Lines to 2 text lines, three next text jumps work (in a 2001 version of, it took only one next text jump, but now there seems to be an iframe on that is complicating the process). But the main story begins with a heading (h2), and it is the only heading, so a simple H key press takes you to the main story.

The difference between a single H key press to move among headings (for Home Page Reader and JAWS as well) and activating the skip link (with Enter) is a difference between day and night. With the H key, Window-Eyes responds by announcing the level of the heading (2) and the heading text. When you press Enter on the skip link, Window-Eyes announces that it is reloading the page and presents the table of statistics for the page (links, frames, Flash objects, and so on), and finally, the text at the target of the link if the jump worked (and sometimes it doesn't work). I don't know why Window-Eyes reloads the page when an in-page link is activated, but it does. And the fact that it does is reason enough that a skip link is a poor accommodation compared with proper headings markup. With the H key, you hear the headline in 2 seconds; it takes about 25 seconds to get through the page reloading message and get to the news.

Skipping Links with Home Page Reader

IBM Home Page Reader includes a command (Ctrl+down arrow) to jump to the next block of text or links, similar to Window-Eyes. So if you are positioned on link text, then this jump takes you to the next nonlink text. If you are positioned on nonlink text, this jump takes you to the next link.

The idea of the next block jump (Ctrl+down arrow) is to skip over the groups of links. But the problem is that very often, there are short stretches of nonlink text scattered among the links, so it still may take a long time to reach the main content. To add to this problem, Home Page Reader inserts metatext, such as "Internal frame 2: Untitled," in its text view, which is then counted as nonlink text. Similarly, "Start of form 1" and "End of form 1" are both stops for this jump command. Home Page Reader uses six jumps to get to the headline on the homepage of (Figure 7-9).

Skipping Links with JAWS

JAWS provides single-character commands for skipping to most object types, including controls (C), buttons (B), edit fields (E), frames (M), headings (H), same element (D), different element (D), and many more. For headings, you can even jump by level using keys 1 through 6.

JAWS Version 6 introduced the new concept of place markers. You can insert a place marker at any position of and page (Ctrl+Shift+K), then return to it with K (Shift+K goes to the previous marker). I experimented by adding place markers at the beginning of the main content of (Figure 7-9) and at MORE NEWS. A week later, much to my surprise, the main content place markers still worked, but the MORE NEWS place marker was off by a line. I am not sure how this is implemented. But it is a cool idea enhanced by the possibility of community-based place-marking, since place markers can be shared among JAWS users.

Accessible Frames

Although few websites use frames these days, when coded correctly, websites with frames can (in principle) achieve access improvements.

The U.S. Access Board advises that frames be identifiable with titles in this Section 508 provision:

§1194.22(i) Frames shall be titled with text that facilitates frame identification and navigation.

The wording of WCAG 1.0, Checkpoint 12.1 on frames is nearly the same:

12.1 Title each frame to facilitate frame identification and navigation.

So where are these "titles" that the guidelines require? The problem with all of these guidelines is that the word title in them is ambiguous.

Guideline 4.1 of the Last Call draft of WCAG 2.0 is the key to accessible frames:

Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies).

The corresponding Level 1 success criterion is the following:

4.1.2 For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. [Level 1]

Success Criterion 4.1.2 requires that it is possible to determine the role of a frame, and the simplest way to do that is by providing meaningful title attributes on those frames.

Let's see how frames work, to help make the issues raised by the guidelines clearer.

How Frames Work

A frame page is actually a collection of pages displayed in separate windows (or frames) within the main window. The main page of a frame site is called the frameset page, and it specifies the layout of the various pages (frames). What is appealing about this design is that the different functions of various parts of the page are separated into different files, which can contribute to helpful navigation for all users.

Figure 7-15 shows an example of a frame site that duplicates the structure of the table shown earlier in Figure 7-2. This frame page consists of five frames; a title frame, two navigation frames, a banner, and the main content, corresponding to the cells of the table in Figure 7-2.

Figure 7-15

Figure 7-15. An example of a frame layout.

Here is the code for the frame structure in Figure 7-15:

<frameset rows="40,*">
  <frame src="Title.htm" ... id="toptitle"
    name="TopTitle" title="Top Title">
  <frameset cols="150,*,150">
    <frame src="Left.htm" ... id="leftnavigation"
      name="LeftNavigation" title="Left Navigation">
    <frameset rows="40,*" border="2">
      <frame src="Banner.htm" ... id="bannerad"
        name="BannerAd" title="Banner Ad">
      <frame src="Content1.htm" ... id="maincontent"
        name="MainContent" title="Main Content">
    <frame src="Right.htm" ... id="rightnavigation" 
      name="RightNavigation" title="Right Navigation">

Notice that each <frame> is provided with a title attribute together with both an id and a name attribute. The name and id attributes are how code in the HTML page refers to a frame (the id attribute replaces the name attribute for XHTML, so for a while both should be used). Often, the name attribute is totally obscure, like name="frame0978", and that is okay, because only programmers are supposed to see this. Links should specify a target frame in which the new page will open. When a link in the navigation frame opens up a page in the main content window, the navigation link should specify MainContent as its target attribute:

 <a href="Content2.htm" target="MainContent">Navigation link 2</a>  

The beauty of this for all audiences is that, when this link is activated, only the new main content page is opened or refreshed; the other frames, perhaps with a table of contents or large banner images, all stay as they were. If you want to read the main content of this sample frame site, just open the main content frame. If you want to check out the navigation links, read the navigation frame. And when you decide to follow a navigation link, since the target frame is specified, assistive technology can automatically read the main content page where the page you requested will be displayed. This scenario is why frame navigation can and should be easy if it is designed correctly.

Remember that the name and id attributes must be only one word beginning with a letter (A–Z; a–z) and may be followed by any number of letters, digits (0–9), hyphens (-), underscores (_), colons (:), and periods (.).

The title attribute, on the other hand, is the textual description referred to in the guidelines cited at the beginning of this section. The title attribute is for human consumption. When assistive technologies list frames, they generally list the title attributes of the frames when available; otherwise, they revert to the name attributes.

How Assistive Technologies Support Frames

When the Lynx text browser opens a frame site, it presents the user with a list of links to the various frame pages. Although assistive technologies use title attributes, Lynx identifies the frames by the name attribute if one exists; otherwise, each frame is identified with a number.

Figure 7-16 shows the list of frames as Lynx sees the example in Figure 7-15. The current link is MainContent. If the Lynx user follows that link (using the right arrow key), the main content page is opened, as shown in Figure 7-17.

Figure 7-16

Figure 7-16. The Lynx view of the sample frame page.

Figure 7-17

Figure 7-17. The single main frame page displayed by Lynx.

With a meaningful name attribute on every frame, the Lynx user can easily identify which frame to open. This Lynx view of the frame world captures the idea of frame browsing as a list of named HTML pages and their contents.

The situation is similar in the case of JAWS for Windows. However, when JAWS opens a frame page, it begins reading frame content one frame at a time in the order seen in the Lynx view shown in Figure 7-16, and which is explicit in the <frameset> page. As a new frame is encountered, JAWS announces "Frame," along with the value of the title attribute (or the name attribute if the title attribute is not available) of the frame. The JAWS user can also request a list of frames using the Ins+F9 command, and the list looks like Figure 7-18.

Figure 7-18

Figure 7-18. The JAWS list of frames.

Window-Eyes and Home Page Reader do the same thing. If no title attribute is available, these technologies will revert to the name attribute of the frame. With no title or name attribute, Home Page Reader will try to use the <title> element on the actual frame page instead. But very often, frame pages do not have <title> elements because the developers of those pages don't see those titles in the title bar; they see only the title of the <frameset> page.

When Home Page Reader encounters the sample frame site in Figure 7-15, it opens the first frame, announces the <title> element of the <frameset> page ("Frame Set Example"), the number of the frame to be read, "Frame 1 of 5," the <title> attribute of the <frame> page ("Title"), and then finally reads the frame page itself.

Frames and Focus

Figure 7-19 shows a test frame site hosted on the Freedom Scientific website. The site actually has three frames; the top frame containing an image has been cropped from the view to save space. The two frames shown in the figure are a table of contents frame on the left and a content frame on the right. So, when you want to read one of the sections, say The HTML Frames Challenge, you find that link in the table of contents frame and activate it. Then the section will open on the right in the content frame, ready to be studied and navigated. Well, for some it is ready—if you can see and don't rely on the keyboard for navigation, it is ready.

Figure 7-19

Figure 7-19. Sample frame page showing table of contents. Input focus stays on the link after opening the new frame.

Before capturing the screen in Figure 7-19, I had just used the Tab key to navigate down the table of contents page and pressed Enter on The HTML Frames Challenge. This opened the material in the content frame on the right. But notice in the figure that Internet Explorer has left focus on the link just activated. The focus rectangle is just barely visible. So, the next tab will not move around the content page as it should; it will still be locked in the table of contents frame. The same thing happens in the Firefox 1.04, Netscape 7.2, and Opera 8.02 browsers.

Basically, this browser focus problem negates the value of frames that I talked about earlier for people who rely on the keyboard. Two of the assistive technologies compensate for this and correctly take care of focus. Both JAWS and Home Page Reader start reading "The HTML Frame Challenge" (and put input focus there, too) after the table of contents link is activated. Unfortunately, Window-Eyes and Hal both continue reading in the table of contents where Internet Explorer has left the input focus.

Summary for Frames

There are fundamental usability problems with frames because they break the unified model of the Web—pages are not represented by unique URLs. Bookmarking, printing, and sharing of URLs don't work as they should. However, in some cases, a web application requires frames. When you must use frames, adding title attributes to the frameset components is a very small task compared to the development of a framed site. Therefore, you should have no difficulty following these guidelines:

Accessible Image Maps

There are two kinds of image maps: client-side and server-side. Client-side image maps are by far the most common type of image map to be found on the Web today. In fact, server-side image maps should be avoided.

Client-Side Image Maps

I talked about client-side image maps in the previous chapter, where I emphasized the requirement of text equivalents for all image map hotspots. These text equivalents are absolutely essential for accessibility.

The image map is called client-side because the browser (the client) must figure out how to handle the result of a click on the image. Any time there is a click on the page, the client (browser) figures out whether or not the coordinates of that click fell inside one of the regions specified as an <area> of the client-side map. If the click is inside one of those regions, then the browser opens the corresponding URL—that is, the value of the href for that <area>.

Figure 7-20 shows a client-side image map from an earlier version of the U.S. Senate website. The alt-text on the image that creates the map is alt="Quick List".

Figure 7-20

Figure 7-20. Navigation panel as client-side image map.

Here is the code that designates the image in Figure 7-20 as a client-side image map:

<img src="sidebar.gif" alt="Quick List" ... usemap="#subnav">  

Client-side maps need to have a usemap attribute, not an ismap attribute. In this case, the usemap attribute points to a map called subnav, which defines the areas of the image map that are hotspots. In the example, there are four areas:

<map name="subnav">
  <area shape="rect" coords="4,33,76,72" href="..."
    alt="Committee Hearing Schedule">
  <area shape="rect" coords="5,78,88,117" href="..."
    alt="Yesterday's Senate Floor Activity">
  <area shape="rect" coords="5,121,75,140" href=" ... "
    alt="Senate Art">
  <area shape="rect" coords="5,143,59,172" href=" ... "
    alt="Senate History">

The four image map areas have alt-text that is exactly the same as the text in the image; this is perfect. The way that this client-side image map works is that each <area> specifies a region of the image in which a click will open a certain URL, namely the href of the <area>.

The shape and coord (coordinates) attributes define the region of each <area>. There are three possible shapes: rect for rectangle, circle, and poly for polygon. The coordinates are pixel coordinates measured from the top left of the image. For a rectangle, the developer must specify the top-left and bottom-right corners. A circle is given by the center point and radius. A polygon is specified by a series of points corresponding to the corners of the polygon.

Server-Side Image Maps

Figure 7-21 shows another image map, from It is fundamentally different from the previous example in Figure 7-20.

Figure 7-21

Figure 7-21. Server-side image map for King County navigation bar.

Figure 7-21 is a server-side image map, with the following elided code.

<a href= "">
  <img src="... navbar.gif" border="0" ismap="ismap"
    alt="King County Navigation Bar (text navigation at bottom)">

Since this is a server-side map, there is no usemap attribute. Instead, the image itself is enclosed in an anchor tag (<a>) and the img element has the Boolean ismap attribute. That attribute tells the browser to send the coordinates of the user mouse click directly to an associated map file on the server that is referenced by the href attribute of the anchor element. For any person who cannot use the mouse, this is a fundamentally inaccessible form of navigation because it requires positioning the mouse on some part of a picture indicating a desired action (pressing Enter on a server-side image map sends click coordinates 0,0 to the server).

The U.S. Access Board recognized the problem with server-side maps and recommends having redundant text links if you do use a server-side map, in this Section 508 provision:

§1194.22(e) Redundant text links shall be provided for each active region of a server-side image map.

WCAG 1.0 has the same requirement at Priority 1:

 1.2 Provide redundant text links for each active region of a server-side image map.

Indeed, the King County site in Figure 7-21 has redundant text links at the bottom of the homepage, and the alt-text for the server-side map tells the user to find text navigation at bottom.

I can't see any reason why the King County site would use a server-side map for its main navigation. The equivalent text links at the bottom of the page make it accessible and compliant. The King County site, however, does not satisfy the second provision of the Section 508 rule on web accessibility:

§1194.22(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

The Section 508 provision is again almost identical to Checkpoint 9.1 of the WCAG:

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

In the Last Call draft of WCAG 2.0, three success criteria relate to server-side maps under Guidelines 2.1, 2.4, and 4.2, respectively:

Guideline 2.1 Make all functionality operable via a keyboard interface.

SC 2.1.1 All functionality of the content is operable in a non time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. (Level 1)

Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it.

SC 2.4.4 Each link is programmatically associated with text from which its purpose can be determined. (Level 2)

Guideline 4.2 Ensure that content is accessible or provide an accessible alternative

SC 4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI. (Level 1)

There is nothing about the regions in the King County image map that would make them difficult to define with available geometric shapes; simple rectangles would work well. In fact, the main navigation map on the homepage has now been changed to a client-side image map, as shown in shown in Figure 7-22.

Figure 7-22

Figure 7-22. King County navigation as client-side image map.

Complex Client-Side Image Maps

As mentioned earlier, client-side maps provide three shapes to describe regions: rectangles (shape="rect"), circles (shape="circle"), and polygons (shape="poly"). Effectively, any shape can be described with a polygon or collection of polygons.

Figure 7-23 shows a good example of a client-side image map with rather complex hotspots, which are regions defined by polygons. It is Microsoft's Local District Information map.

Figure 7-23

Figure 7-23. A complex client-side map - a stylised map of the USA, divided into states.

Using the Tab key, I moved the focus indicator in Internet Explorer to the upper Midwest area in the map in Figure 7-23 so that the focus polygon is visible. The source code for that area in the map uses a polygon determined by about 45 points:

<area shape=poly
 254,53,256,57,257,61,258,66,262,68,263,73,264,75,263,77,     262,78,260,78,259,80,258,82,257,84,256,86,254,87,243,87,243,88,    
 229,88,229,92,207,92,206,90,186,90,184,85,173,82,170,45, 172,30,172,7,174,8"
 href="..." alt="Twin Cities: ND, MN, SD, NE, IA">

In principle, any region of a finite image can be defined by one of the available geometric patterns of a client-side map. In the worst case, individual areas could consist of individual pixels. But, as the map in Figure 7-23 illustrates, complex regions also can be defined using polygons. It is therefore my conclusion that there is no case where a server-side map is permitted under the Section 508 provision §1194.22(f) or WCAG Checkpoint 9.1.

Even though it is hard to imagine, there may be cases where a designer wants every pixel to be a hotspot with different actions. You might argue that there are too many regions in this case. But that is a different issue than the one raised by provision §1194.22(f) and Checkpoint 9.1. A client-side image map still could be used.

Summary for Image Maps

The following points apply to accessible image maps:

Layout and Navigation

Most of us will navigate within a page intuitively. If you can see the page, you can visually move to the main content of the page and read the story, or indeed look across the top global navigation buttons to find the Search form or Contact Us link that you need. You look down the right column to find the other top stories or shopping specials. The process of finding those items is as much navigation as the process of moving from page to page. While reading the main content, a sighted user may have to page down or use the mouse to move down with the vertical scroll bar. Clearly, layout is affecting the process of navigating the content of the page. This process is much more complicated and difficult if you cannot use the mouse or you are partially sighted or blind.

As you've seen, using HTML headings for the sections of your page can make a huge difference in user navigation. A skip navigation link can facilitate movement to the main story. The hidden table of contents at the top of the site (as in the FirstGov site, shown earlier in Figure 7-11) is another approach.

You have also seen how layout tables can make it very time-consuming to find the main content in a page, as in the example shown earlier in Figure 7-2. However, some simple tricks with layout tables actually make it easier to find the main content with a screen reader or talking browser.

It is not clear why at least one column of navigation links is routinely placed on the left side of web pages. On my site in 2004, I used to use a tabular structure like that shown in Figure 7-24, which places the navigation column on the right and the main content on the left.

Figure 7-24

Figure 7-24. Simple table layout with navigation on the right.

With this layout, the main content follows the "title" in a text or linearized view of the page. There is no need to provide a skip navigation link in order to comply with the Section 508 provision §1194.22(o). However, in this situation, I did add a skip to navigation link attached to an invisible GIF at the top of the page. This certainly is not required for compliance with the Section 508 Standards or WCAG 1.0.

When all the layout of a page is controlled with CSS positioning, the web developer is in control of the reading order of the sections (divs) of the page, because the source code order does not determine the visual presentation order. When you are using CSS, make sure that your reading order makes sense and mark up the sections of the page with HTML headings.

Accessible Links

The link text you use can have a major impact on your web page accessibility. But before we look at link text, let's review how link navigation works.

Link Navigation

Some users of the Web are so mouse-dependent that they may not be aware of the fact that you can tab through all the active elements of a web page. As you do that, usually a dotted enclosing polygon, called a focus rectangle, moves along with the focus, highlighting the current link text inside. This was illustrated in the image map from Microsoft (Figure 7-23) and the frame page from Freedom Scientific (Figure 7-19). Figure 7-25 shows another example, which is a piece of the right navigation panel of my current site as seen in Firefox 1.04.

Figure 7-25

Figure 7-25. Link with focus.

The link text that currently has focus is marked with a dotted rectangle, but the foreground and background colors are also changed by the CSS style on the site. The text enclosed inside this focus rectangle is called the link text, which is the content of the anchor element (a):

<a href="webcourse1.htm">
  Web Accessibility for Section 508 – Tutorial

As you navigate around the links of a page with the Tab key (and Shift+Tab to go backwards; A and Q in Opera), you can use the Enter key at any time to activate a link. This action corresponds to clicking the link.

When you are listening to a page, the link text will be identified in one of a number of ways, but generally screen readers precede the text of a link by saying "link" or "visited link." Home Page Reader has several options for indicating links. With the default settings, Home Page Reader changes to a higher-pitched, so-called "female" voice on a link. Alternatively, you can set Home Page Reader to produce a sound alerting the user as the link is spoken, or you can set it to speak some metatext, (such as "link"), before, or even after, the link.

Link Text

The actual link text is important. What does it say? Is the link text clearly explaining what the link is pointing to? WCAG Checkpoint 13.1 captures an important requirement:

13.1 Clearly identify the target of each link. [Priority 2]

Under Guideline 2.4, the Last Call draft of WCAG 2.0 has one Level 2 success criterion and one Level 3 success criterion that relate to link text:

2.4.4 Each link is programmatically associated with text from which its purpose can be determined. (Level 2)

2.4.8 The purpose of each link can be programmatically determined from the link. (Level 3)

You must be able to understand where a link will take you, even if you read the link text out of the context of the page. As you tab from link to link, the focus rectangle highlights the link text. Whether you are using magnification, focusing on the focus rectangle, or listening to the page, it is the link text that is important. At Level 3, WCAG 2.0 requires only that the purpose of the link can be programmatically determined from the link. The requirement at Level 2 is that purpose of the link be available to assistive technology in some way. I think the wording of this success criterion must change; "programmatically associated" is not defined.

The page excerpt shown in Figure 7-26 has a service to sell, but the targets of the links are not clearly identified.

Figure 7-26

Figure 7-26. Examples of poorly chosen link text

With link text such as Learn more and Try it free, a disabled user is left asking, "Learn more about what?" and "Try what free?" The link text needs to be much more meaningful, such as Learn more about our content management system and Try our testing tool for free.

The worst offender is Click here. All of the assistive technologies discussed in this chapter can help users by generating a list of links. With JAWS, Ins+F7 brings up the list. With Home Page Reader, Ctrl+L generates a list. The Window-Eyes command is Ins+Tab. Figure 7-27 shows the Window-Eyes link list for a site that just does not understand the importance of identifying the target of links.

Figure 7-27

Figure 7-27. Window-Eyes link list for a site where all links are "click here".

There are other, less crucial but still important, aspects of accessible link text. As I just mentioned, links are read as "links" by screen readers and talking browsers, so there is no need to include link to in the link text, as is commonly done in alt-text for image links. Don't include verbs like open our contact form here; instead, just say contact us. The latter would be typical of visual text, while the longer version might appear as alt-text on a contact us image. You already saw an example of annoying link text in the skip link (described in the "Creating a Link As Alt-Text on an Invisible Image" section), with Click here to skip to main content. It should be just main content. Unfortunately, there is historical precedent for using skip to main content and skip navigation, but both are poor choices because of the presence of the verb and, in the second case, because the destination cannot even be determined.

Every image that is a link must have nonempty and meaningful alt-text because when you tab to a link, there must be something there. When the link text is the alt-text of an image, it should convey the target of the link. Remember from the previous chapter that an image inside an anchor tag may have null alt-text if text describing the nature of the link is also included within the same anchor.

Finally, there are times when fully spelling out the target of a link really becomes overbearing and annoying for both the visual and auditory experience of a page. Figure 7-28 shows a section of a page on

Figure 7-28

Figure 7-28. Screen shot showing generic link text augmented with the title attribute as pop-up in Internet Explorer 6.

Each of the generic links, including More, Choose, Features, Rooms, and Photos, is relevant to the specific hotel property. Those generic links are repeated for each hotel. Some interpret WCAG Checkpoint 13.1 to require that each generic link must include the specific hotel, such as Features of the Crowne Plaza Universal Orlando. That is the wrong thing to do for all users because the visual design would become highly cluttered, as would the audible presentation. The examples in Figure 7-28 do comply with Success Criterion 2.4.4 because there is text available with which to understand the purpose of the link. In cases like these, you should add a title attribute to the anchor element that specifies the details and thus comply with WCAG Checkpoint 13.1 and WCAG 2.0 Success Criterion 2.4.8. That is what does, as suggested by the tooltip in Figure 7-28.

I am often asked, "What good does that title attribute do?" Can screen readers access that information? The answer is, "not very easily." For example, JAWS has three options for speaking a link: the link text, the title text, or the longer of the two. The default, thank goodness, is link text. I hope one day that screen readers will add an option to speak additional information about this object, which could announce the title attributes on links and other elements, long descriptions of images, and additional information about form controls (see Chapter 8), as just three examples.


In this chapter, we looked at several ways of providing navigation that is accessible to users who depend on screen readers or cannot use the mouse. The most important thing you can do to provide accessible navigation of your page is to mark up the sections of your page with HTML headings, including one at the beginning of the "main content." You also saw how a link to the main content at the top of the page can be a useful facility for users who are visually impaired. You then looked at how frames can be fairly accessible if meaningful title attributes are placed on the frame elements and title elements are included on the frame pages themselves.

Next, you saw how client-side image maps can provide an accessible form of site navigation, as long as you provide alt-text on each area of the map that clearly describes the target of the corresponding hotspot. Server-side image maps are fundamentally inaccessible, so redundant text links for all hotspots of the map should be provided whenever server-side maps are used. It is best not to use server-side maps at all.

Good page layout is another important factor that can increase a website's accessibility, especially for pages with CSS layout.

Finally, you looked at accessible links. All link text, whether it is visible on your page or the alt-text on image links, must clearly tell the user the purpose of the link. Phrases like Click Here or Learn More are of little use to someone using an assistive technology. Not only that, but there is no need to preface link text with link to; instead, simply specify the target.