Re: labels for form controls that don't have labels.

The bit of code that follows does not work for me in jaws 4.51 with ie6 on
xp home with all updates and patches and the settings that matter at factory
defaults.  I have included the explanatory material for reference.

"Figure 8.4 Image button with equivalent alt text

The BUTTON element is a container that allows both images and text on a
button. Images must have alt text as we discussed in Section 2. The
following is
an example.

<BUTTON name="submit" type="submit">
<STRONG>Go</STRONG>
<IMG src="nextarrow.gif" border="0" alt="Next page">
</BUTTON>

Go
Next page
When the text carries the message of the button there is no need to also
have alternative text on the image. In the example above, alt="next page" is
used
so the text on the button for assistive technology would be "go next page."

When a button has focus, assistive technology knows to announce the content
of that button including alternative text on images."
----- Original Message ----- 
From: "Jim Thatcher" <jim@jimthatcher.com>
To: "'Mirabella, Mathew J'" <Mathew.Mirabella@team.telstra.com>;
"'w3c-wai-ig list'" <w3c-wai-ig@w3.org>
Sent: Thursday, May 29, 2003 10:22 PM
Subject: RE: labels for form controls that don't have labels.



Hi Mirabella,

The answer (see http://jimthatcher.com/webcourse8.htm#webcourse8.6) is the
title attribute on the input element. The only (good) reason for using the
title element on a form control is when other information, like position
(zip+4, telephone number, or a table) is telling a sighted user what to
enter. JAWS, Window-Eyes and HPR will speak the title attribute of a form
control.

Jim
508 Web Accessibility Tutorial http://jimthatcher.com/webcourse1.htm.
"Constructing Accessible Web Sites:"  http://jimthatcher.com/news.htm

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On Behalf
Of Mirabella, Mathew J
Sent: Tuesday, May 27, 2003 10:49 PM
To: w3c-wai-ig list
Subject: labels for form controls that don't have labels.


All.

Thanks all for the discussion on the css instead of JavaScript issue.  I
have another issue for discussion...

I am trying to find a way to make form controls accessible to screen reader
users where the form control is one that ordinarily does not have an
on-screen label, and cannot have one due to design constraints.  Some
examples are:

1.  a checkbox that relates to an entire table row in a data table, the
checking of which relates to the selection of a particular set of data in
the table.  i.e. the checkbox is the leftmost cell on the row, but the row
consists of data that comes under the column headings such as date, phone
number, time, cost, etc.  Also other examples may be a set of radio buttons,
one per row.  One solution is to put label element tags around the whole row
and use appropriate for and id attributes.  But the reading of an entire row
may be confusing to some users.

2.  A series of edit fields designed to take parts of a phone number.  I.e.
country code, area code and number are separate, but the only on-screen
label is the one for the entire set.  One solution is to use invisible text
labels (see below).

3.  a series of form controls in different cells of the same row of a table
where the table is a data table, but certain values need to be altered or
set on submitting the form.  One solution is to code the label around the
form field itself or else a particular cell that best represents it.

However, for all these examples, it is difficult to use label elements for
each form control including a text label where there is no logical room for
one on the screen.  I have looked at the following solutions:
1.  use visibility: hidden or display: none; for a span that covers the
contents of the label , thus allowing a descriptive label to be included but
not appearing on the screen.  Some z-index and positioning styles may be
required here as well.  .  However, new screen readers such as jaws 4.5x are
now treating invisible text properly and not reading it.
2.  Using title attributes for the input elements and not having labels at
all.  but this violates the guidelines.
3.  Including label, but only to surround the form control itself, but not
to include any real other label element content.  Rather, include title
attributes on both the label and input element as required.  This seems the
best solution at the moment.  But it still does not involve label content
and the behaviour may be somewhat dubious with some screen readers.

Any other notes or ideas or discussion is welcome.

Regards.

Mat.

Received on Friday, 30 May 2003 08:10:36 UTC