W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2005

RE: [TECHS] Review of Test #168 - propose marking it as optional

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Mon, 14 Feb 2005 13:27:42 -0600
Message-ID: <6EED8F7006A883459D4818686BCE3B3B7ADDEE@MAIL01.austin.utexas.edu>
To: <Becky_Gibson@notesdev.ibm.com>, <w3c-wai-gl@w3.org>
Becky Gibson wrote:
<blockquote>
In my opinion, fieldset and legend should not be required for
conformance and this test should be marked as optional.  It does offer
good advice and is
already in our  HTML techniques document[2].  As long as labeling of
form controls is required, the author should not be forced to group
related components.
</blockquote>
 
I disagree, 
 
at least as far as radio buttons are concerned.  As far as I know,
placing a set of radio buttons and their labels within a fieldset
element and providing a legend is the only way to ensure that screen
readers can programmatically determine the prompt for which the radio
buttons provide possible answers.  Without the fieldset and legend, one
hears the individual options and thir status, but there's no way to find
out what question they might be answers for or what statement they're
responding to. *if* the question/prompt just happens to be positioned
immediately above the first radio button, and *if* there aren't too many
intervening HTML elements (such as nested tables) between the screen
text and the radio button, then *maybe* the screen reader speaks the
prompt-- when you tab to the first item.  But better make sure you don't
forget what the question was (say on a multiple-choice exam), because
there's no way to find out except to arrow back up.  If a JAWS user is
in forms mode when she [resses the up arrow, she will then select the
previous radio button; and when she hits the first item I think she
might cycle back down to the last one, which would then be selected...
HPR would also require the user to drop out of controls mode (alt+o) and
go into items mode (alt+i), then left-arrow back through the radio
buttons to find the preceding text.  But that text wouldn't be
programmatically associated with the set of radio buttons.
 
I don't know how WIndow-Eyes or HAL decide what text to use as the
prompt for a group of radio buttons.
 
 
Becky continues:
<blockquote>

 Also, this opens up additional issues with what information is required
for the <legend> element. For example, is descriptive text required and
would
we need a test to verify the <legend> was not blank and contained an
appropriate description?
</blockquote>
I'm not sure "descriptive" really captures the purpose of the <legend>
in the case I discussed above (e.g., a multiple-choice test, etc.).
Maybe something like:
 
The legend includes text to which a set of radio buttons and associated
labels provides possible responses.
 
Ugly, ain't it?
 
So... <fieldset> and <legend> may be optional when input type <> "radio"
but are required when input type="radio"
 
I don't feel as strongly about checkboxes.
 
Becky lists
<blockquote>
Other issues:
Currently this test is associated with Guideline 1.1: Provide text
alternatives for all non-text content. There is no particular success
criteria associated
with the test.    I believe it should be under Guideline 2.4 Provide
mechanisms to help users find content, orient themselves within it, and
navigate through
it [3].  And be associated with Level 3 Success criteria #1: When
content is arranged in a sequence that affects its meaning, that
sequence can be determined
programmatically [4]  Although I realize that may be a bit of a stretch.
It also falls under Level 1 success criteria for this Guideline:
Structures
and relationships within the content can be
programmatically determined.
</blockquote>
I agre that this doesn't belong under 1.1.
 
I would put the requirement to use fieldset and legend for radio buttons
under 1.3 L1 SC1. As things stand now, that would also place it under
2.4 L1 SC1, which is a cross-reference to 1.3 L1 SC1.
 
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/> 


 

	-----Original Message-----
	From: w3c-wai-gl-request@w3.org
[mailto:w3c-wai-gl-request@w3.org] On Behalf Of
Becky_Gibson@notesdev.ibm.com
	Sent: Monday, February 14, 2005 10:23 am
	To: w3c-wai-gl@w3.org
	Subject: [TECHS] Review of Test #168 - propose marking it as
optional
	
	

	As part of the Techniques Working group review of tests, I was
assigned test #168 [1]: 
	In all forms, all radio button and checkbox groups that provide
multiple value choices for a single field name are grouped using
fieldset and legend elements. 
	
	In my opinion, fieldset and legend should not be required for
conformance and this test should be marked as optional.  It does offer
good advice and is already in our  HTML techniques document[2].  As long
as labeling of form controls is required, the author should not be
forced to group related components.  Also, this opens up additional
issues with what information is required for the <legend> element. For
example, is descriptive text required and would we need a test to verify
the <legend> was not blank and contained an appropriate description? 
	
	Other issues: 
	Currently this test is associated with Guideline 1.1: Provide
text alternatives for all non-text content. There is no particular
success criteria associated with the test.    I believe it should be
under Guideline 2.4 Provide mechanisms to help users find content,
orient themselves within it, and navigate through it [3].  And be
associated with Level 3 Success criteria #1: When content is arranged in
a sequence that affects its meaning, that sequence can be determined
programmatically [4]  Although I realize that may be a bit of a stretch.
It also falls under Level 1 success criteria for this Guideline:
Structures and relationships within the content can be programmatically
determined <http://www.w3.org/TR/WCAG20/#programmaticallydetermineddef>
. 
	
	There are also no written instructions for this test.   The
Procedure, Expected Results, and Fail Instructions all contain, "TODO"
placeholder text.  Here are proposed instructions: 
	Procedure: 
	1. Check all <input> elements of type radio which contain the
same name attribute, indicating that the radios apply to a single
submitted field value.   
	Check all <input> elements of type checkbox which contain the
same name attribute, indicating that the checkboxes apply to a single
submitted field value. 
	2. The related radio or checkbox <input> controls must be
surrounded with <fieldset> and <legend> elements. 
	
	Expected Results: 
	1.  All <input> elements of type radio which contain the same
name attribute are grouped together using <fieldset> and <legend>
elements. 
	2. 1.  All <input> elements of type checkbox which contain the
same name attribute are grouped together using <fieldset> and <legend>
elements. 
	3. The <legend> element contains text that describes the
grouping of elements. (editor's note  - this may be getting too
specific). 
	
	Fail Instructions: 
	1. Group related radio and checkbox elements that provide
multiple, possible values for a single field name within <fieldset> and
<legend> elements. 
	
	I also think that the examples for this test are incorrect. The
test description relates specifically to radio and checkbox groups but
the test uses a grouping of text fields as an example.  I did create a
more valid pass test file since the HTML technique is missing a radio
button example, as well.  The file is attached. 
	
	
	[1]http://www.w3.org/WAI/GL/WCAG20/tests/test168.html
<http://www.w3.org/WAI/GL/WCAG20/tests/test168.html>  
	[2]http://www.w3.org/TR/WCAG20-HTML-TECHS/#fieldset
<http://www.w3.org/TR/WCAG20-HTML-TECHS/#fieldset>  
	[3]http://www.w3.org/TR/WCAG20/#navigation-mechanisms
<http://www.w3.org/TR/WCAG20/#navigation-mechanisms>  
	[4]http://www.w3.org/TR/WCAG20/#navigation-mechanisms-one-seq
<http://www.w3.org/TR/WCAG20/#navigation-mechanisms-one-seq>  
	
	
	
	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 <mailto:gibsonb@us.ibm.com> 
	
Received on Monday, 14 February 2005 19:27:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:35 GMT