E-mail List Archives
Thread: Feedback on a table sort implementation
Number of posts in this thread: 15 (In chronological order)
From: Jeremy Echols
Date: Mon, Jun 18 2018 10:46AM
Subject: Feedback on a table sort implementation
No previous message | Next message →
I'm looking for help on the implementation of a sortable table. I used an "accessible" table JavaScript written by the Illinois Department of Human Services in 2008. I don't recall why I selected this, but I did, and now I'm finding that it probably hasn't been accessible for quite a while (it was created in 2008, so in their defense it was probably the best option at the time).
Since discovering it had some problems, I've tried to update the JS to be a lot more screen-reader friendly. The output, at least the way I've styled it, won't be the most aesthetically pleasing, but hopefully gets the job done both for sighted users and screen-reader users. I'd like any input on where this falls short, as I want to use this approach in multiple projects.
Links:
- The raw JavaScript: http://pages.uoregon.edu/jechols/sortabletable.js
- A live demo taken directly from one of our projects: http://pages.uoregon.edu/jechols/titles.htm
Any input, criticism, or suggestion would be very helpful. Thanks in advance!
From: Greg Wocher
Date: Mon, Jun 18 2018 10:58AM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
Hello,
I tested this using Voiceover with Safari on the Mac. From a quick look it seems to be accessible. I am able to click on one of the column headers and change the sort order. It might be a good idea to let users know that clicking on the column headers lets them choose between ascending and descending order. With Voiceover I did not know that until I actually clicked on one of the headers.
Greg Wocher
> On Jun 18, 2018, at 12:46 PM, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
>
> I'm looking for help on the implementation of a sortable table. I used an "accessible" table JavaScript written by the Illinois Department of Human Services in 2008. I don't recall why I selected this, but I did, and now I'm finding that it probably hasn't been accessible for quite a while (it was created in 2008, so in their defense it was probably the best option at the time).
>
> Since discovering it had some problems, I've tried to update the JS to be a lot more screen-reader friendly. The output, at least the way I've styled it, won't be the most aesthetically pleasing, but hopefully gets the job done both for sighted users and screen-reader users. I'd like any input on where this falls short, as I want to use this approach in multiple projects.
>
> Links:
>
> - The raw JavaScript: http://pages.uoregon.edu/jechols/sortabletable.js
> - A live demo taken directly from one of our projects: http://pages.uoregon.edu/jechols/titles.htm
>
> Any input, criticism, or suggestion would be very helpful. Thanks in advance!
> > > >
From: glen walker
Date: Mon, Jun 18 2018 11:25AM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
I agree with Greg that the sorting capability needs to be noted. Currently
it just says "Title, button" or "Rights, button". What does a "title" or
"rights" button do? Visually, I can see the up/down icon but that's
aria-hidden so an AT user lacks that information.
I like that you're using aria-sorted once a column is sorted, and that you
have row headers so that the "edit" links can be associated with the row.
From: Jeremy Echols
Date: Mon, Jun 18 2018 12:16PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
Great feedback, thanks! For some reason I didn't get Greg's message (but I see it in the webaim archives). Would it make sense to put the "sort by Title descending" in the button, hidden to sighted users (since they have the icon) or add to the explanatory text above the table?
From: David Farough
Date: Mon, Jun 18 2018 1:33PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
I would include this as explanatory text for all to see.
Adding it to the buttons would just increase verbosity when moving from
cell to cell.
Once your users understand the structure and what is available this
explanation is less important.
David Farough
Coordonnateur de l'accessibilité des applications, Services intégrés de
gestion des TI
Commission de la fonction publique du Canada / Gouvernement du Canada
= EMAIL ADDRESS REMOVED = Tél: 819-420-8418 Télécopieur :
819-420-8408
Application Accessibility Co-ordinator, Corporate IT Management
Public Service Commission of Canada / Government of Canada
= EMAIL ADDRESS REMOVED = Tel: 819-420-8418 / Fax: 819-420-8408
>>> Jeremy Echols < = EMAIL ADDRESS REMOVED = > 02:16 PM Monday, June 18, 2018
>>>
Great feedback, thanks! For some reason I didn't get Greg's message
(but I see it in the webaim archives). Would it make sense to put the
"sort by Title descending" in the button, hidden to sighted users (since
they have the icon) or add to the explanatory text above the table?
From: Jeremy Echols
Date: Mon, Jun 18 2018 2:24PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
Of course, that makes sense. Thanks!
From: glen walker
Date: Mon, Jun 18 2018 2:52PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
I'm not sure the explanatory text is needed for all users. Sighted users
have the icon on the button and the arrows are somewhat universally
understood. But since the icons are hidden from AT, explanatory text is
needed for AT. That can be via ARIA or a "visually-hidden" or "sr-only"
class.
From: Jeremy Echols
Date: Mon, Jun 18 2018 3:15PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
I agree, but I am leaning toward keeping a unified experience where I can. It's less to maintain, less "magic" hidden in the HTML, may help users with cognitive disabilities, and doesn't really have to take up much space. Is there any accessibility-related con to having the information visible to everybody?
From: glen walker
Date: Mon, Jun 18 2018 3:24PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
You can certainly have it visible to everyone, although I wouldn't put it
on the button label. Are you thinking of a general statement before the
table that says clicking on the column headers will sort the column? If
I'm an AT user and I tab through the interface, I'll miss that statement
unless it's associated with the button via aria-describedby or a similar
labeling.
On Mon, Jun 18, 2018 at 3:15 PM, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> I agree, but I am leaning toward keeping a unified experience where I
> can. It's less to maintain, less "magic" hidden in the HTML, may help
> users with cognitive disabilities, and doesn't really have to take up much
> space. Is there any accessibility-related con to having the information
> visible to everybody?
>
>
From: Jeremy Echols
Date: Tue, Jun 19 2018 10:31AM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
Yes, I put the information above the table. It's associated with the table via aria-describedby, but not the individual buttons. It seems to get read properly when first entering the table, though not if you tab into the table, which seems like a bug.
I think I'll go ahead and put the description on the buttons instead. It's just extra hidden magic and I'm not a big fan of that.
From: Jeremy Echols
Date: Tue, Jun 19 2018 11:03AM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
On further reflection, I think the above-table description is going to be the best option. Adding anything I can think of to the buttons makes the speech cumbersome, and is one of those things you only need to know once. If the table's description is read (which happens in all cases of entering the table *except* tabbing to a header), it becomes a lot of unnecessary noise.
I still don't understand why tabbing into the table doesn't cause the "aria-describedby" element to be read. Is that an NVDA bug, or just standard screen reader behavior?
From: glen walker
Date: Tue, Jun 19 2018 11:22AM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
> I still don't understand why tabbing into the table doesn't cause the
"aria-describedby" element to be read. Is that an NVDA bug, or just
standard screen reader behavior?
When you specifically navigate to the table with a quicknav key such as T,
your focus is really on the table so the description is announced.
If you tab into the table, you're not really tabbing to the table itself.
You're tabbing to a button that's in the header.
I know it's a minor difference but I can see why the description wouldn't
be announced.
From: David Farough
Date: Tue, Jun 19 2018 12:42PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
I notice the following differences with this table when using Jaws,
NVDA, Firefox 60.2 Google chrom 66 and IE 11.
Ie 11 with Jaws
moving to table with table nav key t
Jaws describes the table with the number of rows and columns. The sort
info not provided at all.
Column headings are announced when moving to each cell.
Using control Insert + t to list the tables on the page lists the
column headings for the table as well as some of the data from the next
row. Had you coded a caption for the table, this information would have
been presented instead.
NVDA with IE 11
moving to table with table nav key t
Nvda describes the table with the number of rows and columns. The
sort info not provided at all.
Column headings are announced when moving to each cell.
Firefox 60.2 with Jaws
moving to table with table nav key t
Jaws describes the table with the number of rows and columns. Then
provides the sort info.
Navigating to each cell speaks the cell title as well as "up down arrow
button"
Using control Insert + t to list the tables on the page specifies the
sort info and then describes the table as 5x74
Firefox 60.2 with NVDA
moving to table with table nav key t
NVDA describes the table with the number of rows and columns. Then
provides the sort info.
Navigating to each cell speaks the cell title but does not include the
up down arrow button
Google chrome 66 with Jaws
moving to table with table nav key t
Jaws describes the table with the number of rows and columns. Then
provides the sort info.
Navigating to each cell speaks the cell title but not "up down arrow
button"
Using control Insert + t to list the tables on the page specifies the
sort info and then describes the table as 5x74
Google chrome 66 with NVDA
moving to table with table nav key t
NVDA describes the table with the number of rows and columns. Then
provides the sort info.
Navigating to each cell will provide the column title as well as the
data for that cell. However, for some reason the title heading for
column 1 is not provided for that cell.
David Farough
Coordonnateur de l'accessibilité des applications, Services intégrés de
gestion des TI
Commission de la fonction publique du Canada / Gouvernement du Canada
= EMAIL ADDRESS REMOVED = Tél: 819-420-8418 Télécopieur :
819-420-8408
Application Accessibility Co-ordinator, Corporate IT Management
Public Service Commission of Canada / Government of Canada
= EMAIL ADDRESS REMOVED = Tel: 819-420-8418 / Fax: 819-420-8408
Ce courriel est destiné exclusivement au destinataire mentionné en titre
et peut contenir de l'information privilégiée, confidentielle ou
soustraite à la communication aux termes des lois applicables. Toute
divulgation non autorisée, toute reproduction ou réacheminement est
interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
par erreur, veuillez le mentionner immédiatement à l'expéditeur et
supprimer le courriel et les copies.
This e-mail message is intended for the named recipient(s) and may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law. Unauthorized disclosure, copying or
re-transmission is prohibited. If you are not a named recipient or not
authorized by the named recipient(s), or if you have received this
e-mail in error, then please notify the sender immediately and delete
the message and any copies.
From: Jeremy Echols
Date: Tue, Jun 19 2018 1:08PM
Subject: Re: Feedback on a table sort implementation
← Previous message | Next message →
David, this is excellent information, thanks! I'm not sure how to address some of these oddities, but I can certainly do things like adding a caption.
Swapping the instructional div with a summary attribute also seems to ensure it's always announced, but the summary attribute has been deprecated.... I'm not sure the right approach here - use an obsolete attribute that's likely to go away soon or lose information for a subset of users? And if I use both, it gets announced twice in some situations.
Glen, regarding entering the table: that does make some sense, but it's still a bit odd to me. If there are special instructions for a table that aren't relevant for a specific header or cell, do we just have to hope screen reader users are going to double-check the table? And why is summary (at least in NVDA + Firefox) always announced no matter how I get to the table?
This is tricky.
From: Jeremy Echols
Date: Tue, Jun 19 2018 1:22PM
Subject: Re: Feedback on a table sort implementation
← Previous message | No next message
It gets even weirder: adding a caption suppressed the summary in NVDA and Firefox. I think I'm just going to have to go with a "good enough" implementation that adheres to the best practices I can find, and hope for the best. There doesn't seem to be a way to make this perfect for everybody without adding a fair amount of brittle code to it.