E-mail List Archives
Thread: Guidelines for nested data tables?
Number of posts in this thread: 10 (In chronological order)
From: D A
Date: Wed, Oct 21 2009 9:50AM
Subject: Guidelines for nested data tables?
No previous message | Next message →
I'm working on an interface that will consist of a data table with
each row being expandable to show more details of that particular
record. The details would then be formatted in their own table.
This seems like a common need, but I haven't found too much that
addresses it specifically.
Is it fine to add a blank TR to the parent Table to insert the nested
table within? Are there any issues/guidelines in regards to nesting
data tables?
-Darrel
From: Steve Green
Date: Wed, Oct 21 2009 6:00PM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
From: Jon Gunderson
Date: Thu, Oct 22 2009 7:05AM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
Sounds like an ARIA Tree Grid:
Resources:
http://www.w3.org/TR/wai-aria/#treegrid
http://dev.aol.com/dhtml_style_guide#grid
http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases#Treegrid
Jon
---- Original message ----
>Date: Thu, 22 Oct 2009 00:59:51 +0100
>From: "Steve Green" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Guidelines for nested data tables?
>To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
>
>
From: D A
Date: Thu, Oct 22 2009 10:20AM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
> I would have thought that you should construct the whole table with all the
> rows that are to be hidden, then use DOM scripting to hide them. That way
> the content is all available to people who do not have JavaScript.
In this case, we're loading the 'parent table'.
Each row (record) of the parent table will then be expandable, where
more data relating to that record will be loaded via an ajax call.
> Can you not come up with an alternate construction, such as linking to
> additional data tables rather than using hide/reveal? Maybe you can't, but I
> would definitely look for alternatives if possible.
I'm definitely interested in the alternatives. In this particular
case, however, I'm not building the system. So I have to work within
the already established wireframes. I'm striving to make them as
accessible as I can up front, though realize there will be compromises
at this point.
> In general, hide/reveal functionality can cause significant difficulty for
> screen reader users if you are not careful to control the location of the
> focus after each operation.
Ah! Good tip in moving the focus. That should be something I should be
able to do fairly easily within the framework we're building upon.
By initial thought was a structure like this:
table
tr
td (data)
td (data)
td (data)
tr
td colspan=3 (to hold sub-table)
sub-table would go here
-Darrel
From: D A
Date: Thu, Oct 22 2009 10:30AM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
> Sounds like an ARIA Tree Grid:
>
> Resources:
> http://www.w3.org/TR/wai-aria/#treegrid
> http://dev.aol.com/dhtml_style_guide#grid
> http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases#Treegrid
Looking at this:
http://codetalks.org/source/widgets/treegrid/treegrid.sample2.html
I'd say yes. Sort of. ;)
In this case, table would look like this:
head1, head2, head3
data1, data2, data3
data1, data2, data3
---
sub Table head 1, sub Table head 2, sub Table head 3
sub table data 1, sub table data 2, sub table data 3
sub table data 1, sub table data 2, sub table data 3
---
data1, data2, data3
data1, data2, data3
The sub table may or may not have the same number of columns so seems
best served as a separate table.
-Darrel
From: Wendy Chisholm
Date: Thu, Oct 22 2009 12:20PM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
The most reliable method I've found to associate a data cell with a
heading is to use the headers and id attributes
(http://sp1ral.com/tests/flood-data-final.html). I have not tested
associating a data cell in an inner (nested) table with a heading in
an outer table. It would be an interesting test. Do you have an
example of the tables/data you are marking up? I'd love to hear how
Jaws, WindowEyes, and NVDA handle that type of relationship.
--w
On Thu, Oct 22, 2009 at 9:27 AM, D A < = EMAIL ADDRESS REMOVED = > wrote:
>> Sounds like an ARIA Tree Grid:
>>
>> Resources:
>> http://www.w3.org/TR/wai-aria/#treegrid
>> http://dev.aol.com/dhtml_style_guide#grid
>> http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases#Treegrid
>
> Looking at this:
>
> http://codetalks.org/source/widgets/treegrid/treegrid.sample2.html
>
> I'd say yes. Sort of. ;)
>
> In this case, table would look like this:
>
> head1, head2, head3
> data1, data2, data3
> data1, data2, data3
> ---
> sub Table head 1, sub Table head 2, sub Table head 3
> sub table data 1, sub table data 2, sub table data 3
> sub table data 1, sub table data 2, sub table data 3
> ---
> data1, data2, data3
> data1, data2, data3
>
> The sub table may or may not have the same number of columns so seems
> best served as a separate table.
>
> -Darrel
>
From: D A
Date: Thu, Oct 22 2009 12:50PM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
> The most reliable method I've found to associate a data cell with a
> heading is to use the headers and id attributes
> (http://sp1ral.com/tests/flood-data-final.html). I have not tested
> associating a data cell in an inner (nested) table with a heading in
> an outer table. It would be an interesting test. Do you have an
> example of the tables/data you are marking up? I'd love to hear how
> Jaws, WindowEyes, and NVDA handle that type of relationship.
My intent isn't to associate headings in the parent table with those
in the nested table. The nested table will have its own set of
headings.
This isn't a hiding/showing of rows of the parent table, but rather a
hiding/showing of ancillary data for each row in the parent table.
I'll try to get some sample markup soon...
-Darrel
From: Sailesh Panchang
Date: Fri, Oct 23 2009 10:00AM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
Well a few questions:
Do the child data rows produced on expanding a parent row share the
same column headings as the parent row?
Is there a mechanism (markup) by which you are conveying the relation
between parent row and child row?
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?
The need for a blank TR is also perhaps an indication of this.
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.
Sailesh Panchang
On 10/21/09, D A < = EMAIL ADDRESS REMOVED = > wrote:
> I'm working on an interface that will consist of a data table with
> each row being expandable to show more details of that particular
> record. The details would then be formatted in their own table.
>
> This seems like a common need, but I haven't found too much that
> addresses it specifically.
>
> Is it fine to add a blank TR to the parent Table to insert the nested
> table within? Are there any issues/guidelines in regards to nesting
> data tables?
>
> -Darrel
>
From: D A
Date: Fri, Oct 23 2009 10:50AM
Subject: Re: Guidelines for nested data tables?
← Previous message | Next message →
> 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.
-Darrel
From: Sailesh Panchang
Date: Fri, Oct 23 2009 12:25PM
Subject: Re: Guidelines for nested data tables?
← Previous message | No next message
> 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 ADDRESS 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
>