RE: SC 3.1.4 edits

Comments below, preceded by [js].
 

"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 6:21 pm
	To: public-wcag-teamb@w3.org
	Subject: SC 3.1.4 edits
	
	

	I've been editing SC 3.1.4 and its techniques in response to
comments in the surveys. There were a few non-editorial issues I wanted
to bring up:

	1.      There seems to be some sentiment that "Using the title
attribute to provide explanations of words or phrases
<http://trace.wisc.edu/wcag_wiki/index.php?title=Using_the_title_attribu
te_to_provide_explanations_of_words_or_phrases> " (formerly
"Supplemental Meaning Cues") is not a sufficient technique. Should it be
moved to Advisory?
	[JMS]  Yes.

	2.      There are requests for discussion of when to use <abbr>
and when to use <acronym>. Does anyone know the answer? Is this a
technology issue? Is it a language issue that should refer to the
general technique "Providing the expansion or explanation of an
abbreviation
<http://trace.wisc.edu/wcag_wiki/index.php?title=Providing_the_expansion
_or_explanation_of_an_abbreviation> "?
	[JMS] Argh! There was a huge thread about this several months
ago (maybe before the Brussels meeting). That discussion led to the
current Glossary item. HTML 4.01 and XHTML 1.x contain both <abbr> and
<acronym> elements. XHTML 2.0 (in draft) has only <abbr> because it is
the more general term== acronyms and initialisms are both subclasses of
abbreviation. My inclination is to recommend <abbr> but to accept
<acronym> as well if the DTD supports it. They are reported exactly the
same way by screen readers.

	
	[JMS] The only way it might make a practical difference would be
if a scripted lookup function knew only about either abbr or acronym but
not both.       
	[JMS] 

	 Although I thought that "first in a delivery unit" was
unambiguous, there seems to be confusion about the meaning of "first" in
"Providing the abbreviation immediately following the first use of the
expanded form within the delivery unit
<http://trace.wisc.edu/wcag_wiki/index.php?title=Providing_the_abbreviat
ion_immediately_following_the_first_use_of_the_expanded_form_within_the_
delivery_unit> ". Does anyone have any suggestions for how to make this
clearer?
	[JMS] See Gregg's response on this one. We may want to make this
something like "first occurrence in the authored unit." If an authored
unit contains several aggregated authored units, this would result in
redundant expansions, which would still do no harm (MHO) and would be
sufficient. That is, we're not trying to *exclude*/forbid expanding
multiple instances of an abbreviation or acronym-- just trying to make
sure that it happens at least once, and that that's the first time the
abbreviation or acronym appears in what the user encounters.

	4.      There are lots of comments and questions on the general
technique  "Providing the expansion or explanation of an abbreviation
<http://trace.wisc.edu/wcag_wiki/index.php?title=Providing_the_expansion
_or_explanation_of_an_abbreviation> ". Christophe, would you be willing
to try to clarify what sorts of information should be provided for
different classes of abbreviations?

	Loretta Guarino Reid

	lguarino@adobe.com

	Adobe Systems, Acrobat Engineering