E-mail List Archives
Thread: form label question
Number of posts in this thread: 18 (In chronological order)
From: Kathleen Ballard
Date: Wed, Aug 08 2007 5:10AM
Subject: form label question
No previous message | Next message →
Dear list,
I understand the need for using <label> tags for form
controls.
Is using display: block to hide the labels and keep
them available for screen readers a safe/accepted
practice?
Also, a recent webinar mentioned using the alt or
title attribute of the form control itself. This
would actually allowed giving the screen reader user
better infromation about the form control. Ex:
alt="Enter First Name required"
Are both <label> and alt preferred? Or should one be
chosen over the the other?
Thank you for your time,
Kathleen
From: Jukka K. Korpela
Date: Wed, Aug 08 2007 5:50AM
Subject: Re: form label question
← Previous message | Next message →
On Wed, 8 Aug 2007, Kathleen Ballard wrote:
> Is using display: block to hide the labels and keep
> them available for screen readers a safe/accepted
> practice?
No, because labels and associated markup help far more people than just
screen reader users. Everyone, and especially many cognitively disabled
people, need well-written labels so that they know the meaning of each
field.
I wonder how you expect display: block to hide anything.
> Also, a recent webinar mentioned using the alt or
> title attribute of the form control itself.
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.
> This
> would actually allowed giving the screen reader user
> better infromation about the form control. Ex:
> alt="Enter First Name required"
You must have confused attributes with each other. No form field except
image submit button may have an alt attribute, by HTML rules. You probably
mean the title attribute.
> Are both <label> and alt preferred? Or should one be
> chosen over the the other?
Use good label texts and <label> markup to associate them with fields.
That's it. No hassling around with fancy attributes.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Kathleen Ballard
Date: Wed, Aug 08 2007 6:10AM
Subject: Re: form label question
← Previous message | Next message →
Jukka,
Sorry, yes, display:block should have been
display:none. I guess I was typing too early in the
morning.
Unfortunately, for the current project, I have the
requirement for a small login form and search form on
each page that do not allow for visible labels in the
layout. The value of the textboxes when the page is
loaded will be the only visual cue to the user on the
form field functionality. ("Search site here")
Thank you for pointing out that title is the correct
attribute. The speaker used both alt and title and I
was not clear on which was the correct term.
Kathleen
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On
Behalf Of Jukka K. Korpela
Sent: Wednesday, August 08, 2007 7:47 AM
To: = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List
Subject: Re: [WebAIM] form label question
On Wed, 8 Aug 2007, Kathleen Ballard wrote:
> Is using display: block to hide the labels and keep
> them available for screen readers a safe/accepted
> practice?
No, because labels and associated markup help far more
people than just
screen reader users. Everyone, and especially many
cognitively disabled
people, need well-written labels so that they know the
meaning of each
field.
I wonder how you expect display: block to hide
anything.
> Also, a recent webinar mentioned using the alt or
> title attribute of the form control itself.
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.
> This
> would actually allowed giving the screen reader user
> better infromation about the form control. Ex:
> alt="Enter First Name required"
You must have confused attributes with each other. No
form field except
image submit button may have an alt attribute, by HTML
rules. You probably
mean the title attribute.
> Are both <label> and alt preferred? Or should one
be
> chosen over the the other?
Use good label texts and <label> markup to associate
them with fields.
That's it. No hassling around with fancy attributes.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Tim Harshbarger
Date: Wed, Aug 08 2007 6:30AM
Subject: Re: form label question
← Previous message | Next message →
Kathleen,
Unfortunately, "display: none" hides labels from screen readers. If you
want to hide a label using CSS, there are other methods that do work
better. When I have to hide a label, the method I most frequently use
involves moving the label element off the page by setting the "left" CSS
property to a negative number.
Looking at something I recently did, here is a class I set up to hide
some elements--although they were not labels for form controls.
.accessible-header {
position: absolute;
left: -32767;
}
It is also possible to use the "title" attribute of a form control. I
don't use the "alt" attribute, but mainly because I believe it isn't a
valid attribute for most form controls and I run most of my HTML through
a validator.
My preference is to use the label element rather than the title
attribute. I have 3 reasons for my choice. First, visible labels are
clickable and will cause focus to move to the related form control. If
someone has to use the mouse, I like to make it as easy as possible for
them to select the control they want. Secondly, the label element just
seems more semantically correct to me. Lastly, Internet Explorer
displays tooltips for elements that have "title" attributes and some of
the project teams I work with seem to feel that negatively impacts the
user's experience with the interface.
Tim
From: Moore, Michael
Date: Wed, Aug 08 2007 7:50AM
Subject: Re: form label question
← Previous message | Next message →
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
From: Steve Green
Date: Wed, Aug 08 2007 8:20AM
Subject: Re: form label question
← Previous message | Next message →
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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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
From: Jared Smith
Date: Wed, Aug 08 2007 8:30AM
Subject: Re: form label question
← Previous message | Next message →
On 8/8/07, Kathleen Ballard < = EMAIL ADDRESS REMOVED = > wrote:
> Unfortunately, for the current project, I have the
> requirement for a small login form and search form on
> each page that do not allow for visible labels in the
> layout. The value of the textboxes when the page is
> loaded will be the only visual cue to the user on the
> form field functionality. ("Search site here")
Form labels should almost always be visible as they provide useful
information for visual users and they provide a larger clickable area
(if you click on the label text, the form element receives focus).
Your case *might* be one in which the label could be hidden visually,
but in a manner that it is still read by screen readers. This article
- http://webaim.org/techniques/css/invisiblecontent/ - outlines our
preferred method for doing this, as well as some additional issues and
concerns.
However, in order for this to be useful, it must be obvious to visual
users what the box is for. If, as you indicate, the default value of
the text box is the only indication, this is probably not sufficient.
If scripting is used to either write and/or make this default text
disappear when you click in the box, then this will not work in many
situations. Also, non-visual users may enter their search term into
the text box *in addition to* the default text. But, if the submit
button (and I do assume there is one) clearly indicates that the
adjacent text box is for searching, this should provide the adequate
visible cue. When coupled with a hidden label for screen reader users,
this should be sufficient.
<label for="search" class="hidden">Search terms:</label>
<input type="text" id="search" name="search" />
<input type="submit" value="Search" />
... where class="hidden" references the CSS to hide the label. You can
see this approach in action on the WebAIM site.
Jared Smith
WebAIM
From: Moore, Michael
Date: Wed, Aug 08 2007 8:40AM
Subject: Re: form label question
← Previous message | Next message →
Steve Green wrote:
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).
Mike's response
You are right, it is always a balancing act. We have over 200 ZoomText
and Jaws users within our agency and we have to work hard to balance
things between the needs of users who use JAWS for screen reading, those
who use ZoomText for screen reading, and those who use ZoomText for
screen magnification only. Since it is relatively easy to move the
mouse away from the input causing the tool tip pop out in IE when titles
are used, we have chosen to use the title to support those who depend
upon the ZoomText reader. This decision was made after user testing
with many assistive technology users and the reccommendation of our
Accessibility Users Group, which is a standing committee of assistive
technology users, trainers, and technology experts.
Mike
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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
From: Michael D. Roush
Date: Wed, Aug 08 2007 9:10AM
Subject: Re: form label question: side note
← Previous message | Next message →
Steve Green wrote:
> 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.
A bit of a side note here: That would be a nice feature I would like to
see incorporated into IE - a way to turn "tool tips" on/off via a
checkbox, instead of having to go into the system registry (or use
another third-party program that changes the registry) to do it. That
could be very useful for people using magnifiers, or people who just
don't want the things popping up.
Michael
From: Jukka K. Korpela
Date: Thu, Aug 09 2007 2:20PM
Subject: Re: form label question
← Previous message | Next message →
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/
From: Moore, Michael
Date: Thu, Aug 09 2007 3:50PM
Subject: Re: form label question
← Previous message | Next message →
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
From: John Foliot - Stanford Online Accessibility Program
Date: Thu, Aug 09 2007 5:20PM
Subject: Re: form label question
← Previous message | Next message →
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
From: Sawang Srisom
Date: Thu, Aug 09 2007 8:00PM
Subject: Re: form label question
← Previous message | Next message →
Dear all,
No matter what we are saying, I insist that LABEL is very important--not
only for blind users but also sighted ones. The point is that it just tells
us what to fill in. Please keep it simple! Don't make it complicated!
Below is the sample of how to handle with radio buttons and labels:
<p>
<label for="gender1 gender2">Gender</label>
<input type="radio" name="gender" id="gender1" value="Male"
checked="checked" /> Male<br />
<input type="radio" name="gender" id="gender2" value="Female"
checked="checked" /> Female
</p>
I'm not so sure if this sample is syntactically correct, but there is no
error returned when I validate the page with this code.
Sawang Srisom
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jukka K. Korpela
Sent: Friday, August 10, 2007 3:14 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] form label question
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/
From: Jared Smith
Date: Thu, Aug 09 2007 11:00PM
Subject: Re: form label question
← Previous message | Next message →
On 8/9/07, Sawang Srisom wrote:
> <label for="gender1 gender2">Gender</label>
> <input type="radio" name="gender" id="gender1" value="Male"
> checked="checked" /> Male<br />
> <input type="radio" name="gender" id="gender2" value="Female"
> checked="checked" /> Female
In this case, "Male" and "Female" should be the labels for their
appropriate radio buttons. "Gender" should not be marked up as a
label. It could and probably should, however, be a legend for a
fieldset that surrounds the two radio buttons.
Examples and proper coding at http://webaim.org/techniques/forms/controls.php
I think what we're all saying is that labels are necessary for
accessibility. There are few cases when they might pose design and
usability issues and in those cases, it must be visually and
programmatically (through title, row/column headers, etc.) apparent
what the function of the form element is.
Jared Smith
WebAIM
From: Jukka K. Korpela
Date: Fri, Aug 10 2007 12:30AM
Subject: Re: form label question
← Previous message | Next message →
On Fri, 10 Aug 2007, Sawang Srisom wrote:
> No matter what we are saying, I insist that LABEL is very important--not
> only for blind users but also sighted ones. The point is that it just tells
> us what to fill in.
There are two issues: the label text, and the <label> markup that
associates the label text with the field. They are both important.
> Please keep it simple! Don't make it complicated!
Here the principle "as simple as possible, but not simpler" is
particularly important.
> Below is the sample of how to handle with radio buttons and labels:
>
> <p>
> <label for="gender1 gender2">Gender</label>
> <input type="radio" name="gender" id="gender1" value="Male"
> checked="checked" /> Male<br />
> <input type="radio" name="gender" id="gender2" value="Female"
> checked="checked" /> Female
> </p>
>
> I'm not so sure if this sample is syntactically correct,
I know that it is not.
> but there is no
> error returned when I validate the page with this code.
Then you made an error of some kind or used a phoney validator.
The markup is invalid, and validator issues an error message like
"Error: value of attribute for must be a single token"
since the for attribute is declared as having an IDREF value. This is
natural because it is semantically defined as referring to a single
element by its id attribute value. Pragmatically, if it were allowed to
use two identifiers there, which of the radio buttons should be checked
when the label is clicked on? I'm referring to the common accessibility
feature in modern browsers: when you click on a label, the corresponding
field gets "activated".
The words "Male" and "Female" should both be made labels, for the
corresponding fields. It is less relevant what markup you use for the
question that they relate to. You could put the word "Gender" (or, more
accessibly, "Sex") inside <fieldset> markup, or make it a heading, or just
a <div>, or even (illogically) a <p>; but that's not a big problem.
(And there should be a "neutral" alternative, such as "Do not want to
tell", or maybe several neutral alternatives, including "Not answered
yet", and one of the alternatives should be initially selected. Of course
the trivial set of alternatives discussed here is just an example, but
it's really a _bad_ example, since it's too trivial. For an explanation of
this, see http://www.cs.tut.fi/~jkorpela/forms/choices.html )
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Moore, Michael
Date: Fri, Aug 10 2007 9:20AM
Subject: Re: form label question
← Previous message | Next message →
On 8/9/07, Sawang Srisom wrote:
> <label for="gender1 gender2">Gender</label> <input type="radio"
> name="gender" id="gender1" value="Male"
> checked="checked" /> Male<br />
> <input type="radio" name="gender" id="gender2" value="Female"
> checked="checked" /> Female
Jared:
In this case, "Male" and "Female" should be the labels for their
appropriate radio buttons. "Gender" should not be marked up as a label.
It could and probably should, however, be a legend for a fieldset that
surrounds the two radio buttons.
Examples and proper coding at
http://webaim.org/techniques/forms/controls.php
I think what we're all saying is that labels are necessary for
accessibility. There are few cases when they might pose design and
usability issues and in those cases, it must be visually and
programmatically (through title, row/column headers, etc.) apparent what
the function of the form element is.
Mike's response:
Try testing this
<span class="question">Gender</span>
<div class="radioInput"><input type="radio" name="gender" id="gender1"
value="Male" />
<label for="gender1"><img src="hidden.gif" alt="gender" height="1"
width="1">Male</label></div>
<div class="radioInput"><input type="radio" name="gender" id="gender2"
value="Female" />
<label for="gender2">Female</label></div>
You will need to create your own styles for the classes, and a 1px clear
gif.
This method has now been tested with JAWS 6, JAWS 7, and JAWS 8. Window
Eyes testing to be done early next week. It has the following advantages
over fieldsets/legends:
1. Better formatting of questions over the use of fieldsets/legends,
particularly for long questions.
2. Better reporting of questions by JAWS over the use of fieldsets. The
jury is still out on Window Eyes but I don't see why it wouldn't work.
Overriding reading of fieldset legends does not result in no reading of
the questions.
3. Better usability for JAWS users because the do not have to listen to
the question again for each answer selection. This assessment is based
upon feedback from several dozen JAWS users and complaints about JAWS
rereading questions placed in fieldset labels from an even larger set of
users.
I would appreciate it if someone could provide results of testing with
other screen readers.
Mike
From: Jon Gunderson
Date: Fri, Aug 10 2007 12:00PM
Subject: Re: form label question
← Previous message | Next message →
You can use the Firefox Accessibility Extension to test form controls for proper labeling with the Firefox Browser.
http://firefox.cita.uiuc.edu
Jon
---- Original message ----
>Date: Thu, 9 Aug 2007 22:55:21 -0600
>From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] form label question
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>
>On 8/9/07, Sawang Srisom wrote:
>
>> <label for="gender1 gender2">Gender</label>
>> <input type="radio" name="gender" id="gender1" value="Male"
>> checked="checked" /> Male<br />
>> <input type="radio" name="gender" id="gender2" value="Female"
>> checked="checked" /> Female
>
>In this case, "Male" and "Female" should be the labels for their
>appropriate radio buttons. "Gender" should not be marked up as a
>label. It could and probably should, however, be a legend for a
>fieldset that surrounds the two radio buttons.
>
>Examples and proper coding at http://webaim.org/techniques/forms/controls.php
>
>I think what we're all saying is that labels are necessary for
>accessibility. There are few cases when they might pose design and
>usability issues and in those cases, it must be visually and
>programmatically (through title, row/column headers, etc.) apparent
>what the function of the form element is.
>
>Jared Smith
>WebAIM
>
From: Sawang Srisom
Date: Tue, Aug 21 2007 8:10PM
Subject: Re: form label question
← Previous message | No next message
Dear all,
Does anyone here happen to know any accessible content management system
(CMS)? I've been searching for it for weeks but cannot really find a good
one.
Best regards,
Sawang Srisom
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jon Gunderson
Sent: Saturday, August 11, 2007 12:58 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] form label question
You can use the Firefox Accessibility Extension to test form controls for
proper labeling with the Firefox Browser.
http://firefox.cita.uiuc.edu
Jon
---- Original message ----
>Date: Thu, 9 Aug 2007 22:55:21 -0600
>From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] form label question
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>
>On 8/9/07, Sawang Srisom wrote:
>
>> <label for="gender1 gender2">Gender</label>
>> <input type="radio" name="gender" id="gender1" value="Male"
>> checked="checked" /> Male<br />
>> <input type="radio" name="gender" id="gender2" value="Female"
>> checked="checked" /> Female
>
>In this case, "Male" and "Female" should be the labels for their
>appropriate radio buttons. "Gender" should not be marked up as a
>label. It could and probably should, however, be a legend for a
>fieldset that surrounds the two radio buttons.
>
>Examples and proper coding at
http://webaim.org/techniques/forms/controls.php
>
>I think what we're all saying is that labels are necessary for
>accessibility. There are few cases when they might pose design and
>usability issues and in those cases, it must be visually and
>programmatically (through title, row/column headers, etc.) apparent
>what the function of the form element is.
>
>Jared Smith
>WebAIM
>