RE: SC 2.4.5: links in context

Hi, Ben. Thanks for the detailed and thoughtful response.

Something you said early in your message makes me think I didn't make
myself clear on an important point. I'll address that one in this
message and see if it helps.

You wrote: 
<blockquote>
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?
</blockquote>

I'm sorry-- I didn't mean to imply that the link list should be treated
as some sort of test. My concern about many of the examples I cited is
that they don't make sense even when the user moves from the links list
to the link as it appears in context on the page (this is what the alt+m
keystroke does). In most of the examples I cited, discovering the
context for the link required several additional keystrokes, and that's
what I have trouble with.

As for your question,
<blockquote>
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?
</blockquote>

In the scenario I'm thinking of, the screen reader user *has* already
read the content that leads up to the link (e.g., "Read more...". But
there are multiple links on the page with the same link text ("Read
more...") that pint to different destinations. And it is typical for
screen reader users to listen to a lot of content on a glog or news site
before deciding which articles to read completely. (This is the
equivalent of visually scnaning the page before zeroing in  on a
specific item that interests you. But a sighted user can scan a lot of
content at once, while someone using a screen reader has to listen to it
sequentially. So now the person with the screen reader has heard enough
of the page, and has decided to read the full story for an item earlier
on the page. How do you get back to that earlier item and make sure you
have the right link?

There are several ways to do this in JAWS:
1. Press Shift+tab to move backwards through links and form controls. In
this scenario, the screen reader will land on several links that say
only, "Read more dot dot dot." There is no keystroke that is designed to
provide the context for this link. I can press Shift+H to find the
previous heading, which does provide context on a well designed page (or
even on slashdot). But the Read more... Link doesn't have focus any
more, so I have to tab back  (one more keystroke) to get to it.
It 

2. I can press Shift+U (a new feature in JAWS 7.0 I think) to move
backwards through unvisited links on the page. The rest of the actions
described in (1) above are still necessary, though, so this doesn't
really change anything.

3. I can press Ins+F7 to bring up the links list. Then I can highlight a
Read more... Link early in the list and press alt+m. This closes the
links list dialog and gives focus to the Read more... Link. *If* there's
a heading above that Read more... Link, JAWS 7.0 will speak the heading.
(This is what happens on slashdot and on the Accessibility Institute
page I mentioned, and I have no problem with it. But earlier versions of
JAWS didn't read the heading-- alt+m just closed the links list dialog
and gave focus to the link, and additional keystrokes were needed to
check the context. As far as I know, Window Eyes and Home Page Reader do
not provide this behavior-- Home Page Reader doesn't have an equivalent
to the alt+m functionality in JAWS.

4. I can use the upArrow until I find contextual information.

5. Or I could press Ins+F6 to bring up the headings list and find the
heading I want. This is probably the best option, since pressing Enter
closes the headings list dialog and takes you to the heading on the
page. From there you'd press tab to get to the link. But that means the
heading has to be there, and while that's appropriate for most blogs and
news sites (and lots of others), it's not *always* appropriate and one
of the other procedures would kick in.


All of the procedures described above, except (3) and (5),  take focus
*away* from the link. So in addition to having to do additional
keystrokes to find the context, the user *also* has to do at least one
other keystroke to get back to the link she or he was already on. So the
best case for all of those procedures except (3) and (5)  is a minimum
of three additional keystrokes (shift+h to get a heading, then tab to
get back to the link). That may not sound like a lot. But they add up
over the course of a day or a week or a month, as David pointed out ina
previous discussion.

I'm beginning to think that the real problem happens when the user can't
find the context for the link without taking focus away from the link.

I'll make a proposal about that in a separate message.

Thanks. This is really helpful.

John
"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 


-----Original Message-----
From: Ben Caldwell [mailto:caldwell@trace.wisc.edu] 
Sent: Friday, February 24, 2006 3:47 pm
To: John M Slatin
Cc: w3c-wai-gl@w3.org
Subject: 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>

Received on Friday, 24 February 2006 22:30:27 UTC