Re: 2.4.5 Proposal

>> The proposal replaces "programmatic reference" with the more
> understandable term "link"

I think that is a very good modification

> <proposed>
> 2.4.5 Text describing the context of each link can be programmatically
> determined or is available from link text in combination with parent
> structures.
> </proposed>

I'm kind of surprised that we have reopened this issue, only to make it lean more 
towards (what I consider) inaccessibility. If we are going to reopen the item, I would 
say we move in the other direction towards a closer assoication between link text and a 
description of its destination. 

To me, gramatically, the word "or" in a sentence functions like a fulcum of a balancing 
scale. Everything on one side of the fulcum has the same weight as everything on the 
other side of the fulcrum. Each side of the word "or" is of equal value. In this 
sentence the word "or" gives the concept of  undescriptive link text the same weight as 
descriptive link text. I don't think this is a good signal to send to webmasters.

If we replace the word "or" with an = sign in the sentence we are basically saying:

descriptive text = undescriptive text

in its importance, value, and validity. And we are saying this in a normative document.

I don't think the issue is *only* whether the information describing the destination is 
available. I think a significant part of the issue is what a disabled user has to go 
through to get to the description. Given that links are what makes the web what it is, 
and an active user encounters hundreds of links a day, I would not like to see the blind 
user have to lose focus and increase precious key strokes, to simply do what sighted 
people do effortlessly.

If we insist on demoting this WCAG 1.0 priority 2 item, then I prefer the ambiguity of 
the current wording "associated" better. Then at least we are not being "in your face" 
about undescriptive link text. And I think we have a precident for this ambiguity with 
our position on layout tables.  We wouldn't say "separate content from structure OR use 
layout tables" and AT has come further in accommodating layout tables than it has in 
accommodating undescriptive text since the WCAG 1.0.

Devid MacDonald

www.eramp.com

...access empowers people...
   ...barriers disable them....



On Mar 07, Ben Caldwell <caldwell@trace.wisc.edu> wrote:
> 
> 
> The following is a proposal meant to address some of the concerns that
> have been expressed on the list in recent weeks regarding success
> criterion 2.4.5 [1].
> 
> <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>
> 
> --------------------------------------------------------------------
> 
> Background:
> 
> How to meet 2.4.5 [2] contains a fairly extensive editorial note
> describing issues related to meeting this SC:
> 
> <ednote>
>    Editorial Note: The WCAG Working Group is not sure how close the
>    "association" between the text and the destination should be. On one
>    hand, if you have a page with a list of book titles with links
>    saying WORD, PDF, HTML, and TEXT following each title, it seems
>    logical that having the title next to the row of links would be
>    better than repeating the title in each of the links. It would be
>    better for people who look at the page and better for someone
>    reading down the page with a screen reader looking for a book title
>    and then selecting the type. On the other hand, allowing "text next
>    to a link" to suffice for 'associated' would allow one to say "for
>    more information" next to a link labeled "click here". This can lead
>    to a page of 'click here' links and that is not seen as desirable.
>     1. Is there a rule or wording for the success criterion that allows
>        one but not the other?
>     2. How big is the problem?
>     3. Would requiring that all links contain full information about
>        their destination (without reading any surrounding text) be
>        overly restrictive or not?
>     4. Should links be required to make sense when read out of context?
>        (Or is this requiring that pieces of content need to make sense
>        when removed from the rest of the content?)
>     5. Note: Jumping between links or listing the links on a page is a
>        common navigation technique.
> </ednote>
> 
> Here's a (highly condensed) summary of the issues with this criterion as
> it is currently written from the list:
> 
> - programmatic association of links with text describing the link
> destination significantly reduces the number of key presses required to
> understand a link
> 
> - WCAG 1.0 Checkpoint 13.1 (Clearly identify the target of each link)
> was Priority 2
> 
> - the phrase "description of the destination" might not be quite right
> 
> - some technologies may not provide mechanisms for providing
> supplemental information (or hiding it)
> 
> 
> --------------------------------------------------------------------
> 
> Proposed Revisions:
> 
> The following proposal is an attempt to address the above concerns by
> splitting the current success criterion into two as follows:
> 
> Level 2
> 
> <proposed>
> 2.4.5 Text describing the context of each link can be programmatically
> determined or is available from link text in combination with parent
> structures.
> </proposed>
> 
> Level 3
> 
> <proposed>
> 2.4.9 The context of each link can be programmatically determined.
> </proposed>
> 
> --------------------------------------------------------------------
> 
> Rationale:
> 
> 1.) The proposal replaces "programmatic reference" with the more
> understandable term "link"
> 
> 2.) The proposed replaces "text describing the destination" with, "the
> context of each link"
> 
> 3.) The proposal takes a similar approach to this issue as we've taken
> with titles in 2.4.4 and 2.4.7 (required at level 2, descriptive at
> level 3) and other SC (timeouts, contrast, etc.). So that, at level 3,
> the requirement is more strict than at level 2, requiring that assistive
> technologies have access to the link's context without taking focus away
> from the link.
> 
> 4.) For level 2, the idea would be to allow links with the same link
> text to different locations at level 2, but only if they are part of a
> hierarchical structure that could be be understood by walking up the
> tree. Sufficient techniques would then be exactly what we've already got
> written up for this technique and failures would occur when ambiguous
> links occur without preceding paragraphs, list items, or headers that
> describe their context.
> 
> 5.) The level 3 success criterion would essentially require that either
> the link itself be understandable out or context or that a title
> attribute (if the tech. supports this type of structure) be present. All
> of the sufficient techniques for this SC would also be sufficient to
> meet level 2.
> 
> Thoughts?
> 
> -Ben
> 
> [1] SC 2.4.5: links in context
> <<a href='http://lists.w3.org/Archives/Public/w3c-wai-
gl/2006JanMar/0396.html>'>http://lists.w3.org/Archives/Public/w3c-wai-
gl/2006JanMar/0396.html></a>
> [2] How to meet 2.4.5
> <<a href='http://tinyurl.com/mlvbr>'>http://tinyurl.com/mlvbr></a>
> 
> 
> -- 
> Ben Caldwell | <caldwell@trace.wisc.edu>
> Trace Research and Development Center <<a 
href='http://trace.wisc.edu>'>http://trace.wisc.edu></a>
> 
> 
> 
>

Received on Tuesday, 7 March 2006 21:57:20 UTC