- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Sun, 26 Feb 2006 18:05:41 -0600
- To: "Gregg Vanderheiden" <gv@trace.wisc.edu>, "David MacDonald" <befree@magma.ca>
- Cc: <w3c-wai-gl@w3.org>
Using JAWS to read David's examples (http://www.eramp.com/david/testhide.html) *does* result in the document title appearing twice (once for the HTML version and once for the PDF version). I do *not* have a problem with that! If I am only interested in PDF versions, I can bring up the links list and press "skip past the HTML versions. If my screen reader doesn't have a links list feature (like the Japanese screen readers Makoto mentions), I hear all the information I need as I tab through the links on the page. Gregg suggests adding "beyond the current sentence" or "beyond the current list item" to the wording I proposed for SC 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 [beyond the current xxx] </proposed. I'm not sure about Gregg's suggestion. I understand the rationale-- there's a tricky balance between constraints imposed on the author and demands made on the user. But "beyond the current list item" would put a very tight constraint on the author-- it seems to say links must appear in a list, and there may be technologies that don't support lists as a structure; certainly there are designs that don't use lists. And "beyond the current sentence" also seems both too narrow and too wide: the world is full of links that aren't in sentences, too-- including the ones in the examples David and Gregg cite, as well as many of those I cited in my initial post. The examples David provided don't require the user to change focus at all, and the text-hiding technique doesn't encumber the visual design. Neither does using the title attribute. But those are both HTML techniques, of course. Other technologies may not provide mechanisms for providing supplemental information (or for hiding it)-- in which case the proposed wording (for the SC might be needed to ensure that users get the information they need to find content, orient themselves within it, and navigate through it. John "Good design is accessible design." Dr. John M. Slatin, Director Accessibility Institute University of Texas at Austin FAC 248C 1 University Station G9600 Austin, TX 78712 ph 512-495-4288, fax 512-495-4524 email jslatin@mail.utexas.edu Web http://www.utexas.edu/research/accessibility -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: Sunday, February 26, 2006 2:55 PM To: 'David MacDonald' Cc: w3c-wai-gl@w3.org; John M Slatin Subject: RE: SC 2.4.5: links in context 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 Monday, 27 February 2006 00:05:56 UTC