RE: Action item: Bug 300- Form embedded in table

 

	-----Original Message-----
	From: w3c-wai-gl-request@w3.org
[mailto:w3c-wai-gl-request@w3.org] On Behalf Of Chris Ridpath
	Sent: Friday, June 25, 2004 1:22 pm
	To: Sailesh Panchang; w3c-wai-gl@w3.org
	Cc: Jim Thatcher
	Subject: Re: Action item: Bug 300- Form embedded in table 
	
	
	We have a technique that all form controls must have an
explicitly associated label[1].
	 
	Your demo table fails the technique but is still accessible
because it uses the title attribute of the control instead.
	 
	Should we modify our technique to permit the use of the title
attribute instead of an explicitly associated label?
	[JMS] I would say yes, Crhis-- there are times when the visual
design won't accommodate a text label on the screen, or when putting one
there would create clutter (for example, when the form provides three
separate fields for the various parts of a telephone number-- an example
Jim Thatcher often uses), or when an onoine survey uses a series of
horizontally laid out radio buttons to indicate strength of preference
(another of Jim's examples).  The title attribute works well in these
cases and should be allowed as a conforming technique in cases like
these.
	 
	John 
	 
	 
	 
	I think the type of form you have in the demo (using a table to
identify the controls) is a rare type. So this is not a big issue.
	 
	Chris
	 
	[1] http://www.w3.org/TR/WCAG20-HTML-TECHS/#label
	 

		----- Original Message ----- 
		From: Sailesh Panchang
<mailto:sailesh.panchang@deque.com>  
		To: w3c-wai-gl@w3.org 
		Cc: Jim Thatcher <mailto:jim@jimthatcher.com>  
		Sent: Friday, June 25, 2004 12:01 PM
		Subject: Action item: Bug 300- Form embedded in table 

		Bug 300:
		Question: what is the advice for properly labeling form
controls when those controls sit in a table and the headings of the
table provide visual clues
		for what is to be done with the controls? How should
that be marked up for assistive technology?
		 
		The first observation is that the label element cannot
work because there are (assumed to be) two pieces of text associated
with each form control -
		(the row header and the column header). At the same
time, each piece of text also goes with more than one control. Since
id's are unique, the label can only be
		used for one control.
		 
		The second possibility is that heading markup in the
table may be adequate for assistive technology; certainly all the
information would be available
		if TH is used for the appropriate headings. The problem
with this is that controls need to be navigated in "forms mode" and when
in "forms mode" the
		headings information is not announced by most text to
speech technologies. (Window-Eyes regards the table as a layout table
and table-navigation keys cannot be used; Home Page Reader does not
permit navigation in forms mode and  table mode at the same time like
JAWS does). 
		 
		The final possibility is to use the title attribute on
each input control which provides information equivalent to the row and
column headings. This
		works for all the assistive technology tested (JAWS For
Windows 5.0, Window-Eyes 4.5 and Home Page Reader 3.02). The title
attribute is read in forms mode as well as one tabs from control to
control  out of forms mode.  
		See attached example  title-FormInTable.htm
		[1]
		http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=300
		 
		Jim Thatcher and Sailesh Panchang