2.4.5

I think if we stay with this SC wording for 2.4.5 we will need to make it clear that it 
is OK to have more than one link going to the same place on a web page.

Some sites have a repeat of the menu bar at the bottom of the delivery unit. (ie. site 
map, Home, products etc)

If each link has a unique function, we need to make clear the distinction between an 
exact copy of the link vs. different link text going to the same place..

David
www.eramp.com



On Mar 14, Ben Caldwell <caldwell@trace.wisc.edu> wrote:
> 
> Hi all,
> 
> Here are the resolutions from last week for the SC in question:
> 
> resolution: revise SC 2.4.5 to read, "The unique function of each link
> can be determined."
> 
> resolution: add 2.4.9 to read, "The unique function of each link can be
> programmatically determined from the link."
> 
> Based on Loretta's reply, I'm assuming that the concerns that were
> raised were about Identifying the unique function of a link using any
> combination of text associated with the link, text immediately before
> the link, and text immediately after the link <<a 
href='http://tinyurl.com/qu5sf>.'>http://tinyurl.com/qu5sf>.</a>
> 
> Michael's first proposal makes sense to me, but I'm not sure about the
> non-link part of it. Could we split things up as follows?
> 
> <proposed>
> Providing link text that describes the unique function of a link  USING
> one of the technology-specific techniques below.
> </proposed>
> 
> Here, "Providing link text that describes the unique function of a link"
> would be a general technique and the Tech specific techniques could be
> retitled as follows:
> 
> Using the a element or text alternatives for non-text content to provide
> link text
> 
> Providing link text using a text alternative for the area element
> 
> This would require splitting the existing HTML technique into two, but
> to me it makes more sense to have a general technique about providing
> links text than it does to have a series of technology-specific
> techniques that duplicates this info for each technology capable of
> providing links.
> 
> I disagree with Michael's suggestion to move the general technique in
> question to the boneyard. If we did this, there would be no difference
> between the level 2 and 3 criteria. However, we can add UA and AT notes
> (as we've already done for with the technique on supplementing link text
> with title) to address the UA support concerns here.
> 
> Misc. items I tripped over while looking at these:
> 
> - The intent section for HTM 2.4.5 is going to need work to explain the
> difference between "determined" and "programmatically determined from
> the link."
> 
> - I'm not sure "and text immediately after the link" is sufficient here.
> We don't include example for it, so maybe leaving this phrase out of the
> title for, "Identifying the unique function of a link using any
> combination of text associated with the link, text immediately before
> the link, and text immediately after the link" would be a good idea.
> 
> - How to meet 2.4.5 includes a number of references to delivery units
> that need to be updated.
> 
> Gregg Vanderheiden wrote:
> > I am a bit confused.
> > 
> > What SC are we talking about?  
> > 
> > How is   
> > 
> > Providing link text that describes the unique function of a link
> > 
> > Different from 
> > 
> > Providing link text that describes the unique function of a link   using one
> > of the technology-specific techniques below
> > 
> > Are there non-technology specific techniques for providing link text? 
> > 
> > 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 <a 
href='http://tinyurl.com/dho6b'>http://tinyurl.com/dho6b</a> 
> > 
> > -----Original Message-----
> > From: John M Slatin [mailto:john_slatin@austin.utexas.edu] 
> > Sent: Monday, March 13, 2006 3:57 PM
> > To: Loretta Guarino Reid
> > Cc: Michael Cooper; Gregg Vanderheiden; Ben Caldwell; David MacDonald
> > Subject: Suggestion re SC 2.4.5: Providing link text that describes the
> > unique function of a link
> > 
> > Both David and Michael have objected strongly to the proposed technique
> > Providing link text that describes the unique function of a link  [1].
> > 
> > Michael has suggested the following:
> > 
> > <proposed>
> > Providing link text that describes the unique function of a link   using one
> > of the technology-specific techniques below
> > </proposed>
> > 
> > This would not be a link. It would simply refer people to the HTML and CSS
> > techniques listed as sufficient in How to Meet SC 2.4.5, which are
> > currently:
> > 
> > HTML
> > * Providing link text that describes the unique function of a link  (this
> > includes examples using alt text)
> > * Providing a text alternative for the area element
> > * Supplementing link text with the title attribute
> > 
> > CSS
> > * Supplementing link text with hidden text
> > 
> > Michael also suggests moving the technique Identifying the unique function
> > of a link using any combination, etc., to the Boneyard so that we can
> > promote it to a sufficient technique when user agents support it.
> > 
> > I think this makes a lot of sense. As was said on the call last week, it
> > gives people using current AT support they need while pointing AT vendors in
> > a good direction. And it gives us an upgrade path for this particular set of
> > techniques.
> > 
> > Thoughts?
> > JOhn
> > 
> > 
> > 
> > [1]
> > <a href='http://trace.wisc.edu/wcag_wiki/index.php?
title=Providing_link_text_that_des'>http://trace.wisc.edu/wcag_wiki/index.php?
title=Providing_link_text_that_des</a>
> > cribes_the_unique_function_of_a_link
> > 
> > 
> > "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 <a 
href='http://www.utexas.edu/research/accessibility/'>http://www.utexas.edu/research/acces
sibility/</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, 14 March 2006 21:22:25 UTC