E-mail List Archives
Thread: Data table
Number of posts in this thread: 11 (In chronological order)
From: Sumit Patel
Date: Wed, Oct 14 2020 3:19AM
Subject: Data table
No previous message | Next message →
hai all,
I have a doubt on providing column headers for the Data tables.
I could see that column headers must be provided for data tables in WCAg.
But, we would have tables like -
first column, we will have some text like 2017 report, 2018 report in
all the rows.
And in the second column, a Download pdf link.
So, my question is whether it is a data table or not?
And do we need to provide column , row headers and caption.
Waiting for answers....
.
Regards,
Sumit patel
From: Sailesh Panchang
Date: Wed, Oct 14 2020 7:21AM
Subject: Re: Data table
← Previous message | Next message →
Hello Sumit,
This content could well be marked up as a list with the PDF link
positioned next to the report identifier using CSS in the same LI.
If it is a table, a screen reader user could navigate down the rows in
col#1 and then to the right to the download link ... once the user
understands the design.
Or, one could be navigating down col#2 and expect the screen reader to
expose the report identifier. This will work if the report name cell
is marked up as TH and not TD. So yes, it is a data table in the
present form and needs row headers identified.
The table does not seem to have column headers as per your
description. So nothing needs to be marked up unless the table has
column headers like: Report Name / Available at ... or such.
A caption for the table needs to be marked up as one, if the there is
a caption available visually in the table's design.
Best wishes,
Sailesh
On 10/14/20, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
> hai all,
>
> I have a doubt on providing column headers for the Data tables.
> I could see that column headers must be provided for data tables in WCAg.
>
>
> But, we would have tables like -
> first column, we will have some text like 2017 report, 2018 report in
> all the rows.
> And in the second column, a Download pdf link.
>
> So, my question is whether it is a data table or not?
> And do we need to provide column , row headers and caption.
>
> Waiting for answers....
>
> .
>
>
> Regards,
> Sumit patel
> > > > >
--
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
From: Alan Zaitchik
Date: Tue, Oct 20 2020 2:53PM
Subject: Re: Nested data tables
← Previous message | Next message →
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
From: Patrick H. Lauke
Date: Tue, Oct 20 2020 3:13PM
Subject: Re: Nested data tables
← Previous message | Next message →
On 20/10/2020 21:53, Alan Zaitchik 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.
Nesting tables is generally not a problem when the data is in fact best
represented as a set of nested tables. What *is* generally frowned upon
is when tables are nested in an illogical/incorrect way, when really it
should be a single complex table or some even more complex structure.
(that codepen link doesn't seem to work btw)
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Steve Green
Date: Tue, Oct 20 2020 4:07PM
Subject: Re: Nested data tables
← Previous message | Next message →
My experience is that screen readers have no problem with nested tables, but screen reader users do. Even things like rowspans can cause difficulty. In more than 15 years of user testing, I don't recall seeing any screen reader user use the table navigation commands - they all "arrow" through the table, hoping that the data in each cell gives a clue as to what the column heading is. In small tables, they might remember all the column headings and keep track of where they are by counting the cells.
I doubt if 90% of users even know that there are table navigation commands. Remember that the screen reader users in this forum are probably in the top 1%, so their ability is unrepresentative of users in general.
I'm not saying that you should not use complex tables, but the only way to know for sure is to do user testing with people of average ability. And 50% of people are below average, so you ought to include some of them too.
Steve Green
Managing Director
Test Partners Ltd
From: Jonathan Avila
Date: Tue, Oct 20 2020 5:10PM
Subject: Re: Nested data tables
← Previous message | Next message →
JAWS has historically had issues with table navigation commands not working correctly in nested tables. This can be manifested in table header cells with nested layout tables that are not marked as presentation and in data tables within data tables. JAWS can get confused about which table you are in and you can easily skip cells across nested table boundaries and get out of the nested table accidently.
When I previously trained JAWS users we always covered table navigation commands. Although I suspect that many users who have not receive training are not aware of the commands as NVDA and VoiceOver on iOS both announce headers automatically when arrowing down through a table but JAWS does not.
Jonathan
From: Don Mauck
Date: Tue, Oct 20 2020 5:32PM
Subject: Re: Nested data tables
← Previous message | Next message →
I only use just my arrow keys in Grid like tables and I hate it!! Being able to use table commands correctly no matter the screen reader and assuming tables are marked up correctly row and column headers make a big difference.
Regards:
Don Mauck | Senior Accessibility Evangelist | Accessibility Program Office | (APO)
303.334.4184
= EMAIL ADDRESS REMOVED =
From: Alan Zaitchik
Date: Wed, Oct 21 2020 8:27AM
Subject: Re: Nested data tables
← Previous message | Next message →
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 ADDRESS 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
From: Sailesh Panchang
Date: Wed, Oct 21 2020 1:20PM
Subject: Re: Nested data tables
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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
> > > > >
From: Guy Hickling
Date: Wed, Oct 21 2020 7:13PM
Subject: Re: Nested data tables
← Previous message | Next message →
Steve Green, your observations about the vast majority of screen reader
users using the arrow keys instead of the table navigation provision is
very interesting. It is also just the kind of real life observation that we
need more of, so we know what real people out there are actually doing. It
would be worth a whole forum just to itself.
And your comment reminds me of a time when Microsoft, some years back now,
did a survey among users to find out what their users wanted to see added
in the next release of one of their products (Word, if I remember rightly).
About half the responses they got back were asking for things that were
already in the product but the users didn't know about! It seems a bit of
that may be happening with screen reader users in tables!
Jonathan Avila, your comments about JAWS were useful as well.
From: Steve Green
Date: Wed, Oct 21 2020 9:35PM
Subject: Re: Nested data tables
← Previous message | No next message
"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