E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 14 (In chronological order)

From: Lee, Samson (HRSA) [C]
Date: Wed, Mar 26 2008 8:20AM
Subject: textbox in table cell
No previous message | Next message →

I have a data table, which has some textboxes like this:

<table>
<tr>
<th scope="col">Diagnosis</th>
<th scope="col">Level 1</th>
<th scope="col">Level 2</th>
<th scope="col">Level 3</th>
</tr>
<tr>
<th scope="row">Heart Disease</th>
<td><input type="text" size="3" id="tbHLevel1" /></td>
<td><input type="text" size="3" id="tbHLevel2" /></td>
<td><input type="text" size="3" id="tbHLevel3" /></td>
</tr>
<tr>
<th scope="row">Lung Disease</th>
<td><input type="text" size="3" id="tbLLevel1" /></td>
<td><input type="text" size="3" id="tbLLevel2" /></td>
<td><input type="text" size="3" id="tbLLevel3" /></td>
</tr>
...etc.
</table>

My question: <td>s are all accessible because row headers and column
headers are all set. But does this also automatically make the textboxes
inside the <td>s accessible? If not, how do correct this? Each textbox
has to be tied to two "labels" (one column header, one row header), so I
don't think I can use the <label> tag...

From: Jared Smith
Date: Wed, Mar 26 2008 10:20AM
Subject: Re: textbox in table cell
← Previous message | Next message →

On Wed, Mar 26, 2008 at 8:11 AM, Lee, Samson (HRSA) [C] < = EMAIL ADDRESS REMOVED = > wrote:
>
> Each textbox has to be tied to two "labels" (one column
> header, one row header), so I don't think I can use the
> <label> tag...

You are correct. You can't associate a form element with two separate
labels. There are two options that I can think of to address this.

You could put labels within the table cells, but hide those labels
visually in a way that a screen reader would still read them.
Something like...

<td><label for="tbHLevel1" class="hidden">Heart Disease - Level
1</label><input type="text" size="3" id="tbHLevel1" /></td>

The hidden class would apply CSS styles that hide the label visually.
Details on the CSS at
http://webaim.org/techniques/css/invisiblecontent/#hidingfromsighted

The other approach is to put the description in the the title
attribute for the input element. Most major screen readers will read
the title attribute if no label is found. This, however, is not really
optimal because it isn't really the prescribed method for labeling
elements and it may be a misuse of the title attribute to provide such
vital information.

Jared Smith
WebAIM

From: Lee, Samson (HRSA) [C]
Date: Wed, Mar 26 2008 11:00AM
Subject: Re: textbox in table cell
← Previous message | Next message →

Your latter approach (using the "title" attribute) seems quick and
easier, but it does seem like a misuse.

I guess my real question is, in the example I provided, when you are in
a table cell, don't screenreaders tell the cell's associated headers and
therefore doesn't that implicitly tell what that textbox is for? Or is
this too vague? Yes, your former approach makes it explicit and very
clear, but I want to know if this is really necessary since I have too
many textboxes to deal with.

From: Moore, Michael
Date: Wed, Mar 26 2008 11:50AM
Subject: Re: textbox in table cell
← Previous message | Next message →

"I guess my real question is, in the example I provided, when you are in
a table cell, don't screenreaders tell the cell's associated headers and
therefore doesn't that implicitly tell what that textbox is for? Or is
this too vague? Yes, your former approach makes it explicit and very
clear, but I want to know if this is really necessary since I have too
many textboxes to deal with. "

No, that functionality is disabled when the screen reader software has
been placed in the mode needed to type information into form. This
allows the software to distinguish between reading commands e.g. typing
the "h" key to get to the next heading in JAWS, or entering the first
letter of the name "harvey" in a text box. The "forms mode" of the
screen reader allows the user to tell the screen reader, "hey I need to
enter some stuff into a form", as a consequence keystrokes used to
execute keyboard navigation commands such as those needed to determine
row and column headings in a table must be disabled.

For the user to use the row and column headers to determine the inputs
it would be necessary to exit forms mode then query the software about
the headers then enter forms mode to enter the information for each
input on the form.

Failing to add labels or titles would fail to meet either section 508 or
WCAG accessibility requirements.

Mike

From: Jared Smith
Date: Wed, Mar 26 2008 12:00PM
Subject: Re: textbox in table cell
← Previous message | Next message →

On Wed, Mar 26, 2008 at 11:39 AM, Travis Roth < = EMAIL ADDRESS REMOVED = > wrote:
> As for screen readers, I can speak for JAWS. When it is in forms mode, it
> does not use cell header information in a table. When not in forms mode, and
> table navigation commands are used then JAWS will.

This is correct. JAWS and Window Eyes do not read the table headers
when navigating through the form elements in forms mode. In other
words, the table headers would only provide the necessary 'labeling'
if the user turned off forms mode, forced the screen reader to read
the cell information, then accessed the form element again to re-enter
forms mode. This is not likely to happen and certainly isn't very
accessible.

> What I am not sure about is what the JAWS behavior would be when the table
> is navigated with table navigation commands if both header cells and
> explicit labeling via the Label tag are both used.

When navigating through the table itself NOT in forms mode, the screen
reader will read the appropriate headers AND the label/title for the
form element when it is encountered. Yes, this may be a bit redundant,
but the form is almost certain to be accessed in forms mode, not in a
reading mode.

Jared Smith
WebAIM

From: Travis Roth
Date: Wed, Mar 26 2008 12:10PM
Subject: Re: textbox in table cell
← Previous message | Next message →

As for screen readers, I can speak for JAWS. When it is in forms mode, it
does not use cell header information in a table. When not in forms mode, and
table navigation commands are used then JAWS will.

What I am not sure about is what the JAWS behavior would be when the table
is navigated with table navigation commands if both header cells and
explicit labeling via the Label tag are both used.

And of course, JAWS is not the only screen reader.

From: Lee, Samson (HRSA) [C]
Date: Wed, Mar 26 2008 1:40PM
Subject: Re: textbox in table cell
← Previous message | Next message →

Okay, that's good to know. What do you think about using the title
attribute as a solution? Although it probably isn't the best solution
from the accessibility point of view, do you think that's still
acceptable?

From: Moore, Michael
Date: Wed, Mar 26 2008 2:20PM
Subject: Re: textbox in table cell
← Previous message | Next message →

Personally I prefer to use the title solution, I have not come across a
screen reader in a long time that does not announce the title by default
when there is no label defined. I think that the objections to the
solution are mainly from standardistas who view the use as inappropriate
from a web standards view. The use of the title as defined by the W3C
"This attribute offers advisory information about the element for which
it is set." source:
http://www.w3.org/TR/html401/struct/global.html#adef-title I think that
providing a description of what to put in the input would qualify as
advisory information.

m

From: Jared Smith
Date: Wed, Mar 26 2008 2:50PM
Subject: Re: textbox in table cell
← Previous message | Next message →

On Wed, Mar 26, 2008 at 2:16 PM, Moore, Michael
< = EMAIL ADDRESS REMOVED = > wrote:
> The use of the title as defined by the W3C
> "This attribute offers advisory information about the element for which
> it is set." source:
> http://www.w3.org/TR/html401/struct/global.html#adef-title I think that
> providing a description of what to put in the input would qualify as
> advisory information.

To play devil's advocate a bit - if the information provided in the
title attribute is *necessary* to ensure accessibility, then is it
really "advisory"? You wouldn't want to use title to provide vital or
required information or content. It should be reserved for
supplementary information.

Now in this case, because the table headers already provides the
information, but not necessarily in a way that is friendly to screen
readers, then you could certainly argue that repeating that
information in the title attribute is indeed advisory.

And to clarify, the only cases where most screen readers will read the
title attribute by default is for form elements that have no labels
and for frames.

Like many things in accessibility, there really isn't a right answer.
Title works in this case and provides the necessary accessibility. If
you think that this is a misuse of the title attribute and actually
care about such things, then hidden labels might be the better option.

Jared Smith
WebAIM

From: Jukka K. Korpela
Date: Wed, Mar 26 2008 3:30PM
Subject: Re: textbox in table cell
← Previous message | Next message →

Lee, Samson (HRSA) [C] wrote:

> I have a data table, which has some textboxes like this:

As usual, a URL would make the situation clearer, but it seems that this
a problem that has been discussed a few times. You have table of input
fields (it's often radio buttons, but here text fields) so that the
meaning of each field is to be inferred from the column and row headers.

It's this basic structure that creates accessibility problems. Even if
you could make speech browsers read those headers for each field, what
about the over 99% of users who use "normal" browsing?

> <tr>
> <th scope="row">Heart Disease</th>
> <td><input type="text" size="3" id="tbHLevel1" /></td>
> <td><input type="text" size="3" id="tbHLevel2" /></td>
> <td><input type="text" size="3" id="tbHLevel3" /></td>
> </tr>

This isn't accessible, even if you have column headers so that a small
fraction of users will hear or see the association. Just put labels for
each field there, together with <label> markup. Better still, modify the
structure so that you have one label and its field on one line. For
example, using

<fieldset><legend>Heart Disease</legend>
<div><label ...>...</label> <input ...></div>
...
</fieldset>

or perhaps a two column table inside the fieldset.

> My question: <td>s are all accessible because row headers and column
> headers are all set.

No they aren't. Such association would benefit a tiny fraction of users
only. It would be useful to have the association, of course, _if_ you
_had_ to have the table structure you have. But you don't.

It's essential to realize that web forms are not paper forms and should
not imitate them and should not be written compactly to save paper,
since no paper is involved. One item per line is fine.

Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

From: Moore, Michael
Date: Wed, Mar 26 2008 3:40PM
Subject: Re: textbox in table cell
← Previous message | Next message →

From: James Nurthen
Date: Wed, Mar 26 2008 6:50PM
Subject: Re: textbox in table cell
← Previous message | Next message →

Indeed the title solution for such cases is documented in the current
draft of the techniques document for WCAG2.0
http://www.w3.org/TR/WCAG20-TECHS/H65.html

Regards,
James

On Wed, Mar 26, 2008 at 1:16 PM, Moore, Michael
< = EMAIL ADDRESS REMOVED = > wrote:
> Personally I prefer to use the title solution, I have not come across a
> screen reader in a long time that does not announce the title by default
> when there is no label defined. I think that the objections to the
> solution are mainly from standardistas who view the use as inappropriate
> from a web standards view. The use of the title as defined by the W3C
> "This attribute offers advisory information about the element for which
> it is set." source:
> http://www.w3.org/TR/html401/struct/global.html#adef-title I think that
> providing a description of what to put in the input would qualify as
> advisory information.
>
>
> m
>
>

From: Chris Hoffman
Date: Wed, Mar 26 2008 8:30PM
Subject: Re: textbox in table cell
← Previous message | Next message →

On Wed, 2008-03-26 at 10:17 -0600, Jared Smith wrote:
> On Wed, Mar 26, 2008 at 8:11 AM, Lee, Samson (HRSA) [C] < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Each textbox has to be tied to two "labels" (one column
> > header, one row header), so I don't think I can use the
> > <label> tag...
>
> You are correct. You can't associate a form element with two separate
> labels.

Is that a limitation of the assistive technologies' capabilities?
Because it certainly isn't a violation of the HTML4 spec:

"Each LABEL element is associated with exactly one form control."

but:

"More than one LABEL may be associated with the same control by creating
multiple references via the for attribute."

(http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1)

--Chris

From: Patrick H. Lauke
Date: Wed, Mar 26 2008 8:40PM
Subject: Re: textbox in table cell
← Previous message | No next message

Chris Hoffman wrote:

> Is that a limitation of the assistive technologies' capabilities?
> Because it certainly isn't a violation of the HTML4 spec:
>
> "Each LABEL element is associated with exactly one form control."
>
> but:
>
> "More than one LABEL may be associated with the same control by creating
> multiple references via the for attribute."
>
> (http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1)

I'd say it's a limitation of current AT...to a certain extent, as the
spec doesn't actually clarify the use cases for multiple labels. Does it
allow multiple labels under the tacit understanding that those labels
would really all mean the same thing, or does it intend to offer a
mechanism for situations like the one discussed here? It's unclear...and
therefore AT is inconsistent in that regard.

The info may not be the most up-to-date, but worth having a look at
http://www.access-matters.com/2005/09/10/speaking-form-labels-summary/#mult

--
Patrick H. Lauke
______________________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________
_______________________________________________
To manage your subscription, visit http://list.webaim.org/
Address list messages to = EMAIL ADDRESS REMOVED =