- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Mon, 14 Feb 2005 13:27:42 -0600
- To: <Becky_Gibson@notesdev.ibm.com>, <w3c-wai-gl@w3.org>
- Message-ID: <6EED8F7006A883459D4818686BCE3B3B7ADDEE@MAIL01.austin.utexas.edu>
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 UTC