Ian Hickson wrote:
Joe Clark wrote:
http://blog.fawny.org/2006/10/28/tbl-html/
FYI, my response to that his here.
http://lachy.id.au/log/2006/10/fixing-html
* Allow multiple uses of the same id/label in a form and suddenly it
becomes possible to mark up multiple-choice questionnaires accessibly.
Could you elaborate on this? I'm not sure how this would work with the
DOM, but I'm sure there's a way of addressing the use case you have in
mind.
I believe the issue is with the way screen readers handle existing
forms. The problem is that each radio button or checkbox has it's own
label, but the whole group is often associated with a single question
and there is no way mark that up.
e.g.
<p>Gender:
<label for="m"><input type="radio" id="m" name="gender" value="m">
Male</label>
<label for="f"><input type="radio" id="f" name="gender" value="f">
Female</label>
</p>
In this case, when screen readers are in forms mode and the user is
tabbing between form controls, it will only read out "Male" and
"Female", it won't read out "Gender:".
In this specific case, that's probably not a major issue because male
and female are fairly self explanitory, but there are many cases where
it's not.
There are workarounds using fieldset and legend for the question, like this.
<fieldset>
<legend>Gender:</legend>
<label for="m"><input type="radio" id="m" name="gender" value="m">
Male</label>
<label for="f"><input type="radio" id="f" name="gender" value="f">
Female</label>
</fieldset>
Because of the way screen readers work, they now read out "Gender: Male"
and "Gender: Female" as they tab to each control.
This example demonstrates this technique.
http://www.alistapart.com/d/prettyaccessibleforms/example_3/
The problem with that technique is that, because of the way legends are
rendered in browsers, styling is somewhat restricted.
There are a few possible ways to address this that I have thought of.
1. Allow labels to be associated with a group of form controls
by referring to the control name.
<p><label group="gender">Gender:</label>
<label for="m"><input type="radio" id="m" name="gender" value="m"
info="gender"> Male</label>
<label for="f"><input type="radio" id="f" name="gender" value="f"
info="gender"> Female</label>
</p>
(I know the for attributes aren't technically required here, but due to
current screen reader limitations, they are)
2. Allow labels to be associated with multiple controls, using a
space separated list of IDREFs (like the headers attribute in
tables).
<p><label for="m f">Gender:</label>
<label for="m"><input type="radio" id="m" name="gender" value="m"
info="gender"> Male</label>
<label for="f"><input type="radio" id="f" name="gender" value="f"
info="gender"> Female</label>
</p>
3. Allow form controls to refer to additional labels.
<p><span id="gender">Gender:</span>
<label for="m"><input type="radio" id="m" name="gender" value="m"
info="gender"> Male</label>
<label for="f"><input type="radio" id="f" name="gender" value="f"
info="gender"> Female</label>
</p>
4. Same as #3, but allow the link from the label elements instead.
<p><span id="gender">Gender:</span>
<label for="m" info="gender"><input type="radio" id="m" name="gender"
value="m"> Male</label>
<label for="f" info="gender"><input type="radio" id="f" name="gender"
value="f"> Female</label>
</p>
I think #1 is the best of these options because it's more convenient to
type a single name, than multiple IDs. Plus, if a new control gets
added to the group, it's implicitly associated without having to update
the for attribute with the new ID. I don't particularly like #3 and #4,
but they were my first thoughts, so I listed them anyway.
Start a Working Group For Web Accessibility, independent from the W3C, and
write an alternative to WCAG2. In about 2 years, if the work you've done
starts getting more traction than the W3C's work, then you'll get their
attention and then they'll start fixing the WCAG work.
Joe has already decided to take a similar approach with his WCAG
Samurai. However, he's keeping it top secret. There's virtually no
information about it and no way to participate or even keep track of the
work without an invitation.
http://alistapart.com/articles/tohellwithwcag2/#WCAG-documents:WCAGSamurai
http://wcagsamurai.org/
--
Lachlan Hunt
http://lachy.id.au/
