E-mail List Archives
Thread: Radio Buttons Again!
Number of posts in this thread: 7 (In chronological order)
From: Tim Harshbarger
Date: Mon, Oct 20 2003 6:34AM
Subject: Radio Buttons Again!
No previous message | Next message →
Hi,
I am beginning to think the bane of my existence is the labeling of radio
buttons -- most particularly those radio buttons that both share a group
label as well as each have their own specific labels.
I have a specific situation which is frustrating me currently.
Someone is designing an interface. They need the group label for radio
buttons to appear to the left of the group of radio buttons. All the
related radio buttons appear on the same line with their specific labels
appearing directly to the right of the related radio button.
Unfortunately, I haven't figured a good method for contorting the caption
element for a fieldset using CSS so it appears on the same line as the radio
buttons.
The title attribute is not a good solution because the browser the intended
audience uses makes tooltips pop-up all over the place.
And of course, the label element alone just won't do the job.
Any suggestions? I am running low on new approaches to try.
Thanks!
Tim
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Mon, Oct 20 2003 7:01AM
Subject: Re: Radio Buttons Again!
← Previous message | Next message →
On Mon, 20 Oct 2003, Tim Harshbarger wrote:
> Someone is designing an interface. They need the group label for radio
> buttons to appear to the left of the group of radio buttons. All the
> related radio buttons appear on the same line with their specific labels
> appearing directly to the right of the related radio button.
I'm not sure I understand the situation (a URL would help), but I suppose
this means that you have the entire group on one line. Well, that goes
against good accessibility, no matter what WAI guidelines say. The
guidelines formulate the relevant guideline rather confusingly, and the
"Errata" document changes (!) the recommendation, without really making
things clear. But in practical terms, the _safe_ approach is as follows:
Label for the group
( ) label for button
( ) label for button
...
where ( ) indicates a radio button. It's not just for speech browsers.
People who see a string of buttons and interspersing texts easily get
confused: which button is for which text? (Even "normal" people get
confused that way. So what about people with cognitive disabilities?)
If the design requires that the label for the group appeat to the left of
the group, the design is simply wrong, by accessibility criteria.
You can reduce some of the damage by using <label> markup etc., but just
some of it.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Randy Pearson
Date: Mon, Oct 20 2003 7:05AM
Subject: RE: Radio Buttons Again!
← Previous message | Next message →
Tim,
We're dealing with the same issue. I would like to say we have an adequate
solution, but I cannot. As an example form fragment:
Name: [_____________]
Favortite Color: ( ) Red ( ) Green ( ) Blue
1. For the textbox you'll wrap "Name" in a <label for=id>; however you
cannot do that for the "Favorite Color" label, because the radio buttons
have three different ID's.
2. We're resigned at the moment to leaving the label as "plain text" in this
case, and only using <label> wrappers on the items (Red, Blue, Green).
3. Aside: I read somewhere recently that for radio buttons, the labels
should actually preceed the physical control, more like this:
Favortite Color: Red ( ) Green ( ) Blue ( )
This advice was based on the sequencing that a screen reader would use.
We're not doing this yet, but we are thinking about it.
4. If the form is layout uses an HTML <table>, I was wondering if this
situation would be improved by placing the "Favorite Color" text (and other
labels) in <th> cells, and then specifying "headers" in the adjacent <td>.
5. This situation also applies to "choose all that apply" checkboxes.
6. Ironically, this situation does not apply to <select> dropdowns, as they
have a single ID. What that means is, if you could "detect" users with
screen readers, you could possibly arrange to switch interfaces.
>> Unfortunately, I haven't figured a good method for contorting the
>> caption element for a fieldset using CSS so it appears on the same line
>> as the radio buttons.
We looked at this too. Seems no modern browser is allowing <legend> within a
<fieldset> to be styled. Seems quite crude right now. Something to explore
again in 2+ years I imagine.
-- Randy
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Derek Featherstone
Date: Mon, Oct 20 2003 8:26AM
Subject: RE: Radio Buttons Again!
← Previous message | Next message →
> >> Unfortunately, I haven't figured a good method for contorting the
> >> caption element for a fieldset using CSS so it appears on the same line
> >> as the radio buttons.
>
> We looked at this too. Seems no modern browser is allowing <legend> within
a
> <fieldset> to be styled. Seems quite crude right now. Something to explore
> again in 2+ years I imagine.
This barebones code gives varying results (haven't tested on Mac or Linux),
but seems to allow for *some* styling that is close to what you'd like...
And of course, YMMV, and depends on whether or not you are using table for
form layout, or floated divs etc... Note the <br /> after the legend is only
in there as it seems to be a necessity in Moz and Opera for keeping the
radio options together...
<form action="foo" name="testform" id="testform">
<fieldset style="margin-left: 120px; border:0px solid #ffffff;">
<legend style="display: block; font-weight: bold; background-color:
#ffffff; color: #000000; float: left; position: relative; left: -7em; top:
1em;">More Options</legend><br />
<div><input type="radio" name="test" id="t1" /><label
for="t1">Option 1</label></div>
<div><input type="radio" name="test" id="t2" /><label
for="t2">Option 2</label></div>
<div><input type="radio" name="test" id="t3" /><label
for="t3">Option 3</label></div>
</fieldset>
</form>
Best regards,
Derek.
--
Derek Featherstone = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Andrew Kirkpatrick
Date: Mon, Oct 20 2003 8:35AM
Subject: Re: Radio Buttons Again!
← Previous message | Next message →
Not entirely true... It is a bit of a kludge, but you can hide the legend
and the fieldset border visually and then provide some text inside the form
to function as the visual version of the label.
Obviously, this breaks when stylesheets are not used, although it is more of
an offense to document semantics than to the usability of the page...
AWK
On 10/20/03 8:59 AM, "Randy Pearson" < = EMAIL ADDRESS REMOVED = > wrote:
> We looked at this too. Seems no modern browser is allowing <legend> within a
> <fieldset> to be styled. Seems quite crude right now. Something to explore
> again in 2+ years I imagine.
--
Andrew Kirkpatrick
CPB/WGBH National Center for Accessible Media
125 Western Ave.
Boston, MA 02134
E-mail: = EMAIL ADDRESS REMOVED =
Web site: ncam.wgbh.org
617-300-4420 (direct voice/FAX)
617-300-3400 (main NCAM)
617-300-2489 (TTY)
WGBH enriches people's lives through programs and services that educate,
inspire, and entertain, fostering citizenship and culture, the joy of
learning, and the power of diverse perspectives.
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: John Foliot - WATS.ca
Date: Mon, Oct 20 2003 9:56AM
Subject: RE: Radio Buttons Again!
← Previous message | Next message →
All,
Radio Buttons, Radio Buttons...
Might I also suggest to all that if/whenever possible the <select> form
input provides greater usability/accessibility for a number of reasons;
1) as previously pointed out, the ordering of radio buttons *may* have a
cognitive impact, not only for users with developmental issues, but even for
inexperienced or "mainstream" users [()radio button radio button()]. I
believe this is the point Jukka was making.
2) as this thread has pointed out, use of the <label> element is restrictive
for this form input, another area of potential negative impact.
3) users with mobility impairment issues often find that radio buttons and
checkboxes are "problematic". I have had much experience working with an
associate who is a quadriplegic and who uses voice recognition software to
access both the web and other applications. While not ideal, the software
(in his case either Dragon Dictate or the newer Dragon Naturally Speaking)
often lacks what I referred to as "fine motor control", as his ability to
move the cursor or page focus often reminds me of watching very young
children using the mouse... getting it on "target" is often a challenge.
This behaviour is more pronounced on laptop computers or older machines
lacking CPU/RAM, as the voice recognition apps are very memory intensive...
there is often a delay between "speaking" a command and the actual
implementation. And while he can "tab" through form inputs using the
software, it too has it's issues. As a result, he usually prefers the
<select> over radio buttons. From a "programming" perspective, both options
provide a means of entering a single controlled response, yet from a
usability/accessibility perspective one is clearly easier for him to use.
From a design point of view, <select>s also require less "real estate",
making forms appear "shorter", etc.... another usability "benefit".
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Mon, Oct 20 2003 10:49AM
Subject: RE: Radio Buttons Again!
← Previous message | No next message
On Mon, 20 Oct 2003, John Foliot - WATS.ca wrote:
> Might I also suggest to all that if/whenever possible the <select> form
> input provides greater usability/accessibility for a number of reasons;
You may, but may I suggest just the opposite?
> 1) as previously pointed out, the ordering of radio buttons *may* have a
> cognitive impact, not only for users with developmental issues, but even for
> inexperienced or "mainstream" users [()radio button radio button()]. I
> believe this is the point Jukka was making.
My point was that the label and the field should be very clearly
associated with each other. Using <label> markup for that is good, but
enough. It is true that <select> makes the association clear, since the
selection _is_ the text, in a sense. But a radio button and a label on a
line of their own is just as clear.
> 2) as this thread has pointed out, use of the <label> element is restrictive
> for this form input, another area of potential negative impact.
Well, you can use it to associate buttons with their labels. I don't think
we need to do much more.
> 3) users with mobility impairment issues often find that radio buttons and
> checkboxes are "problematic".
That is true. The default rendering makes them too small, and if you try
to make them bigger, many users don't like it. But by using <label> markup
together with markup that suggests the clickability of the label text,
too, I think you can remove many of the problems.
> ... getting it on "target" is often a challenge.
I am not familiar with the circumstances that you describe, but I would
say that when fine motorics is a considerable challenge, users basically
need keyboard input or its equivalent, i.e. some method for moving from an
element (such as link or form field) to another, without needing to point
at a specific location.
> From a design point of view, <select>s also require less "real estate",
> making forms appear "shorter", etc.... another usability "benefit".
I think it's not a benefit, since when a form is being filled out, then
form fields with their labels are the real thing, the content proper.
All the alternatives should be visible, without specifically opening a
<select> menu. I know that visual viewing is not the only possibility, but
it's the way that most users (including most users with some disability)
use. Besides, when radio buttons are used, you can use text styling and
even add small icons that describe the choices, whereas in <select>, you
are limited to plain text by the syntax.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/