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 screen shot of two entries in such a list is shown below.
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 screen
shot above. The title attribute on each anchor clearly identifies the target of the corresponding link.
Two observations about this solution:
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. 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.
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
titleattribute is used to provide additional information to help clarify or further describe the purpose of a link. If the supplementary information provided through thetitleattribute 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 thetitleattribute.
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 screen shot 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 screen shot of a single hotel block marked up using the accessibility tool bar to show table cells.
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 screen shot of the JAWS links list dialog for this Priceline.com page including the links in the screen shot above.
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 screen shot 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.