Re: SC 2.4.5: links in context

Hi John,

Thanks for your proposal. I prefer the proposed wording.

John said,
<blockquote>
In my opinion, the fact that additional keypresses are needed counts as a serious accessibility barrier, especially since the situation occurs so often.
</blockquote>

I agree with you. I've seen many screen reader users who have trouble
with the ambiguous links and finally give up at the user testings I
conducted. I can't ignore this situation and WCAG should address this
issue. JIS addressed this as it is a serious accessibility barrier.

In Japan, JAWS is not popular and the users are limited as it is very
expensive. Japanese popular screen readers such as PC-Talker and 95
Reader can't create the link list. The users are tabbing through the
links within a page. I think the proposed wording would help such users
to decide whether they want to navigate there.


Cheers,
Makoto


On Fri, 24 Feb 2006 16:37:50 -0600
"John M Slatin" <john_slatin@austin.utexas.edu> wrote:

> 
> This proposal is meant to address some of the concerns that Ben raised
> in his response to my original post on this thread, and I think itmight
> catch some of Makoto's concerns as well.
> 
> <proposed>
> 2.4.5 When a link or other programmatic reference to a delivery unit (or
> part of the same delivery unit) has focus, text describing the
> destination is available without changing the focus.
> </proposed>
> 
> The current wording is as follows:
> <current>
> 2.4.5 Each programmatic reference to another delivery unit or to another
> location in the same delivery unit, is associated with text describing
> the destination.
> </current>
> 
> Rationale
> In some of the examples listed in the technique "Describing the delivery
> unit in text immediately preceding the programmatic reference" [1] and
> in my post on "SC 2.4.5: links in context" [2], users encounter
> difficulty because they must move focus away from the link in order to
> find out where the link goes. Additional key presses are needed first to
> find the context and then to return to the link and follow it. In my
> opinion, the fact that additional keypresses are needed counts as a
> serious accessibility barrier, especially since the situation occurs so
> often.
> 
> I am not convinced that the current wording of the SC describes a
> "functional outcome." I think the proposed wording addresses that
> problem (it may create other problems, of course, and I'm sure someone
> will point them out...)
> 
> The proposed wording *could* be satisfied by AT, for example if the AT
> grabbed the title from the link destination and reported it to the user,
> or if it went and got the nearest heading before the  link, etc. In
> those cases the author wouldn't need to do anything beyond what's
> required by other SC (use heading markup to markup headings, provide
> titles for delivery units, etc.). 
> 
> Ben mentioned that the phrase "description of the destination" might not
> be quite right. I think he may be on to something, but I don't have a
> proposal for that part yet.
> 
> Thanks!
> John
> 
> 
> 
> [1]
> http://trace.wisc.edu/wcag_wiki/index.php?title=Describing_the_delivery_
> unit_in_text_immediately_preceding_the_programmatic_reference
> [2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JanMar/0396.html
> 
> 
> 
> "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 Saturday, 25 February 2006 08:19:01 UTC