WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Nested data tables

for

From: Steve Green
Date: Oct 21, 2020 9:35PM

"I disagree that screen reader users do not know how to use table navigation"

Well I've got 16 years of user testing results to support my assertion. It's easy for us sighted people who only need to remember perhaps 20 or 30 shortcuts in order to test websites. Screen reader users need to remember upwards of a hundred shortcuts just for the most common features on the most common applications they use. Most have not received thorough training and most don't keep up to date with changes - the changelog for each new JAWS release is quite daunting.

Also, we are careful to take account of users' proficiency level in our user testing, so we involve people with average ability unless clients have the budget to cover a breadth of abilities.

Steve


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Sailesh Panchang
Sent: 21 October 2020 20:21
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Nested data tables

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
> > > archives at http://webaim.org/discussion/archives
> >