[whatwg] How not to fix HTML

[Lachlan Hunt]

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/