RE: SC 2.4.5: links in context

Hi John
I think if you added "not change the focus beyond reading the current
sentence or list item"  it would make sense.  If they are focused on a
single word - or between two words I don't think your proposal works.  But
if you mean that "read current sentence" should be enough, or if it is a
list item, "read current list item",  then that seems to work.  And it
allows most common linking approaches to work.   I think.

Just tossing it out. Haven't given it a thorough think through. 

Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Makoto UEKI - Infoaxia, Inc. -
Sent: Saturday, February 25, 2006 2:19 AM
To: w3c-wai-gl@w3.org
Subject: 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_deliver
> y_ 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&utl
> ol
> =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 Sunday, 26 February 2006 05:39:24 UTC