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

The title for form controlls although they are all edit fields in a table
example on the page you point to does work.  I would submit however that
this is a hack and that it will not stand up to the tests in real world
since many people do not use the latest and greatest technologies to access
public services.  I have also noticed that a lot is spent here on section
508 and given the funding and impetus for this project, I can understand
that.  I would hope though that we can see some more broad implementations
of solutions to this ever present problem.

----- 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:20:48 UTC