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

Hi Mat,

I think using title elements isn't a strict violation of the 
guidelines, since the attribute is indeed there to provide information 
about the element it is part of, but it isn't as helpful as having a 
real label (Screen reader users aren't the only people who don't find 
forms intuitively clear, and I say this as a customer of Telstra).

Similarly I think that table headers are not a strict violation of the 
guidelines. (I think I may have said something different in the past). 
They are an explicit label for all the cells in their scope, which 
would include form controls. As someone said you can't put a label 
element around a table row, but it isn't incorrect in HTML to have 
several labels all pointing to the same control. So you could have the 
contents of each cell in a row be a label for a checkbox, but I don't 
know if browsers really handle this cleanly (I'd love to discover they 
do, of course).

Cheers

Chaals

On Friday, May 30, 2003, at 04:22 Europe/Zurich, Jim Thatcher wrote:

>
> 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 01:42:00 UTC