WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Forms in Tables

for

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

From: David Ashleydale
Date: Tue, Jan 17 2012 6:33PM
Subject: Forms in Tables
No previous message | Next message →

Hi,

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?

Just looking for some opinions on the topic.

Thanks,
David Ashleydale

From: Birkir R. Gunnarsson
Date: Tue, Jan 17 2012 8:54PM
Subject: Re: Forms in Tables
← Previous message | Next message →

What about utilizing ARIA here and "hiding" the table from the user,
since it sounds like the table is merely being used for layout.
What I like about the possibilities of ARIA is that we can allow for
nice visual layout effects without adversely affecting the
accessibility of the underlying data, basically low for different
presentations.
Feel free to correctme, I may be wrong on this, butit seems to be a
sensible solution to use ARIA to hide the dta table here and just
allow the user to see the form fields.
There was an example posted on this, on this list, quite a while back.
Cheers
-B

On 1/18/12, David Ashleydale < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
>
> 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?
>
> Just looking for some opinions on the topic.
>
> Thanks,
> David Ashleydale
>

From: David Ashleydale
Date: Tue, Jan 17 2012 9:03PM
Subject: Re: Forms in Tables
← Previous message | Next message →

Hi Birkir,

That's a good suggestion, but I did specify that the table is not just
merely being used for layout -- it is a semantically correct data table.

Thanks,
David

On Tue, Jan 17, 2012 at 7:54 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> What about utilizing ARIA here and "hiding" the table from the user,
> since it sounds like the table is merely being used for layout.
> What I like about the possibilities of ARIA is that we can allow for
> nice visual layout effects without adversely affecting the
> accessibility of the underlying data, basically low for different
> presentations.
> Feel free to correctme, I may be wrong on this, butit seems to be a
> sensible solution to use ARIA to hide the dta table here and just
> allow the user to see the form fields.
> There was an example posted on this, on this list, quite a while back.
> Cheers
> -B
>
> On 1/18/12, David Ashleydale < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi,
> >
> > 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?
> >
> > Just looking for some opinions on the topic.
> >
> > Thanks,
> > David Ashleydale
> >

From: Bryan Garaventa
Date: Wed, Jan 18 2012 1:48AM
Subject: Re: Forms in Tables
← Previous message | Next message →

I don't see that it's a problem, as long as the form fields have explicit
labels. :)


----- Original Message -----
From: "David Ashleydale" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, January 17, 2012 5:33 PM
Subject: [WebAIM] Forms in Tables


> Hi,
>
> 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?
>
> Just looking for some opinions on the topic.
>
> Thanks,
> David Ashleydale
>

From: Benjamin Hawkes-Lewis
Date: Wed, Jan 18 2012 1:54AM
Subject: Re: Forms in Tables
← Previous message | Next message →

On Wed, Jan 18, 2012 at 1:33 AM, David Ashleydale < = EMAIL ADDRESS 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

From: Bourne, Sarah (ITD)
Date: Wed, Jan 18 2012 9:00AM
Subject: Re: Forms in Tables
← Previous message | Next message →

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 ADDRESS REMOVED =
http://www.mass.gov/itd


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS 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

From: Lucy Greco
Date: Wed, Jan 18 2012 2:27PM
Subject: Re: Forms in Tables
← Previous message | No next message

If your only using the table to lay out the form don't. the table as a form is ok but it should not just be a table to lay out the form. I go to a site every day ware I use a table that is a form and I don't find it hard to use. The reason for the table in this case is I am picking how many of each item I want to act on. but a table just for lay out is not worth it.

Lucy Greco
Assistive Technology Specialist
Disabled Student's Program UC Berkeley
(510) 643-7591
http://attlc.berkeley.edu
http://webaccess.berkeley.edu


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bryan Garaventa
Sent: Wednesday, January 18, 2012 12:50 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Forms in Tables

I don't see that it's a problem, as long as the form fields have explicit
labels. :)


----- Original Message -----
From: "David Ashleydale" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, January 17, 2012 5:33 PM
Subject: [WebAIM] Forms in Tables


> Hi,
>
> 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?
>
> Just looking for some opinions on the topic.
>
> Thanks,
> David Ashleydale
>