WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: form label question

for

From: Moore, Michael
Date: Aug 9, 2007 3:50PM

My responses are in-line below:


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.

Jukka's Response:

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

Mike's reply:

I respectfully disagree, the limitations of assistive technology should
be considered when developing web content or applications. Consider the
use of a skip link for example: Modern screen readers support
navigation by headings thus eliminating the need for skip links for
those users when we use headings properly. However, other groups of
users still benefit, e.g. somone who navigates via the keyboard instead
of a mouse, so we still use skip links and we make them visible. If the
worlds most popular browsers supported navigation by headings then there
would be less justification for skip links.

Jukka:

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

Mike:

I agree, it is a trade off and when you use the method you should
consider your audience. However, I do not agree that the title attribute
is pointless, it does help ZoomText users, and I am not sure how
"disturbing" the tool tip really is. I am currently only using this
method within an internal environment where I know that we have a
significant population of ZoomText users who depend upon ZoomText's
reader functionality and must complete the forms as part of their jobs.
Adding the titles enables them to work more efficiently.

Jukka:

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.

Mike:

The placement of the label has nothing to do with the issue. The
problem is not that users cannot find the label it is that their
assistive technology does not read the label when they tab to the input.


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

Jukka:

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

Mike:

Sorry for the misstatement, I did mean label element. The problem that
we are attempting to resolve is that of intervening text and the way in
which screen reader users navigate through forms. After entering forms
mode, the majority of users tab through the form from input to input.
When label elements are properly applied they will hear the label for
each input. However, intervening section headings, instructions or even
questions are not a part of the labels for the inputs. Thus screen
reader users miss critical information unless they exit forms mode after
each text input the use reading mode until they reach the next input.
This is inefficient and not typical user behavior.

To resolve this intervening text issue we have been experimenting with
several methods, one is to use the title attribute. However, when the
title attribute is used it is only read by JAWS, our agency standard for
screen reading, if there is not a label element associated with the form
field. We are making a trade off for the benefit of an interal
audience. We have also been experimenting with a couple of different
methods that look promising for resolving the intervening text issue
without breaking the label/input bond. These methods and their current
testing status follow:

1. Wrap the label element around all of the intervening text up to the
input and control formatting with spans.
This has been pretty ugly thus far. We loose structure because the
label element cannot contain block level elements like headings and
paragraphs. Additionally reliable cross browser formatting has proven
to be difficult. Testing with JAWS 6, JAWS 7 and JAWS 8 plus Window Eyes
has been successful.

2. Include a small, 1px, transparent gif to the label. The alt
attribute of the gif contains the intervening text. This is currently
testing well in JAWS 7 and is our most promising method to date. The
primary shortcoming with this method is the case of large blocks of
intervening text. We also had an early failure with a form where the
user was required to fill in the fields of a table.



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

Mike: Hopefully the explanation above was a little clearer.

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

Jukka:

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

Mike:

This is the primary reason that we continue to work on developing a
better method.

Jukka:

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.

Mike:

Yes, I did not include any markup that would be used to support
formatting.

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

Jukka:

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.

Mike:

I agree, fieldset and legend is ugly. Formatting is problematic, JAWS
verbosity settings may result in the legend not being read when the user
is reading in forms mode, and when JAWS reads the legend it gets
repeated for every input within the field set. Another reason for
finding a good alternative.

Mike