Added situations to proposed HTM 1.3.1

I have updated the proposed HTM 1.3.1 document in the wiki [1] with 2 
situations as discussed in the team C call of December 11.  The situations 
could used some additional word-smithing - I'm not sure how to explain 
when plain text is needed without exactly repeating the SC text.  I have 
used  "semantic structure" but it would be better is there was another 
term or description. 

Situation A - When the technology provides semantic structure to make 
relationships and information conveyed through presentation 
programmatically determinable, the following are sufficient: 

followed by HTML and Scripting techniques

Situation B: When the technology in use does NOT provide the semantic 
structure to make the presentation and relationships conveyed through 
presentation programmatically determinable, the following would be 
sufficient: 

followed by general and plain text techniques 

Also, if we are going to have a situation that allows plain text, should 
this be part of the SC text?  Should we consider updating 1.3.1 to:

Info & Relationships: Information and relationships conveyed through 
presentation <ins>are available in plain text or </ins>can be 
programmatically determined  and notification of changes to these is 
available to user agents, including assistive technologies. 

We never really give specific information about the last clause - making 
the changes available to UA and AT - in the HTM documents.  It is sort of 
implied that if you use semantic structure  the changes will also be 
available.  But, I think that is ok, since not all information and 
relationships will have changes that the UA and AT need to be notified 
about. 

I haven't updated the intent section yet to address Cynthia's concern 
about how people know what types of information must be made available to 
UA and AT.  For example if prices are marked in red bold, must there be a 
textual way to identify that as well?  I think that as long as the $ sign 
is available then the price IS identified in text.  We probably need to 
spell that out somewhere but that might be a better example for 1.3.2.   I 
also had ideas of trying to explain in the intent that if the information 
can be determined when the content is accessed serially that the 
information is appropriately identified.  If any one else wants to take a 
shot at integrating that into the in progress how to meet document [1], 
please do! 

I suggest adding another example to F2: Failure of SC 1.3.1 and 1.3.4 due 
to using CSS to create variations in presentation of text that conveys 
information without also using the appropriate markup or text [2] 

Failure example 2: Using the <strong> element  to convey information other 
than emphasis.
Instructions for an on-line form  indicate that, "The label of required 
fields are emphasized" and the markup encloses the <label> elements within 
<strong>.

<p>The label of required fields are emphasized.</p>
<form>
<strong><label for="name">Name: </label></strong><input id="name" 
type="text" value="" />
...... other fields
</form>

This is a failure because even though the <stong>element does 
programmatically indicate emphasis, it does not provide the information 
that the field is required. 



[1] 
http://trace.wisc.edu/wcag_wiki/index.php?title=In_progress_update_of_HTM_1.3.1
[2] 
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS-20060801/Overview.html#F2

Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com

Received on Thursday, 14 December 2006 20:54:35 UTC