Re: SC 2.4.5: links in context

Hi John,

Thanks for digging up these examples. Good food for thought.

One concern I have about these in general is with the assumption that 
users should always be able to determine the destination of a link from 
the links list dialog. While the links list is certainly a useful tool 
for finding a link that you already know is there (especially on 
frequently visited pages), I'm not convinced that all links should make 
sense when read out context. As an author, there are certain 
circumstances (news sites and blogs are prime examples) where the 
question I ask is, why would it be helpful to know what the destination 
of the link is if you haven't already read the content that led up to 
that link?

As you mentioned in your summary, I think there are some questions we 
need to answer around one word links.

Take the following example:

<p>I wasn't awake this morning until I'd had my first cup of <a 
href="http://starbucks.com">coffee</a>.</p>

 From an accessibility perspective, is ambiguity about the destination 
of the link "coffee" a barrier to accessibility? What if the link 
pointed to the Equal Exchange Fair Trade site 
(http://www.equalexchange.com/) or wikipedia's entry on coffee 
(http://en.wikipedia.org/wiki/Coffee) instead of to Starbucks?

AT implementation issues aside, it's great advice to make this link more 
usable by adding a title attribute. However, my feeling is that we're 
taking this success criterion a bit too far if what it means is that a 
page containing only the sentence above does not conform to the 
guidelines at Double-A.

John suggested that linking from a single word embedded in the text of a 
sentence would be a sufficient technique to meet this criterion since 
the context of the sentence usually describes the destination. I 
disagree. In the example above, the destination of the link isn't 
described, so this would fail this success criterion as currently written.

To extend this example further, what about a page which contains only 
the word "coffee" as a link? In this case, there isn't any text 
associated with it that describes the destination. However, this is not 
inaccessible, it's just ambiguous. If the user wants to know what the 
destination is, they can simply follow the link and find out.

Maybe the question is about the type of link we're talking about. Are 
there certain types of links or situations where it's more important 
that the destination be clearly described than others? I think part of 
what we're wrestling with here is that there are examples where we'd 
like to see clear link text at level 2 an other examples where it seems 
more like good advice.

Here's my take on the questions and examples from your summary:

John M Slatin wrote:
...
> The questions are:
> (1) Do the instances I describe actually pass SC 2.4.5 *as it is
> currently written*?
> (2) If you think they fail the SC *as currently written*, how would you
> explain why they fail?
> (3) If you think the instances *pass* the SC *as currently written*, do
> you think the SC itself is OK as written, or should "programmatically
> associated" descriptions be required? (That is, should we rewrite the SC
> so that the instances in the attached document would fail)?

<http://www.w3.org/Member/> - This is an odd construction and I had to 
click on the link myself before I could figure out where it would take 
me. I would have thought JAWS would provide a better clue about what 
this link does by announcing that that the "more" link here is a "this 
page link." I agree that determining the context for this link isn't at 
all straightforward in this case, but would suggest that it's no more 
confusing for AT users than it is for anyone else. In addition, if the 
navigation bar had included headings or nested lists by category, I 
think this would be a lot easier to figure out. So, as 2.4.5 is 
currently written, I think this example would fail because the 
destination of the link can not be inferred from context.

<http://slashdot.org/> - This is a great example of the type of site 
where it makes very little sense to use the links list as a tool for 
navigating the site. Once you're familiar with the way content on 
slashdot is organized, a user might use the links list to quickly find 
sections of interest (ex. games, media, etc.) but navigating by header 
or reading the main content of the page in its entirety is a much better 
strategy. I think this example should pass 2.4.5 as currently written 
since the destination of the link is clear when the link is read in context.

<http://utdirect.utexas.edu/lib/utnetcat/index2.WBX?search_type=MK&utlol=yes&search_text=slatin%2C+john+m>
For the UT library catalog, I'd suggest that this fails 1.3.1 based on 
the fact that the links are in separate cells from the results in a 
layout table. This is another very odd construction and I think as 
currently structured, this one should fail 2.4.5. However, if this were 
in a data table, I think it would be the other way around (though the 
overall structure would still have a number of usability issues).

<http://blogs.usatoday.com/sportsscope/> - This is similar to the 
slashdot example. I agree that it fails 1.3.1, but the purpose of the 
page is to provide a series of sports headlines and article snippets. 
For those articles that are a bit on the long side, the "read more" 
provides an easy way for users to pick up where they left off on a 
separate page while minimizing the amount of screen real-estate a single 
article can take up on the home page. The destination of the "read more" 
links in this example is the middle of the article being read, so I'm 
not even sure what 2.4.5 would require in this case. Would it really be 
helpful to have a title attribute here that said something like, 
"paragraph 6 of Thursday wrap and Cohen reaction"? As currently worded, 
I think this example should pass 2.4.5.

<http://www.xe.com/ucc/> I think this passes the SC as it is currently 
written.

Thanks again for providing these specific examples John. It has been 
very helpful in thinking this through more carefully.

Not sure what to recommend at this point. If there's a way to categorize 
links that can't be understood because they don't have surrounding 
context (ex. links in navigation bars or menus), I could see addressing 
this at level 2 and moving the current criterion with programmatic to 
level 3, but as written, I'm concerned that this criterion is too 
restrictive for level 2.

-Ben

-- 
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>