E-mail List Archives

Re: Guidelines for nested data tables?


From: D A
Date: Oct 23, 2009 10:50AM

> Do the child data rows produced on expanding a parent row   share the
> same column headings as the parent row?

No. An example:

Start main table:
thead: Name | Address | Zip
tr: bob | 5th ave | 5555
tr: sam | 3rd ave | 5555
tr: mary | elm st | 5555
tr (colspan 3): Start nested table of related data to mary
thead: cell | age | eyecolor | height
tr: 555-555-5555 | 24 | blue | 6

In other scenarios (different data) the nested table would have
multiple rows as well.

> Is there a mechanism (markup) by which you are conveying the relation
> between parent row and child row?

No. At the moment, that would be one of my questions for this group.
Is there a way to do that? Right now, the associated table is added to
a new TR created after the current record in the main table.

> Often in such a case,  the parent table appears to be used partly as a
> data table and partly as a layout table. This happens if parent data
> rows and child data rows have need for different column headers. Are
> there some data rows to which certain column headers do not apply?

Yes, that's a good explanation. The parent table is strictly a data
table until one expands a row (record). Once that happens, a new
'layout-only' TR is created in the parent table, and a new data table
nested within. That one TR would not actually be associated with the
THs of the parent table, as it's merely a placeholder.

> If the design becomes complex, one may need to use header-id method of
> relating data cells with header cells. That is error prone and  not a
> task one would like to do.

I really likely can't do a major change to the visual behavior. It
does make sense from a purely visual standpoint that data relating to
a record row to appear below it. I'm attempting to do what I can to
adhere to any accessibility best practices as I can in the process.
Admittedly, though, it may simply end up being considered a complex
table that won't be fully accessible.