WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: form label question

for

From: Steve Green
Date: Aug 8, 2007 8:20AM

That's interesting Mike. A ZoomText user I have worked with has the opposite
opinion, and finds the tooltips associated with 'title' attributes to be
annoying because they cover a lot of the screen. It can be difficult to get
rid of them if you don't know which element they are associated with.

Whether they are a benefit or a hindrance probably depends on the
magnification level (he uses x4) and whether speech is enabled (he only uses
it for long blocks of text).

Steve Green
Director
Test Partners Ltd / First Accessibility
www.testpartners.co.uk
www.accessibility.co.uk



-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Moore, Michael
Sent: 08 August 2007 14:46
To: WebAIM Discussion List
Subject: Re: [WebAIM] form label question

On Wed, 8 Aug 2007, Kathleen Ballard wrote:

> Also, a recent webinar mentioned using the alt or title attribute of
> the form control itself.

Jukka replied:

That's pointless or worse. If you have good labels, nobody needs such
attributes. If you don't, most people won't perceive any labels.

Mike Moore's response:

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. We have tested this using the most recent versions, ZoomText
9.0 and ZoomText 9.1. The reader in ZoomText will report the title. Thus
adding a title that matches the label does add value for at least one group
of users.

JAWS will also reliably report the content of the title attribute if the
label attribute is missing 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. 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 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.

There are also disadvantages to this method:
1. It is not proper semantic structural markup (Web Standards issue) 2. Form
inputs with only the title defined will fail automated accessibility
testers.
3. It has only been confirmed to work with JAWS 6.1 and above. We have not
tested with other screen readers.
4. There are character limits governing how much text will be read from a
title attribute.

We are also beginning some experiments with using 1px transparent gifs with
the alt attribute defined within the label element to resolve the
intervening text (Instructions/questions covering groups of inputs) issue
for JAWS users. I will let everyone know how those experiments come out the
next time this issue is raised on this list.

m