- From: Loretta Guarino Reid <lguarino@adobe.com>
- Date: Mon, 22 May 2006 12:50:41 -0700
- To: <public-wcag-teamb@w3.org>
- Message-ID: <EDC8DDD212FEB34C884CBB0EE8EC2D916927BA@namailgen.corp.adobe.com>
Jim and I had been having a discussion about the Link Text success criteria that needs to move to the Team B list. Loretta Guarino Reid lguarino@adobe.com Adobe Systems, Acrobat Engineering ________________________________ From: Jim Thatcher [mailto:jim@jimthatcher.com] Sent: Monday, May 22, 2006 10:33 AM To: 'Gregg Vanderheiden'; Loretta Guarino Reid Subject: RE: Link Text SC's Hi Loretta and Gregg, I had a talk with John about this yesterday. It is clear that what he was looking for: > The goal was to permit the user to explore the context without needing to navigate away from the link. ... as you put it Loretta. I think that is an admirable and very understandable user goal. But I think it is impossible to build this requirement build into a success criterion. Using a phrase like "Programmatically associated" without defining it - doesn't solve the problem. Screen Reader/2 for OS/2 had a key command that allowed the user to "save the current state" do any other command, and return to the saved state when that completed or was stopped. So the goal of allowing the user to explore the context is AT specific, which you mentioned, Loretta. The point is that there is nothing structural about that exploration. Nothing related to the current link. You could "push the state, and read "line" 123" and be back where you were. You could read the whole page and be back at your link. John mentioned http://slashdot.com <http://slashdot.com/> as an example. In this case the context is the text above, not a paragraph; good context is the previous heading. But with current AT - I think - you can't read the previous heading without loosing your place - or the previous paragraph. There are several different situations on Slashdot.com where generic links relate to a previous text which is not a paragraph tag - just a div. However, with Slashdot (as John pointed out in our conversation), when you move to the Read more link from the JAWS links list JAWS announces the heading which is the (or a) context for the link - that's cool. Furthermore, even though JAWS isn't as sophisticated as Screen Reader/2 (!) you can accomplish the same thing with PlaceMarkers. When you are on the link, press CTRL+K to set a temporary place market, Press SHIFT+H for previous heading, Press K to return to the PlaceMarker, and you are back at the link. So the context is read without loosing your place. One of my favorite examples of this problem area is the Priceline.com hotel listing: The 7 generic links, Choose, More, Features, etc., all concern the hotel at the top of the block. Priceline uses the title attributes to resolve this but we all know how well that is supported - the issue here is not about the title attributes - The issue is that there is no sensible "Programmatic association" of the hotel title to the generic links. For each generic link there is a (different) technique for accessing the hotel name - using a PlaceMarker. For Choose, use next table cell (CTRL ALT+RIGHT ARROW). For More, Features, ... Map, use current table cell,(CTRL+ALT+UP ARROW), For the last link go up two cells. Combine these with the CTRL+K and K combination, and one is able to explore context with out loosing the link. The reason I am saying all this is I believe that there is nothing special about these examples. I think it is always going to be possible to find a combination of keys that will provide context for a "generic link." And I think there will be no general sequence that will work in all or even many cases. (How about setting a place marker and moving back (up arrow) in the document? It fails for the Choose link in the Priceline example.) In the same way as the Priceline and Slashdot examples, the first and third Examples of Success Criterion 2.4.4 don't necessarily have any programmatic connection to the link itself. The important information could just be in a div - not the same paragraph, maybe not the same table cell. But WCGA 2.0 calls these success! I think that 2.4.4 should be eliminated because there is no definition of what is wanted, and I think what is wanted will always be available anyway. Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931 -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: Monday, May 22, 2006 9:59 AM To: 'Loretta Guarino Reid'; jim@jimthatcher.com Subject: RE: Link Text SC's Yes. That was one item that underwent a LOT of debate and that language was what people could finally reach consensus on. But maybe that was because people could read it how they wanted to. Not a good solution. Lets see if we can lose programmatically associated - and come up with language that means the same - that is what the group came to agreement on. John was a key player in that one so lets see if we can get his opinion on the final version. 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 <http://tinyurl.com/cmfd9> ________________________________ From: Loretta Guarino Reid [mailto:lguarino@adobe.com] Sent: Monday, May 22, 2006 8:06 AM To: jim@jimthatcher.com Cc: Gregg Vanderheiden Subject: Re: Link Text SC's Thanks, Jim. This is helpful feedback. It is possible to fail 2.4.4, but it looks like we do need better explanations. The goal was to permit the user to explore the context without needing to navigate away from the link. That is, if there is context that a user agent might be able to provide from the link, that is acceptable, but not if the user needs to start moving around in the content to explore the context. So asking for the enclosing sentence, the previous or the following sentence, the enclosing paragraph, or the contents of the current link item are "programmatically associated" contexts that a user might need to request from the user agent to understand the link in context. The more "navigation" needed to reach the relevant context, the less likely a user agent will provide a way to request that information from the link. So the paragraph before the table which contains a link in one of its cells is not programmatically associated with that link. This is another instance where user agent capabilities will influence what it means to be "associated", and the answer may change over time. Gregg, we ought to think about whether there is a better phrase than "programmatically associated"; I can see how it could be mistaken for "programmatically determined". Loretta On 5/21/06 12:18 PM, "Jim Thatcher" <jim@jimthatcher.com> wrote: Hi Loretta, I had read the "How to's" but not carefully enough. I had actually compared them and thought the two How To sections (for 2.4.4 and 2.4.8) were essentially the same. With one exception: the undefined phrase "Programmatically associated." So I did not read carefully enough. I suspect that my concern over "programmatically associated" clouded my thinking. Is it possible to remove the word "programmatically" from 2.4.4? That concept seems to me to be the difference between 2.4.4 and 2.4.8. In one case 2.4.8 the purpose of the link can be determined by computer; in the other it can't necessarily. Benefits of 2..4.4 specifically mentions screen reader list of links; I think it shouldn't because compliance with 2.4.4 does not necessarily result in that benefit. Of course, neither does 2.4.8 but compliance with 2.4.8 could yield a good links list. List of book titles example - in the 2.4.8 case, the book-title text is "associated with" the link - But just reading that, it sounds like the wording of 2.4.4. I think it means associated like with the title attribute. Finally, is it possible to fail 2.4.4? Probably not realistically. Only by not telling anybody what the link is for. So what is the definition of "programmatically associated?" I have just done a search on my desktop and in every occurrence I found, the phrase is used as synonomous with "programmatically determined." But wouldn't that definition make 2.4.4 the same as 2.4.8? Nit: "success criterion 3.2.4" should be a link in How to Meet 2.4.4. Sorry for bothering you with this, Loretta. I am at the final stage of editing my chapter on navigation, and was writing about 2.4.4 (and 2.4.8). So my only suggestion is to remove "Programmatically" in which case I think 2.4.4 has almost no benefit at all. Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931 -----Original Message----- From: Loretta Guarino Reid [mailto:lguarino@adobe.com] <mailto:lguarino@adobe.com%5d> Sent: Saturday, May 20, 2006 9:04 PM To: jim@jimthatcher.com Subject: Re: Link Text SC's Jim, have you read the techniques in the How To document for these SC? I want to make sure that our understanding of what is permitted by this SC match. We spent a LOT of time wrestling over this issue, and tried to make sure that the documents expressed our intentions. The techniques documents also include John's research on what sorts of "context" support is available today from assistive technology. Suggestions for clearer wording are always appreciated. (I miss John...) Loretta On 5/20/06 6:54 PM, "Jim Thatcher" <jim@jimthatcher.com> wrote: > "Read more" following the opening sentences of an article satisfies 2.4.4 - There is no way, in my opinion, that the link information in this (rather typical) example is "Programmatically associated" with that link. He said that having no definition of "Programmatically associated". If that is the intention of the SC (which I accept) then the wording must change. Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931 -----Original Message----- From: w3c-wai-gl-request@w3.org [ mailto:w3c-wai-gl-request@w3.org] <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> On Behalf Of Loretta Guarino Reid Sent: Saturday, May 20, 2006 6:22 PM To: jim@jimthatcher.com; 'Gregg Vanderheiden'; WCAG Subject: Re: Link Text SC's Actually, "Click here" with a good title attribute satisfies both, since the title attribute is explicitly associated with the link (so you could include that information in the link list). However, "Read more" following the opening sentences of an article satisfies 2.4.4 but not 2.4.8. On 5/20/06 4:08 PM, "Jim Thatcher" <jim@jimthatcher.com> wrote: Thanks Loretta - I now understand the intended difference - but it sure isn't/wasn't clear to me. "Click here" with a good title attribute is good for 2.4.4 but not 2.4.8. Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931 -----Original Message----- From: Loretta Guarino Reid [mailto:lguarino@adobe.com] <mailto:lguarino@adobe.com%5d> <mailto:lguarino@adobe.com%5d> <mailto:lguarino@adobe.com%5d> <mailto:lguarino@adobe.com%5d> <mailto:lguarino@adobe.com%5d> Sent: Saturday, May 20, 2006 5:30 PM To: jim@jimthatcher.com; 'Gregg Vanderheiden'; WCAG Subject: Re: Link Text SC's Context can be used in interpreting the link in 2.4.4, but not in 2.4.8. (See the technique that is sufficient for 2.4.4 but not for 2.4.7: Identifying the purpose of a link using link text combined with link context USING a technology-specific technique below (for a technology in your baseline)) If 2.4.8 is satisfied, a list of links for a web unit should give a user sufficient information to understand the purpose of each link. This may not be true when only 2.4.4 is satisfied, since it may be necessary to retrieve the context of the link to understand its purpose. Loretta On 5/20/06 3:19 PM, "Jim Thatcher" <jim@jimthatcher.com> wrote: In 2.4.4. text (from which its purpose can be determined) has to be associated with the link. In 2.4.8 the link text has to describe the purpose of the link Sound similar. So, must ask again, what is the difference? Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931 -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] <mailto:gv@trace.wisc.edu%5d> <mailto:gv@trace.wisc.edu%5d> <mailto:gv@trace.wisc.edu%5d> <mailto:gv@trace.wisc.edu%5d> <mailto:gv@trace.wisc.edu%5d> <mailto:gv@trace.wisc.edu%5d> <mailto:gv@trace.wisc.edu%5d> Sent: Saturday, May 20, 2006 4:08 PM To: jim@jimthatcher.com; 'WCAG-WG' Subject: RE: Link Text SC's In 2.4.4. text has to be associated with the link. In 2.4.8 the link text has to describe the purpose of the link. 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 <http://tinyurl.com/cmfd9> <http://tinyurl.com/cmfd9> ________________________________ From: w3c-wai-gl-request@w3.org [ mailto:w3c-wai-gl-request@w3.org] <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> <mailto:w3c-wai-gl-request@w3.org%5d> On Behalf Of Jim Thatcher Sent: Saturday, May 20, 2006 2:33 PM To: 'WCAG-WG' Subject: Link Text SC's Can someone please explain the difference between SC 2.4.4 and SC 2.4.8. They seem the same to me. The "How To Meet" text is essentially the same (when "programmatically associated" is defined as someone has suggested). Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931
Attachments
- image/jpeg attachment: image001.jpg
Received on Monday, 22 May 2006 19:51:06 UTC