Virtualized table: Accessibility audit

[evwilkin]

Follow-up to #4453 and #4454

Explore current a11y and flag any updates needed for virtualized table

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jessiehuff]

So after taking a look at the different variations of our virtualized table by keyboard, VO, JAWS, and NVDA, I have a few thoughts:

Keyboard:

• Currently there is no way for keyboard users to scroll or see more entries, particularly in tables where there are no interactive elements inside of the table. When the data is just readable/presentational, keyboard users can only see what is in view on page load. It is less concerning in the selectable or actions examples as they have interactive elements that allow users to cycle through the options.
• Suggestion: if we give the container tabindex="0", this will allow keyboard focus to shift to the table and the user can then use up/down arrow keys to scroll the data. In scenarios where there is additional interactive elements, this gives users the option to view all options or to tab again and enter the table (or vice versa tab out). It would work if we add tabIndex={0} to the VirtualTableBody.tsx file on line 236.
• There is a very odd interaction on the Filterable with WindowScroller example. When I tab through this example, the entire table shifts by two columns and goes back and forth between looking normal and then having the first two columns on the right side. @mcoker do you know if this is a CSS issue or maybe have insight into what's happening here?

VO (on Chrome):

• Currently all of the data cells are not associated. We should likely add headers attributes to associate cells with their appropriate header(s) as is typically recommended for tables.
• VO does not read the headers at all, this is an issue because the columns of what data the user is seeing is never announced, taking away vital context for users. This is even more concerning in the Sortable example where there are two sorting buttons that then become inaccessible to screen reader users.
• In the case of the Filterable with WindowScroller example, I could not get into the table at all. I could navigate through the toolbar, but not the table itself.
• Labeling - nothing announces that sortable button has been sorted (this is an issue across screen readers- should likely announce that it's sorted "Ascending" or "Descending")
• Suggestion: This is a tough one. Given the structure of the virtualized table, there is a top table with the column headers and a bottom table with the data, I assume so that the column headers will stay in place as users navigate the table. The roles also seem to be interfering with the tables' accessibility. When I take role="grid" off of the containing <div>, I am able to navigate through the headings. However, I think the structure needs some work as it seems to confuse screen readers. One potential approach we could take is have the top column header table as aria-hidden and provide a second set of headers only visible for screen readers for the bottom table so that screen readers could successfully associate the table elements. However, in doing this, we would need to sync up the sortable example buttons to also trigger when these visually hidden header buttons were pressed by screen reader. I'm not sure this approach will work though because then we put the keyboard users at a potential risk. (If the second set of headers is visually hidden, that hidden button would still be keyboard focusable and the user might lose their keyboard focus which is definitely an issue. And the previous header with a button wouldn't be keyboard accessible anymore because aria-hidden takes it out of the tab order.) I haven't determined the best path forward on this one that will meet all of our needs but still remain accessible for both keyboard and screen reader users.

VO (on Safari):

• I was unable to enter the tables at all. VO detected that these tables were there, but it did not allow me to navigate or read them. My theory is that this is due to the structural issues above. Roles probably need reworked/updated to better associate table elements and make the table work with a screen reader.

NVDA:

• Noticed a few odd interactions with the actions buttons and the filterable example announces the first column out of the table. Theorizing that these could be related to the structural issues above.

JAWS:

• Surprisingly looked pretty good, did not find any significant issues with it. It looks like JAWS was able to guess the associations well.

[mcoker]

There is a very odd interaction on the Filterable with WindowScroller example.

@jessiehuff can you link me to this example?

[jessiehuff]

@mcoker sure, this is the one I'm referring to. It might be easiest to look at it in a new window by itself to see what I mean. If you try to tab through the virtual table, you can see the odd interaction I'm mentioning.