WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: form label question

for

From: Jukka K. Korpela
Date: Aug 9, 2007 2:20PM

On Wed, 8 Aug 2007, Moore, Michael wrote:

> Sorry to disagree Jukka, but the title attribute is very helpful to one
> group of assistive technology users that I know of. Screen
> magnification users, specifically ZoomText. The speech engine included
> with ZoomText does not reliably report labels, even when properly marked
> up using the for and id attributes.

That's bad. How much attention should we pay to flaws in assistive
software? It was once thought that "placeholder" content in text fields is
needed to cope with software that cannot handle empty text fields, and
this was even turned into a _requirement_ in WCAG 1.0 (though with the
obscure "until user agents..." condition).

The gain needs to be weighed against the problems caused. If you have a
title attribute for, say, a radio button, the great majority of users
(namely people using common graphic browsers) will see a completely
pointless and potentially disturbing "tooltip".

Besides, in normal good form design, you have e.g. a radio button followed
by its label. This is so common that users soon figure it out and get used
to it. (It's originally bad practice, since the label should preceed the
field. But bad practice has become good practice by being so common,
almost universal.) So even if a program does not recognize the
relationships expressed by <label> markup, the user should be able to
understand which text associates with a radio button.

> JAWS will also reliably report the content of the title attribute if the
> label attribute is missing or broken.

I guess you mean the label _element_. What's the point? Why should the
label element be left out or broken?

> We have been experimenting with a
> method of taking advantage of that behavior to improve reporting of
> intervening text including instructions or questions that apply to
> multiple inputs. We purposely do not use the label element on the first
> form input following the instruction or question and place the
> instruction/question and the first response within the title attribute
> of the next form input.

I'm not sure I follow the logic.

> 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".

I hope you omitted the <br> markup (or <div> markup) for brevity here.
With the above markup, the buttons and texts would all appear on the same
line (if permitted by available width), which is _bad_. Each button/label
pair should appear on a line of its own.

> 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. 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.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/