WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: form label question

for

From: John Foliot - Stanford Online Accessibility Program
Date: Aug 9, 2007 5:20PM

Jukka K. Korpela wrote:
>> JAWS will also reliably report the content of the title attribute if
>> the label attribute is missing or broken.

Uhm... (and I can be corrected here), out-of-the-box, the default setting
for JAWS is to not read the title attribute. It can be subsequently
configured by the end user to be read all or just some of the time, or not
at all. However, even if the default *is* to read the @title attribute,
given that the end user can ultimately set their machine to read or ignore
@title is, for me, reason enough to *not* use it for important information.
If the label element is missing, then the form is poorly constructed; I'm
not 100% sure how it would be "broken"...

>> Code example follows:
>>
>> <p>What is your favorite color?</p>
>> <input type="radio" title="What is your favorite color? Red." ...
>> />Red <input type="radio" title="Blue" id="blue" ... /><label
>> for="blue">Blue</label> <input type="radio" title="Green" id="green"
>> ... /><label for="green">Green</label>
>> ...
>
> This certainly violates the rule for associating labels with fields
> using markup, and it implies that e.g. a motorically challenged
> person, using a common browser, can select "Blue" by clicking on the
> word "Blue" (instead of trying to hit the tiny radio button) but
> cannot do the same for "Red".

Yes, this is horrible markup. Gerrymandering HTML to "perform" for a
specific screen reading technology is just plain *wrong* and harkens back to
the "Best viewed In..." days of web development. This 'solution' is not a
solution, and as Jukka points out, actually creates another barrier for a
different user-group. Stop trying to out think the users, and their
technology. Code to standards (please!)

>> This method provides some advantages over other methods that we have
>> tried for accomplishing the same task. If fieldsets and legends are
>> used, JAWS may not report the legend if the user has selected
>> "advanced" in their verbosity settings on the utilitity manager.

This is the end users right and privilege - who decided you could over-ride
this behaviour by working around the user-agent settings? No, no, no, no,
no!

I simply do not understand why content authors think they know better than
the end user how they wish to deal with the page content. Your mind-reading
abilities must be colossal to be able to fully comprehend and understand the
differences that each user requires, so that you can go against standards to
produce a "better experience" for all users.

As well, this whole mess seems to be geared towards JAWS - I wonder, have
you tested any of this enhancement with other screen readers?

>> Additionally if JAWS reports the legend, it will reread it for every
>> input within the fieldset. Next, JAWS will only read the legend that
>> is closest to the input, thus no nested fieldsets/legends to add
>> instructions. Finally, the ZoomText reader does not report legends
>> at all.
>
> The usefulness of fieldset and legend markup is somewhat questionable,
> when we consider its implications on current browsers. But I don't
> think this has much to do with the label and title issue.

I agree, stay on topic.

The @label attribute aids more than just the visually impaired, it is quite
useful for the mobility impaired as well.

The @title attribute may be used, but should not be relied upon for mission
critical information, as not all user agents (or UA settings) will support
the rendering of the @title's value. And while today's crop of mainstream
browsers have settled on a semi-defacto standard of the "tool tip" nowhere
within any of the W3C specs is this behaviour mandated, and this might
change at any time (so in other words, do not *expect* a tool tip forever)

Legend and fieldset are not fully supported in all user-agents: this however
is not a reason to not include them in your web forms. If your form
requires explanation, there is always the tried and true <p>Explanation text
proceeding the form</p> - no magic or trickery required. (It is worth noting
that embedding this type of information inside of the form will not expose
it to screen reading technologies anyway, as the system must go into "forms
mode", or PC cursor, as opposed to the "normal" virtual cursor)

When I do my Advocacy talks, one point I try to make is this: we are not
manufacturing automobiles, we are producing gasoline (petrol): I really
don't car what car you drive, from a Lamborghini to a beat-up old jalopy -
my concern is that I am pumping out 100% clean gasoline - no additives, no
extra junk, no "optimized for" specialty product. IMHO, suggesting this
type of "work-around" as a better way forward does a dis-service, and I
strongly urge one-and-all to *NOT* do this - it is wrong, plain and simple.

If user-agents are not supporting the spec fully, that is a problem for the
user-agent. If the end user decides to tweak their tools to meet their
personal needs, then they run the risk of short-changing themselves, but
that's for them to decide. As content developers, we should not (must not!)
try and affect these types of changes, simply to meet our perception of what
the end user needs.

My cranky $0.02 worth today.

JF