mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.15k stars 1.3k forks source link

[DataGrid] Multiple problems with discoverability of sortable columns, exposure of column headers #4124

Open brucelawson opened 2 years ago

brucelawson commented 2 years ago

Duplicates

Latest version

Current behavior 😯

A screenreader (Windows/ Jaws) tested https://mui.com/components/data-grid/#commercial-version for us, reporting:

"β€œIf I use standard screen reader commands for navigating up/down/left/right through either of the tables, my screen reader does not tell me that anything can be sorted. I've eventually figured out that you can summon up a sort of menu to choose to sort things, but none of the controls that trigger it are announced as anything but plain text.

The component is also described as being a grid, which would imply some kind of interactivity, but I can't seem to get it to behave like one - only like a sortable static table.

It doesn't seem to be possible to reach any of the column headers in either table (except the first one that contains the checkbox) using the Tab key, so sorting the columns is problematic for keyboard users.

If you use a screen reader to navigate either table like a standard data table, the column headers are not exposed as interactive controls, so you have no idea you can use them for something.

If you Tab into either table with a screen reader enabled, applications mode is automatically invoked. At that point the keyboard navigation has been provided (very well), but the ability to use the column headers to sort the content is still not announced - though if you experimentally activate one of the column headers the sort does happen, but it's not announced, and neither is the sorted state/order.

This is just a quick look with one screen reader/browser combination.

It's a good starting point. It'd be better if it used proper HTML table markup as its foundation (it'd probably cut the code down by a good 30%/40%), but it wouldn't take much to fix the few niggles with it in its present form.

This example has some of that: https://www.w3.org/TR/wai-aria-practices-1.1/examples/grid/dataGrids.html 11:18 The second example has the sort functionality (with none of the problems of the React implementation).

The second and third examples have other features like content editing, show/hide and scrolling too.

The interactive controls are all announced as such, whether in applications mode or not. The sort capability is announced, as is the sort state (assuming there is one). I can edit those fields that are editable too.

The keyboard functionality (if you're in applications mode) has been provided and works well.

The one thing that doesn't seem to work is that, when in applications mode and moving up/down or left/right through the table, the row/column headers are not being announced.

But overall it's a much better experience than the React pattern. This I can use and figured out how to use it fairly easily. The React one not so much, which I assume would likely defeat a lot of people less familiar with the way these things are supposed to work."

Expected behavior πŸ€”

The sort controls are not visible unless the table is sorted by the column they are in (i.e. only the currently sorted column's control is visible). The button elements are removed from keyboard focus order with tabindex="-1", and the grid role intercepts keystrokes so that screen reader users can't access them either.

The unsorted columns lack an aria-sort attribute (which should be set to aria-sort="none" for the unsorted columns), so there is no indication that the table header cells are sortable UNTIL they are sorted.

They really only need something simple, like:

<table> <thead> <tr>

<th aria-sort="ascending"><button type="button">Column 1</th> <th aria-sort="none"><button type="button">Column 2</th> </tr> </thead> </table>

this is a good pattern for a sortable data table: https://www.w3.org/TR/wai-aria-practices-1.2/examples/table/sortable-table.html

Steps to reproduce πŸ•Ή

Steps:

1. 2. 3. 4.

Context πŸ”¦

No response

Your environment 🌎

`npx @mui/envinfo` ``` Don't forget to mention which browser you used. Output from `npx @mui/envinfo` goes here. ```

Order ID πŸ’³ (optional)

No response

flaviendelangle commented 2 years ago

We do have the aria-sort atribute Do you see any problem with its value or position ? It is placed on the higher node of the column header (the equivalent of the th)

https://github.com/mui/mui-x/blob/master/packages%2Fgrid%2Fx-data-grid%2Fsrc%2Fcomponents%2FcolumnHeaders%2FGridColumnHeaderItem.tsx#L157-L160

Or is the problem the fact that the event handlers are on the same node as aria-sort (which is a div not a button) ?

m4theushw commented 2 years ago

It doesn't seem to be possible to reach any of the column headers in either table (except the first one that contains the checkbox) using the Tab key, so sorting the columns is problematic for keyboard users.

We treat the grid as composite widget. In this way, pressing Tab focus the first column header. Once focused the navigation keys are used to navigate between cells and column headers. We try to follow https://www.w3.org/TR/wai-aria-practices/#grid and https://www.w3.org/TR/wai-aria-practices/#kbd_roving_tabindex

Should Tab move focus to the next column header too?

The unsorted columns lack an aria-sort attribute (which should be set to aria-sort="none" for the unsorted columns), so there is no indication that the table header cells are sortable UNTIL they are sorted.

True, we only add aria-sort once the column is sorted. It turns out that not adding aria-sort=none makes the screen reader not to announce that the column is sortable, although none is the default value. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-sort#values We can fix that.

IanPouncey commented 2 years ago

The component is also described as being a grid, which would imply some kind of interactivity, but I can't seem to get it to behave like one - only like a sortable static table.

The confusion here is because although the screen reader user who reported the problem was able to navigate the cells using arrow keys, the editable cells contain no interactive control to indicate that the cell has any additional functionality. There is no difference between the cells in the "ID" column, which are not editable, and the cells in the "First Name" column, which are editable. Data Grid Examples: Example 2: Sortable Data Grid With Editable Cells has an example of how you can add this indication of functionality, by wrapping the initial cell contents in an element with role="button":

<td>
  <div class="editable-text">
     <span class="edit-text-button" tabindex="-1" role="button">Down Town Grocery</span>
     <input class="edit-text-input hidden" tabindex="-1" value="">
  </div>
</td>

Navigating to the cell using arrow keys sets focus to the <span role="button"> element and pressing ENTER with this focussed replaces it with the <input> element.

While there are some improvements that can be made to this example (trigger the activation of the <span role="button"> with the SPACE key as well as ENTER - using a <button> element would give you this for free - and give the <input> element an explicit accessible name with a <label> element, aria-labelledby,or aria-label), the basic functionality is there and clearly exposed to screen reader users. It is also accessible to voice control software users without having to replicate the use of key presses to navigate the table, which is very time consuming.

Also note in the example that the editable cell is visually obvious as well, which is not the case for your Data Grid; while this may be clearer based on the context in which the grid is used, this may not always be the case. An icon or at least a visual styling (an underline on the text or different border thickness on the cell, for example) would help.

It doesn't seem to be possible to reach any of the column headers in either table (except the first one that contains the checkbox) using the Tab key, so sorting the columns is problematic for keyboard users.

Should Tab move focus to the next column header too?

Not within a role="grid", but the problem with grids is that it's generally not obvious to keyboard users that they are grids and can therefore be navigated with arrow keys; keyboard users may not know that this is possible unless they've encountered it before. Data Grid Examples: Example 2: Sortable Data Grid With Editable Cells shows a depiction of arrow keys when keyboard focus is moved to it, which might help.

Also, while the sort functionality is keyboard accessible (which also having the same problem with a lack of interactive element, as described above meaning that there is low discoverability), the "Menu" control for each cell which includes additional functionality is not, not is it screen reader, voice control, or touch screen accessible as it only displays on hover. You could make activating this menu the default for the entire cell; this would make it accessible to users of all of these technologies, with the downside of adding key presses to activate the sort functionality.