- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 6 Oct 2005 12:34:41 -0400
- To: wai-xtech@w3.org
What follows is a draft post following on to a thread on www-html.
http://lists.w3.org/Archives/Public/www-html/2005Sep/thread.html#19
I would like to know:
- Other pedagogical examples I didn't find already on the web that are as good?
- pragmatic considerations why we shouldn't present this example as
good practice?
[compare with the pragmatic considerations mitigating against fieldset/legend]
Al
-- draft follows
>Ming Teo wrote:
>>I had a concern regarding the use of checkboxes and radio buttons.
>>Firstly, as every form element should have a label with attribute
>>for="form_element", and every input thus has a name with attribute
>>name="form_element", the use of checkboxes and radio buttons fails.
>
>The for attribute refers to the value of an id attribute, not a name
>attribute.
>
>><label for="choose">First Option</label> <input type="radio"
>>name="choose" value="First Option" />
>><label for="choose">Second Option</label> <input type="radio"
>>name="choose" value="Second Option" />
>
>That should be something like this:
>
><label for="choose-first">First Option</label>
> <input type="radio" name="choose" id="choose-first" value="First Option" />
><label for="choose-second">Second Option</label>
> <input type="radio" name="choose" id="choose-second" value="Second
>Option" />
>
>--
>Lachlan Hunt
>http://lachy.id.au/
Key format fact, as Lachlan pointed out:
the 'name' attribute on a hyperlink, an 'a' element, is
interchangeable with an 'id' in hyperlinking to a document part.
the 'name' attribute on a form control (input element) is
*quite different from the 'id' attribute.* The 'id' distinguishes
this form control _as an element among all the elements in
the same document_. The 'name' identifies _what data field
this control sets in the current form_.
Nowhere is this more important than in radio buttons where the
alternative values offered for *the same form field* are only tied
together by having the *same* value of 'name' whereas for 'id' values
(and a.name values) such repetition would be wrong.
On the other hand, the example as restated commits a number
of sins vis-a-vis clearly exemplifying the functions of the markup
facets.
To further distinguish the functions of the different markup facets,
we could rephrase the example more along the lines of:
<li class="compact noBullet">
<input
type="radio"
name="MP_third_riding"
id="MP3rd-0123"
value="Pele"
/>
<label for="MP-01">
Pele<span class="more"> for MP, Third Riding</span>
</label>
</li>
<li class="compact noBullet">
<input
type="radio"
name="MP_third_riding"
id="MP3rd-012x"
value="M.Theresa"
/>
<label for="MP-02">
Mother Theresa<span class="more"> for MP, Third Riding</span>
</label>
</li>
The label for a radio button should explain not only the individual
option or answer proposed by that button, but also the 'name' that
identifies the question being answered. In theory the 'name' in the
outcome name=value could be conveyed by a 'legend' associated with a
'fieldset' collecting the set of radio buttons. In practice,
implementation vagaries have put the fieldset/legend markup under a
cloud.
A verbose label can be abbreviated in delivery contexts (screen is
many 'em' across and tall) where the sense of the 'name' will indeed
be obvious from the surroundings. The abbreviation is implemented
using display control in CSS. The span.class="more" text above is
meant to be suppressed in abbreviated display. This is a hastily
hacked together sketch for what EZ calls "layered help" and the Voice
Browser community calls "tapered prompts."
Al
ID values in tutorial examples should not be purely mnemonic. The ID
may be partly mnemonic but the examples should illustrate the fact
that variations from mnemonic usage will need to be used to ensure
uniqueness. In general, tutorial examples should use different diction
in id, name, and label in form elements to communicate the disparate
functional roles of the three strings.
Received on Thursday, 6 October 2005 16:34:53 UTC