WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Forms in Tables

for

From: Benjamin Hawkes-Lewis
Date: Jan 18, 2012 1:54AM

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