WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Nested data tables

for

From: Sailesh Panchang
Date: Oct 21, 2020 1:20PM

Hello Alan,
From the example, it is difficult to see the relationship intended to
be portrayed. The parent row has a MF symbol, price and gain/loss.
But the child table has account#, account type (like checking or IRA)
and then an amount column.

Perhaps if it showed in which account the particular MF is held, the
quantity of units and its current value, that would make more meaning.
As of now the child table seems to hold content that appears to be
from a different data set. That made me wonder, why is nexting /
expand - collapse being used.
About screen readers and nested tables:
When a nested table is presented, it breaks screen reader's table
navigation. the table nav-keys fail and one has to use arrow key to
navigate to the next cell and decipher the relationship.
Wwhen nested table(s) are expanded, the "T" key goes to each table
and it is difficult to see the relationship in the context of the
page.

Consider instead, the parent table itself should have the columns for
account#, holding quantity and current value following the price and
gain/loss columns. Those should be hidden on page load.
But should be displayed with relevant data when the "show" button for
at least one symbol is expanded. Again those columns should contain
data only for symbol(s) for which the user has chosen to view the
data.
In the current design, it is not possible to see the total values /
holding across accounts, but the single table option will facilitate
this.
The benefit is that all data is within a single table and the column
headers / caption for the nested table do not have to be repeated.
Alternatively, on activating the "show" button for a symbol, consider
presenting the data in a popup that can be closed.
I still maintain nesting tables is an avoidable choice from a design
and accessibility perspective.
Whether one nests tables or uses a single table option with expandable
columns as described above, using the summary attribute of old to
describe the functionality will be very useful. I believe screen
readers still support it.
I disagree that screen reader users do not know how to use table
navigation. It is perhaps the poor markup for tables generally makes
users adopt alternative methods to review tables.
Thanks,

--
Join me at axe-con 2021: a free digital accessibility conference. Read more at
https://www.deque.com/axe-con/
Feel free to contact Deque marketing if you have any questions. Thanks!

Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765
































On 10/21/20, Alan Zaitchik < <EMAIL REMOVED> > wrote:
> My apologies... Typo in codepen URL— please try
>
> https://codepen.io/azaitchik/pen/OJXRQVQ
>
> Thank you,
> Alan
>
>> On Oct 20, 2020, at 16:53, Alan Zaitchik < <EMAIL REMOVED> > wrote:
>>
>> I understand that nesting a data table inside another data table is
>> generally frowned upon, but in some cases it seems to me that nesting a
>> table in another is exactly the best way to communicate the data
>> relationships. I wrote a codepen which illustrates a case I am dealing
>> with:
>> https://codepen.io/azaitchik/pen/QJXRQVQ. (The top row nests an inner data
>> table.)
>> Voiceover, Jaws, nvda all have no problem with the nested table, and I am
>> wondering if there are guidelines as to when the tables (outer and inner)
>> are "simple enough" that there's no problem with nesting.
>> Any guidance people can offer will be most appreciated!
>> Thank you.
>> Alan
> > > > >