Click Here and Other Link Text (Posted June 16, 2007)

This is an essay about the accessibility of link text and how that is handled in the web accessibility guidelines. Since those guidelines are changing, it is a good time to look at this issue.

Everybody knows that you should not use " click here" for link text - or do they? Mainly this issue this comes up when screen reader users navigate through a page with the tab key, moving from link to link. When you do that and hear "link click here" it is annoying at best and you have no idea where the link takes you. In the same way, a blind user can request a links list, and the appearance of "click here" in that list is not useful.

In 1999 the W3C published the Web Content Accessibility Guidelines (WCAG 1.0) as a formal recommendation. Guideline 13 (Provide clear navigation mechanisms) includes a Priority 2 checkpoint addressing the important issue of the quality of link text.

13.1 Clearly identify the target of each link. (Priority 2)

What does that mean? The explanatory text in the guideline document suggests that that to comply with 13.1, the link should be meaningful when read out of context (like in the links list). So that means  click here would not comply but "for  information about version 4.3, click here" would certainly comply. What about adding a title attribute to the anchor element to explain the purpose of the link? For example, the link could be  click here with title="information about 4.3" (Ugh!). The use of title is mentioned in a kind of a postscript in the WCAG document: "In addition to clear link text, content developers may further clarify the target of a link with an informative link title" (emphasis mine). It seems to me that "clear link text" is not the same as link text which identifies the target of the link and I believe that "click here" is not clear link text so that adding the title attribute doesn't help.

What is wrong with "click here" as link textother than the fact that it doesn't make sense out of context?. Well it is mouse-centric and that is problematic. But keyboard users are very familiar with the idea that "click" means activate and if they are not used to it, then they soon will be because it is everywhere. "To click" has, in my opinion, become synonymous with "to activate." But "to activate here" doesn't make sense. It is amusing that we don't have words that express the idea of activating this here link either with the mouse or the enter key on the keyboard - "click here" is simple.

Independent of the specific phrase, the problem of inadequate link text is pervasive in commercial web sites today. My favorite example is a typical list of hotels found in a hotel search on Priceline.com. A screenshot of two entries in such a list is shown below.

Priceline.com screen shot - Data for two hotels including links map, photos, details, guest reviews and book now.

Each block of hotel information (and there may be 20 or 30 such blocks) includes the name of the hotel, e.g., " Gold Coast Hotel and Casino," a very brief description of the hotel, the price and then five links, " Map", " Photos", " Description", " Guest Reviews" and finally " Book Now." Just imagine the real estate required and overload for everyone if Priceline.com complied with WCAG 13.1:

No one would be happy with that. By agreement with the New York State Attorney General's Office, Priceline.com was required to comply with WCAG 1.0 checkpoint 13.1 and to do so (on my recommendation) they added a title attribute to each of the short links as indicated with the text pop-up "Photos of Gold Coast Hotel and Casino" in the screenshot above. The title attribute on each anchor clearly identifies the target of the corresponding link.

Two observations about this solution:

  1. Except for the text pop-up available to mouse users, the title attribute does no one any good. The title attribute on the anchor element is of no use to users of the current batch of screen readers. I think it should be useful. Screen readers could/should respond to a command for "more information" and then provide the value of the title attribute, if available. It is not that the title should be read automatically but it should be available to the user on command.
  2. Even though the title is currently almost useless, I think a link with a title attribute does comply with 13.1. The target of the link is clearly identified by the link text together with the link's title attribute.

Before Version 1.0 of the Web Content Accessibility Guidelines were completed I worked with the team at the IBM Accessibility Center to create a set of accessibility guidelines for software, hardware and the web. These have evolved over the years and the accessibility guidelines are still available on the IBM Accessibility Center web site. When we first did these, each checkpoint was followed by three links,  Rationale,  Techniques, and  Testing. The purpose of these links, like in the hotel example above, is obvious from the context, but not obvious when read in a list of links. I think this kind of organization is particularly useful because different visitors will want to explore different aspects of an accessibility guideline. One person might care only about the Rationale - another only the testing information. Today the text of each checkpoint of the IBM guidelines is a link to a web page which in turn contains the rationale, techniques, and testing sections. At the top of that page there are three links (did you guess that),  Rationale,  Techniques, and  Testing. So apparently the IBM web accessibility team decided that those three links on the page for a specific checkpoint do clearly identify their targets. This is similar to links  News and  Contact on my home page (or anybody's home page). These are really News on JimThatcher.com and Contact Jim Thatcher, but the extra information is available from context, i.e., from knowing what page or site you are on.

The WCAG Working Group has been developing a revised and updated version of the Web Content Accessibility Guidelines. The draft WCAG 2.0 is now available for public comment. It contains two provisions (called success criteria instead of checkpoints) dealing with link text.

2.4.4 Link Purpose (Context): The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A)

2.4.8 Link Purpose (Link Text): The purpose of each link can be identified from the link text. (Level AAA)

Lets look first at the second success criterion, 2.4.8, which is the simple one. SC 2.4.8 is at level AAA which is analogous to Priority 3 and it says that the link text must tell the user where the link is going. It is a very strong requirement. There is a fundamental, yet very subtle difference between SC 2.4.8 and Checkpoint 13.1 in WCAG 1.0. The latter refers to the "link" while this success criterion specifically talks about "link text." So the title attribute of the link comes into play for 13.1 but not for 2.4.8.

One would expect that many commercial web sites will not be able to meet criteria at level AAA. As I have suggested by examples above almost everybody would not be happy if commercial sites did. The list of fully expanded links for the hotel display on Priceline.com would sound even worse than it looks. I am glad this provisions is at most at level AAA. But wait! WCAG 2.0 includes a sufficient technique for Criterion 2.4.8 to include the full link text as in the list of Gold Cost Hotel links above but to use CSS to hide the extra words. Here's sample code for one of the links in the list. Note that the span surrounds the extra words.

<style> a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; }</style>
 
<li><a href="#">Map <span>for Gold Coast Hotel and Casino</span></a></li>

And here is what the link looks like. (Corrected 6/24/2009 - Thanks Cliff Tyllick!)

Here is how it sounds:  Map for Gold Coast Hotel and Casino! The Working Group has, with this technique, decided that it is OK to not have the link text visible but have it spoken by screen readers and still pass 2.4.8. That's awful! As I said, the repetitive reference to the subjects of the links ("Gold Coast Hotel and Casino" in this case) is not only is unacceptable visually, it is also unacceptable audibly. Instead of styling the text off screen as done in the sample code, it could be styled with display:none. The visual effect would be the same but then most screen readers wouldn't see it either. Then only visitors with CSS disabled would know about the full link text Would that pass SC 2.4.8?

But what about 2.4.4 at level A (analogous to Priority 1). The million dollar question is - what is "programmatically determined link context"? Here's the definition from the WCAG 2.0 editors draft:

programmatically determined link context: additional information that can be programmatically determined from relationships with a link, combined with the link text, and presented to users in different modalities

Example 1: In HTML, information that is programmatically determinable from a link in English includes text that is in the same sentence, paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.

Example 2: A screen reader provides commands to read the current sentence when focus is on a link in that sentence.

The definition (and Example 2) clearly allow the following kind of a link, "To advertise on this page,  click here." That makes sense. In fact this is a compliant example in the WCAG20 techniques document. These pass success criterion 2.4.4 at level A (but not 2.4.8, level AAA) because the sentence gives the context. But what about our hotel example?

The sufficient techniques for Success Criterion 2.4.4 explicitly include the option of providing the purpose of the link in the title attribute:

The title attribute is used to provide additional information to help clarify or further describe the purpose of a link. If the supplementary information provided through the title attribute is something the user should know before following the link, such as a warning, then it should be provided in the link text rather than in the title attribute.

The sufficient technique explicitly includes the hotel example, coded with the title attribute, as meeting 2.4.4 - in a way that is useful to almost no one. But what about without the title? Each individual hotel block is in fact a separate table. I created the screenshot above awhile back and I don't know if the hotel name is included in the same table cell. I suspect it isn't. If it isn't and if the hotel name is not designated as a header cell (which would be silly) then these links fail 2.4.4.

An amusing situation is presented with the current formatting of this hotel list on Priceline.com. Here is a screenshot of a single hotel block marked up using the accessibility tool bar to show table cells.

Hotel listing on priceline.com - screen shot

The links  More,  Read (7) Guest Reviews,  Features,  Rooms,  Photos, and  Map are all in the same cell as the name of the hotel so they pass Success Criterion 2.4.4. The link at the bottom,  See all available room types, fails as does  Choose (white letters on a red background) because each of these is not in a table cell containing the expanded information. By the way, the image of the hotel is active and its alt-text is "Details for Embassy Suites Hotel Convention Center Paradise Rd-Las Vegas," the same text as the value of the title attribute on  More.

One last data point about these links. Here's a screenshot of the JAWS links list dialog for this Priceline.com page including the links in the screenshot above.

screen shot of Jaws links list on priceline.com

Each hotel block in the links list includes the name of the hotel and then a number of specific links for that hotel. It isn't as if you have a bunch of links in a row,  More,  More,  More. Instead it goes  Name of hotel,  More,  Another hotel,  More. I think that these should pass at level A, without the title attributes. However, there is one more observation. The important link,  Choose as well as  Priceline Special Rate precede the hotel name in the reading order (the dialog in the screenshot above doesn't have enough room to display those links). I think that those links (without the title attribute) should not pass at level A.

One more point about 2.4.4. We talked about the links  Rationale,  Techniques, and  Testing for the IBM Accessibility Guidelines; when they appear on the page that deals just with a specific checkpoint page should meet SC 2.4.4 because the the context of the page title tells what the link will do. The same link text, appearing repetitively in the list of checkpoints (which themselves aren't links)should not a meet the criterion at this level. The current working draft of the Web Content Accessibility Guidelines does not reflect that.

Summary of suggestions submitted to the WCAG Working group

  1. For 2.4.4, as the  About and  Contact links suggest, the title of the current page should be mentioned as an example of Programmatically Determined Context. It is probably the most common context; it is so common that we don't even think of it as context.
  2. For 2.4.4 and 2.4.8, the technique (C7) of putting in full link text and then hiding the redundant parts for visual users should be removed. Allowing the overload text to be removed for sighted users, but required reading for blind users is not acceptable.
  3. For 2.4.4, topic links of the form  TopicA  Link1  Link2  Link3  TopicB  Link1  Link2  Link3  TopicC etc., provide context for the repeated links that follow (Link1 Link2 Link3) each topic. I don't know how to define this context, but it is common and easy to use for screen readers because all the detailed links on TopicX follow TopicX in the usual reading order - until a new TopicY link is encountered.This is analogous to the fact that the visual display (see the hotel example) of links like this makes the context obvious for sighted users.
 

Archived News Items

Skip Sidebar.

Articles

Popular Pages

: