E-mail List Archives

Re: Guidelines for nested data tables?

for

From: Sailesh Panchang
Date: Oct 23, 2009 12:25PM


> 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.
Sailesh: Precisely. This breaks the semantics of a data table. The
semantics get conveyed via presentation to sighted users: there
cannot be any markup to support this because there is a data table
with its own row/col headers in another data table. So I have seen
developers face the same problem like you: "cannot change visual
appearance but need to make it accessible". In the circumstances, I
have recommended they use header-id method and use a summary on the
table that explains functionality and structure of table for
non-visuall users.
Sailesh Panchang
On 10/23/09, D A < <EMAIL REMOVED> > wrote:
>> 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.
>

> Admittedly, though, it may simply end up being considered a complex
> table that won't be fully accessible.
>
> -Darrel
>