Re: Labeling Groups of Radio Buttons

aloha!

the desired functionality should be applied/attained thus:

1. use a FIELDSET to signify that a grouping of FORM controls belong
together;

2. provide a LEGEND for the FIELDSET -- in this case, "What Kind of Cheese
Do You Want on Your Pizza", and associate an accesskey with it, so that
users can easily move to and from control grouping to control grouping;
since one of FIELDSET's attributes is "id", it is best practice to associate
a unique identifier with each FIELDSET;

3. provide a LABEL for each FORM control inside the FIELDSET -- in this
case, "mozzarella", "cheddar", and "none";

putting 1 through 3 together in a barebones manner, you get:

<FIELDSET id="choose-cheese" accesskey="c">
<LEGEND>What Kind of Cheese Do You Want on Your Pizza?</LEGEND>
<LABEL for="c1">Mozzarella</LABEL> <INPUT TYPE="radio" id="c1" ...>
<LABEL for="c2">Cheddar</LABEL> <INPUT TYPE="radio" id="c2" ...>
<LABEL for="c3">None</LABEL> <INPUT TYPE="radio" id="c3" ...>
</FIELDSET>

4. the AT should provide a range of settings so that the user can fine tune
the amount and nature of the information he or she will receive when
traversing a FIELDSET...  in one such setting, "verbose forms", the LEGEND
defined for the FIELDSET would be spoken or output to a braille display (or
whatever), in conjunction with the LABEL defined for each individual form
control contained in the FIELDSET in the manner described in the post --
"What Kind of Cheese Do You Want on Your Pizza selected mozzarella", "What
Kind of Cheese Do You Want on Your Pizza not selected cheddar", "What Kind
of Cheese Do You Want on Your Pizza not selected none"

5. the AT provides a setting called "less verbose forms", in which the
LEGEND defined for the FIELDSET is spoken/output when a FORM control
contained in the FIELDSET receives focus, and the number and type of form
controls contained in the FIELDSET are announced; as the user navigates
through the FIELDSET, the LABEL for each form control and the number of that
form control, relative to the total number of form controls contained in the
FIELDSET, is spoken/output as the user navigates from form control to form
control: in this scenario, when the user establishes focus on the first form
control in the FIELDSET, he or she would hear: "What Kind of Cheese Do
You Want on Your Pizza? 3 radio buttons; mozzarella selected"; as the user
tab-navigated the FIELDSET, he or she would hear: "Cheddar, not selected, 2
of 3" and "None, not selected, 3 of 3" -- reverse navigation through the
FIELDSET from the last radio button would sound like this: "Cheddar, not
selected, 2 of 3"; "Mozzarella, selected, 1 of 3"; the user should also be
provided with a query mechanism by which he or she can review a LEGEND
defined for a FIELDSET on demand

6. the AT provides a setting called "terse forms", in which the LEGEND
defined for the FIELDSET is spoken/output when a FORM control contained in
the FIELDSET receives focus, and, if the user so chooses, announces the
number and type of form controls contained in the FIELDSET; as the user
navigates through the FIELDSET, the LABEL and state of each form control is
spoken/output; the
user should also be provided with a query mechanism by which he or she can
review a LEGEND defined for a FIELDSET on demand

this is already what screen readers attempt to do in GUI dialog boxes and
property sheets, and which many do extremely well, helped inestimably by
programmers who conscientiously label/bind descriptions to the application's
controls/widget set...  HTML4/XHTML1 defines a labeling mechanism (which
includes FIELDSET, LEGEND, and LABEL) for HTML/XHTML form controls, and WCAG
encourages authors to use them -- the onus, therefore, is clearly on AT
developers to train their software to respond to the FIELDSET, LEGEND, and
LABEL bindings correctly, that is, to extract the pertinent information
either from markup or from the Document Object Model (DOM), rather than
relying on (or waiting for) MSAA to provide a specific binding or mapping to
IE's DOM implementation...

semantically binding structures such as FIELDSET and LEGEND were introduced
into HTML4 precisely to provide the functionality thumbnailed above...
LEGEND is, by spec, the meta-label for a FORM grouping, and, as a speech
user, i find the failure of AT developers to recognize it not only
incomprehensible, but inexcusable...  inexcusable because HTML4 has been a
W3C Technical Recommendation since April 1998...  incomprehensible because,
in a section entitled "17.10 Adding Structure to Forms: the FIELDSET and
LEGEND elements", the HTML4 rec contains the following verbiage:

quote
The FIELDSET element allows authors to group thematically related controls
and labels. Grouping controls makes it easier for users to understand their
purpose while simultaneously facilitating tabbing navigation for visual user
agents and speech navigation for speech-oriented user agents. The proper use
of this element makes documents more accessible.

The LEGEND element allows authors to assign a caption to a FIELDSET. The
legend improves accessibility when the FIELDSET is rendered non-visually.
unquote

moreover, i don't think the problem identified by mike is an IE problem, as
IE recognizes FIELDSET and LEGEND -- items marked up with the FIELDSET
element are applied a default visual styling which incorporates the LEGEND
as part of the containing visual indicator of a FIELDSET -- as illustrated
in the first attachment, fieldset_style_test-default.html -- a bounding box
upon which the text defined by the LEGEND element is superimposed...  the
default visual shorthand for FIELDSET and LEGEND, which is shared by
Mozilla, can be re-styled using CSS, as illustrated by the second attached
file, fieldset_style_test-CSS.html -- further proof that IE already
recognizes FIELDSET and LEGEND...  (note: the default visual indicator of a
FIELDSET -- the bounding box upon which LEGEND is superimposed -- is, at
least in IE, immutable)

so, the elements contained in the FIELDSET, the contents of the LEGEND, and
the bindings between the labels and the checkboxes are all contained in IE's
document object model -- it is up to individual ATs to decide how to extract
that information from IE's DOM and how to present it to the user (and what
level of granularity of control the user will have over what content is
presented and how)

as for LABEL, it should not be used for grouping, even if the result in the
real world
is that it works tolerably well under certain circumstances and is better
than nothing...  why?

the HTML4 rec states:

quote When a LABEL element receives focus, it passes the focus on to its
associated control. unquote

establishing focus on a LABEL, therefore, is equivalent to establishing
focus on the associated control

moreover, the HTML4 technical recommendation's stipulation that "Each LABEL
element is associated with exactly one form control" is an assertion of
equivalency, for--while multiple labels can be associated with a single form
control--an individual LABEL is inextricably bound to a single form
control...  thus, no matter how many labels reference an individual form
control, there is a semantically hardwired equivalency relationship between
the labels and form controls, expressed via the ID/FOR referential
relationship...

so, enough about adherence to standards -- how should the conscientious
webmaster address form control labeling?

LABEL works quite well with (at least) JFW, HPR, and Window-Eyes, so, as an
"until ATs recognize the FIELDSET, LEGEND, and OPTGROUP elements..."
measure, one could consider replicating the LEGEND defined for a FIELDSET as
part of the LABEL, either as a secondary LABEL, or as a SPAN inside the
primary LABEL styled to { display : none }, although i'd strongly advise
against the latter tactic on the grounds that it confounds the user's
ability to choose NOT to hear/feel the LEGEND text repeated every time he or
she lands on a new form control -- unless, of course, that user is
proficient enough at analyzing a stylesheet on-the-fly to add a
counter-active { speak : none } rule to the @media aural portion of a
client-side stylesheet, which, of course, wouldn't actually suppress
repetition of the invisible text unless that user's AT supported the aural
properties of CSS...

mike, i'm curious as to what version of JFW you report as concatenating
labels...  perhaps it has something to do with the markup being utilized, as
you stated in your post: quote When you put controls inside of a LABEL tag,
IE promptly concatenates all of the field names into one name for each
control. unquote

controls shouldn't be contained inside a LABEL -- if you need to span a
control with a LABEL, it should be done by defining more than one LABEL
which points to the form control you wish to span, as in the following
example, which is extracted from a proposed User Agent Accessibility
Guidelines (UAAG) implementation test of browsers' ability to suppress the
automatic triggering of events caused by event handlers, as well as control
over the spawning of a new viewports without explicit user request, or
without at least prompting the user to confirm the opening of a new
viewport, unless the user has chosen to configure the user agent to open new
viewports without confirmation...  whew!  that was a mouthful...

<CODE>
<form method="post" action="http://www.w3.org/TR/uaag10/">
<p>
<label for="f1" accesskey="f"><strong>Single-field form with five options
from which to choose:</strong></label>
<br />
<select id="f1" name="condition"
onchange="if (this.options[this.selectedIndex].value != 'null') {
window.open(this.options[this.selectedIndex].value,'new','toolbar=no,locatio
n=yes,directories=no,status=yes,menubar=yes,scrollbars=yes,resizable=yes') }
">
<option value="null">Select a Guidelines Document</option>
<option value="http://www.w3.org/TR/atag10">Authoring Tool Accessibility
Guidelines 1.0</option>
<option value="http://www.w3.org/TR/uaag10">User Agent Accessibility
Guidelines 1.0</option>
<option value="http://www.w3.org/TR/wcag10">Web Content Accessibility
Guidelines 1.0</option>
<option value="http://www.w3.org/2001/03/earl/">Evaluation &amp; Repair
Language (EARL) 0.9</option>
<option value="http://www.w3.org/TR/AERT">Techniques for Accessibility
Evaluation &amp; Repair Tools (AERT)</option>
</select>
<br />
<label for="f1">Warning: The selected Guidelines document may
open in a new viewport</label>
</p>
</form>
</CODE>

in closing, i strongly encourage all AT developers to join the special
teleconference convened by the User Agent Accessibility Guidelines Working
Group to discuss changes to the assistive technology compatibility
requirements for user agents in UAAG on Thursday, May 31 from 2 to 4pm
Boston time -- the phone number to call in is: +1 617 252 1038

an agenda for the teleconference can be found at:
http://www.w3.org/WAI/UA/2001/05/wai-ua-telecon-20010531.html

as the 25 May 2001 draft of the User Agent Accessibility Guidelines
eloquently state: "Note that the ability of conforming user agents to
communicate well with assistive technologies will depend in part on the
willingness of assistive technology developers to follow the same standards
and conventions for communication."

gregory.

References:
1. HTML4 Definition of FIELDSET
http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET

2. HTML4 Definition of LEGEND
http://www.w3.org/TR/html4/interact/forms.html#edef-LEGEND

3. HTML4 Definition of LABEL
http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1

4. HTML4 Section 17.10: "Adding Structure to Forms"
http://www.w3.org/TR/html401/interact/forms.html#h-17.10

5. XHTML 1.0: The Extensible Hypertext Markup Language, A Reformulation of
HTML4 in XML 1.0
http://www.w3.org/TR/xhtml1/

6. Cascading Style Sheets, Level 2, Section 19: Aural Style Sheets
http://www.w3.org/TR/CSS2/aural.html

7. User Agent Accessibility Guidelines
   (9 April 2001 Last Call Draft)
http://www.w3.org/WAI/UA/WD-UAAG10-20010409/

8. User Agent Accessibility Guidelines
   (25 May 2001 Working Group Draft)
http://www.w3.org/WAI/UA/WD-UAAG10-20010525/

9. User Agent Accessibility Guidelines Assistive Technology Developer Survey
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0225.html

-----------------------------------------------------
He that lives upon Hope, dies Farting.
     Benjamin Franklin, Poor Richard's Almanack, 1736
-----------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
             http://www.hicom.net/~oedipus/index.html
-----------------------------------------------------

----- Original Message -----
> Mike,
>
> You bring up an interesting concept, especially where IE is concerned.
>
> Window-Eyes supports what you're trying to do, but IE does not. Here's
> why.
>
> When you put controls inside of a LABEL tag, IE promptly concatenates
> all
> of the field names into one name for each control. You can see this
> clearly
> with INSPECT or AccExplorer (both from the MSAA SDK -
> http://www.microsoft.com/enable/msaa/download.htm). So with Window-Eyes
> (out of MSAA), you would tab to the first radio button and hear, "What
> kind
> of cheese do you want on your pizza Mozzarella Cheddar None."
>
> If IE would properly assign names to the right controls, then
> Window-Eyes
> would speak (when you tabbed), "What kind of cheese do you want on your
> pizza checkbox checked Mozzarella." Another tab would yield, "What kind
> of
> cheese do you want on your pizza checkbox checked Cheddar," and so on.
>
> So what you're trying to do is correct and a good design method. But IE
> either doesn't understand that, or accept that. Looks like it's time to
> contact our favorite Microsoft representatives. <grin>
>
> At 11:44 AM 5/25/2001 -0500, Mike Scott wrote:
> >Does anyone have ideas on the appropriate way to mark up a group of
> >radio/option buttons (input type="radio") so that a screen
> reader/talking
> >browser can identify the group name as well as the label of the
> individual
> >buttons.
> >
> >For example, if the group was:
> >         "What kind of cheese do you want on your pizza?",
> >and the radio buttons are:
> >         "Mozzarella",
> >         "Cheddar",
> >         "None".
> >
> >and the user tabbed to the radio buttons (a la IE & JAWS in "forms
> mode"),
> >only the radio button label is read. So in this case, the user hears
> >"Mozzarella [tab]Cheddar [tab] None" but never hears what the question
> is...
> >
> >Currently, I've got the radio button labels (Mozzarella, Cheddar, none)
> >tagged with <Label> for their respective buttons. I've tried using
> ><Fieldset> with <Legend> marking up the group label (What kind of
> cheese...)
> >, but JAWS doesn't read it as I would have expected. Home Page Reader
> >handles it a little better by simply reading the group lable before the
> >first value -- if you're on the third button, you still have to arrow
> back
> >to the first if you want to re-read the group label, but it's
> managable.
> >
> >So two questions:
> >(1) What is the "correct" way to markup the button and group labels?,
> and
> >(2) What is the most practical way considering what the leading
> assistive
> >technologies support?
> >
> >Thanks,
> >Mike
>
> --
> Aaron Smith
> GW Micro
> Phone: 219/489-3671
> Fax: 219/489-2608
> WWW: http://www.gwmicro.com
> FTP: ftp://ftp.gwmicro.com
> Technical Support & Web Development