Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I had a talk with John Slatin about 4.2.2 on 5.21.2006. 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.\"
This 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 Slatin mentioned 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 kind of thing with PlaceMarkers. When you are on the link, press CTRL K to set a temporary place marker, 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 - http://tinyurl.com/qh9o2.
There is a framed block for each hotel, of maybe 30 hotels. Each hotel block has 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 WCAG 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.
Proposed Change:
Remove SC 2.4.4.