- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Sun, 26 Feb 2006 14:54:34 -0600
- To: "'David MacDonald'" <befree@magma.ca>
- Cc: <w3c-wai-gl@w3.org>, "'John M Slatin'" <john_slatin@austin.utexas.edu>
Interesting Couple of questions 1) On a link list -- would anything more that "FULL STORY" show up? If not how does this help? 2) would turning off style sheet cause the person hear/see the title three times? <p>Winnie the Pooh <a href="winnie_the_pooh.pdf">HTML<span class="hide">Whinnie the Pooh </span></a> <a href="winnie_the_pooh.pdf"> PDF<span class="hide">Winnie the Pooh </span></a><br /> War and Peace <a href="war_and_peace.pdf">HTML<span class="hide">War and Peace</span></a> <a href="war_and_peace.pdf"> PDF<span class="hide">War and Peace</span></a></p> Would become * Winnie the Pooh link HTML Winnie the Pooh link PDF Winnie the Pooh * War and Peace link HTML War and Peace link PDF War and Peace I tried it with the top picks on Amazon.com. * The Grizzly Maze: Timothy Treadwell's Fatal Obsession with Alaskan Bears link HRML The Grizzly Maze: Timothy Treadwell's Fatal Obsession with Alaskan Bears link PDF The Grizzly Maze: Timothy Treadwell's Fatal Obsession with Alaskan Bears * Consider the Lobster : And Other Essays link HTML Consider the Lobster : And Other Essays Consider the Lobster : And Other Essays link PDF Consider the Lobster : And Other Essays * The Bob Dylan Scrapbook, 1956-1966 link HTML The Bob Dylan Scrapbook, 1956-1966 link PDF The Bob Dylan Scrapbook, 1956-1966 Is this also what a link list will look like? Thanks 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: David MacDonald [mailto:befree@magma.ca] Sent: Sunday, February 26, 2006 10:15 PM To: 'Gregg Vanderheiden' Cc: w3c-wai-gl@w3.org; 'John M Slatin' Subject: RE: SC 2.4.5: links in context An example of meaningful link text in HTML that is hidden and does not change the default presentation is here. Loretta and Team B are currently drafting it in the wiki to present to the group. http://www.eramp.com/david/testhide.html David MacDonald ...access empowers people ...barriers disable them... www.eramp.com -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Gregg Vanderheiden Sent: Sunday, February 26, 2006 12:39 AM To: 'Makoto UEKI - Infoaxia, Inc. -'; w3c-wai-gl@w3.org Subject: 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 20:54:46 UTC