E-mail List Archives

Re: Forms in Tables

for

From: Bourne, Sarah (ITD)
Date: Jan 18, 2012 9:00AM


It has long been a pet peeve of mine that AT does not have better support for data tables that have interactive elements (i.e., form fields.) The semantics are already there, but we have to add redundant code for them to be properly announced. It is this failing that makes online calendars and time sheets, for two obvious examples, so difficult for screen reader accessibility.

Aria-labelledby (as illustrated in Benjamin's post) is often the tidiest, and easiest to implement for dynamic applications.

If you need to support AT versions without ARIA, another option is to use TITLE attributes on the form fields. This is a WCAG2 technique (H65: Using the title attribute to identify form controls when the label element cannot be used, http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H65.) In this case, you would often be repeating the text that aria-labelledby would be determining for you.

<textarea
name="attendee-284894-notes"
title="Attendee notes for John Doe">

sb

Sarah E. Bourne
Director of Assistive Technology &
Mass.Gov Chief Technology Strategist
Information Technology Division
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
<EMAIL REMOVED>
http://www.mass.gov/itd


-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Benjamin Hawkes-Lewis
Sent: Wednesday, January 18, 2012 3:53 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Forms in Tables

On Wed, Jan 18, 2012 at 1:33 AM, David Ashleydale < <EMAIL REMOVED> > wrote:
> I was wondering if this group is of the general opinion that form
> fields should be kept out of data tables in HTML. Using assistive
> technology to navigate a data table is one thing, and using assistive
> technology to navigate a form is another. Should trying to combine the two be discouraged?
>
> Visual designers like to line everything up and to conserve space on a
> page by using tables, so it's difficult to discourage them from doing
> so. And I'm talking about legitimate data tables here, not simply
> using the table element as a layout device. Picture a data table that
> users can "act on", like maybe a "Notes" input field at the end of each row.
>
> My gut reaction is to tell the design team to keep tables and forms
> separate, but would that be going too far? Would it be too strict (and
> unnecessary) of a requirement to tell them *never* to do so?

I think it would be unnecessary.

It's worth distinguishing between two cases.

In the first case, you model this interface as a table with editable cells that are independent forms:

<table>
<caption>Attendees</caption>
<tr>
<th>ID</th>
<th>Name</th>
<th id="notes-header">Notes</th>
</tr>
<tr>
<td>284894</td>
<td>John Doe</td>
<td>
<form action=" " method="POST">
<textarea
name="attendee-284894-notes"
aria-labelledby="notes-header">
<input type="submit" value="Update">
</form>
</td>
</tr>
</table>

In the second case, you model this interface as a single form containing a data table:

<h1 id="page-title">Attendees</h1>
<form action=" " method="POST" aria-labelledby="page-title">
<table aria-labelledby="page-title">
<tr>
<th>ID</th>
<th>Name</th>
<th id="notes-header">Notes</th>
</tr>
<tr>
<td>284894</td>
<td>John Doe</td>
<td>
<textarea
name="attendee-284894-notes"
aria-labelledby="notes-header">
</td>
</tr>
</table>
<input type="submit" value="Update">
</form>

NB This markup relies on aria-labelledby support. Using @title or a <label> element positioned off-screen are good alternatives if you're aiming to support legacy user setups.

Both markup models are logical. However, in the second case, when users have restricted, impaired, or no sight and are using an interaction method that moves them between controls (such as "forms mode" in some screen readers), there's a real risk they will miss the parts of the table which are not controls nor explicitly associated with a control as a label or description.

There are various approaches to this problem.

Perhaps the simplest one is to add more information to the field label:

<tr>
<td id="attendee-284894-id">284894</td>
<td id="attendee-284894-name">John Doe</td>
<td>
<textarea
name="attendee-284894-notes"
aria-labelledby="
attendee-284894-id
attendee-284894-name
notes-header">
</td>
</tr>

The tradeoff here is that users who are listening to the page and are not using an interaction method that skips from control to control but instead consumes interleaved contents will hear information twice. A possible advantageous byproduct is that interfaces that present the user with a list of controls on the page will usefully differentiate between the same control on different rows.

A second approach is to turn the non-editable data cells into read-only controls:

<tr>
<th id="id-header">ID</th>
<th id="name-header">Name</th>
<th id="notes-header">Notes</th>
</tr>
<tr>
<td>
<input readonly value="284894" aria-labelledby="id-header">
</td>
<td>
<input readonly value="John Doe" aria-labelledby="id-name">
<td>
<textarea
name="attendee-284894-notes"
aria-labelledby="notes-header">
</td>
</tr>

A tradeoff here is that these non-editable data cells are in the tab order, which makes for wasted keyboarding by users who have a gestalt view of the table.

A third approach is to begin with the first model (editable forms are individual cells) and progressively enhance when JS is available by removing the individual submit buttons, adding a single submit button after the table, and submitting all the forms as a single data set if any individual form is submitted or the submit button is pressed.

I'm sure there are further approaches, but this gives you some idea of the possibilities.

--
Benjamin Hawkes-Lewis