RE: Soliciting advice on SC 2.4.5

Some comments below.
 
Thanks, Loretta!
 
John
 

"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/
<http://www.utexas.edu/research/accessibility/> 


 

 



________________________________

	From: public-wcag-teamb-request@w3.org
[mailto:public-wcag-teamb-request@w3.org] On Behalf Of Loretta Guarino
Reid
	Sent: Monday, February 13, 2006 4:02 pm
	To: public-wcag-teamb@w3.org
	Subject: Soliciting advice on SC 2.4.5
	
	

	I've been working on this How To page 

	
http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Success_Crit
erion_2.4.5
<http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Success_Cri
terion_2.4.5>  

	and its techniques. 

	1.      Are Associating the description of a delivery unit with
its reference
<http://trace.wisc.edu/wcag_wiki/index.php?title=Associating_the_descrip
tion_of_a_delivery_unit_with_its_reference&action=edit>  and Providing a
supplemental description of a delivery unit
<http://trace.wisc.edu/wcag_wiki/index.php?title=Providing_a_supplementa
l_description_of_a_delivery_unit&action=edit>  general techniques that
we need to define? If so, what do they need to address?

	2.      I've written a draft for Describing the delivery unit in
text immediately preceding the programmatic reference
<http://trace.wisc.edu/wcag_wiki/index.php?title=Describing_the_delivery
_unit_in_text_immediately_preceding_the_programmatic_reference>  , but
there isn't much too it, and I don't know how to define how much text,
or how to find the text, in a testable manner. Comments or suggestions?
	[JMS] Hoo boy. If I remember correctly, this SC uses the term
"programmatic reference" because it's general enough to cover both
conventional hyperlinks and the content displayed in frames So we would
need an example to cover that case, I think. Yvette, can you help with
this?

	In the second example-- the one about the course catalog-- the
text in the link to the HTML version ("HTML version") is included in the
"text immediately preceding the link" to the PDF version (whose link
text is "PDF version").

	 

	So suppose I land on something that makes JAWS say "Link PDF
version." I then press the new screen reader keystroke (the one we're
expecting AT vendors to provide) to make it read the text immediately
preceding the link I'm on. So I hear something like "HTML version." Or
is the AT supposed to be smart enough to know that link text shouldn't
be treated as context for another link, and that both of them refer back
to some other run of prior text? 

	 

	Do we want the following to pass?

	<p>For more information about how to order your very own
tarantula today, click <a
href="http://www.example.com/someComplicatedMeaninglessQueryString">here
</a>!"

	 

	How much of this is the AT supposed to read when I hit that
"context, please" keystroke?

	 

	I think Sofia made an important point on the call last week. For
form controls, we specifically tell authors they *can't* rely on AT to
determine the correct label just by looking at context-- visual
proximity is important but doesn't guarantee anything as far as AT is
concerned. Why should we expect AT to make context work for links when
it can't do it for form controls (and we don't expect it)?

	
<http://trace.wisc.edu/wcag_wiki/index.php?title=Supplementing_link_text
_with_the_title_attribute> 

	
	 Supplementing link text with the title attribute a sufficient
technique? John, do I remember you saying that it is not supported by
screen readers? 
	[JMS]  WOuld that it were that simple!! I think this *should* be
a sufficient technique-- unlike my rant in the previous item, I think
it's entirely reasonable to ask AT vendors to speak *both*screen text
*and* title for text links, or alt text and title for graphical links.

	 

	Current screen readers *do* support title. However, users
currently have to choose *either* hearing the screen text  *or* hearing
the title (for text links). If you choose title, the screen reader
speaks *only* the title-- it completely replaces the screen text of the
link. Ditto for alt and title on images andgraphical links: you get
*either* alt *or* title. Not both.

	 

	So with today's screen readers, the following would not yield
the result one would hope for:

	<a href=http://www.examplecom/fullStoryOfMyLife.htm
<http://www.examplecom/fullStoryOfMyLife.htm>  [JMS] title="of my
life:>Full story</a>

	 

	In order for a screen reader to speak "Link Full story of my
life"  the code would have to be:

	<a href=http://www.example.com/fullStoryOfMyLife.htm
<http://www.example.com/fullStoryOfMyLife.htm>  [JMS] title="Full story
of my life">Full story</a>

	 

	I would support use of title to provide supplemental information
as a sufficient technique, and I think we should ask the AT vendors to
support it as well.

	 

	FOr what it's worth, there *is* an option in JAWS 6.x (maybe
even 5.x) to support *both* label **and* title for form controls, so we
know they can do it!

	 

	John 

	4.      I moved Providing adjacent image and text links that
point to the same resource
<http://trace.wisc.edu/wcag_wiki/index.php?title=Providing_adjacent_imag
e_and_text_links_that_point_to_the_same_resource>  from a technique to a
common failure. Do you agree?



	Loretta Guarino Reid

	lguarino@adobe.com

	Adobe Systems, Acrobat Engineering