-1

I am challenged to make an HTML table/grid accessible, which offers the user the possibility to select a row and perform an action on the selected row.

The following link gives an example, on how everything shall look like (without accessibility): https://alejandro.app.fi/crud-ui-demo/simple

My problem is: How do I make the buttons on top of the page, for performing the action on the row, accessible? How can I get the screen reader to announce the part, so that the user is able to interact with it?

In my opinion it would be a bad idea, to let the screen reader read something like "To edit this row tab back xyz times and use the buttons above the table"

I searched through the wai-aria and was hoping to find something like a "connector" to give the screen reader a connection to these buttons at the top, but could not find anything, that would fit.

Is this a bad pattern, with which I want to work with? Or how can this be solved?

TylerH
  • 20,799
  • 66
  • 75
  • 101
CTB
  • 1
  • 1
  • If it single selection, I would suggest to put action controls in the row itself in the last column and do the accessibility as outlined on [WAI Aria Practices for the Data Grids](https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html) – Ritesh Jagga Jul 11 '21 at 15:52

1 Answers1

0

A large table with internal selectability and external editing controls is inherently difficult to use, even without any disability.

Large tables are hard to get intuitive information from.

Wide tables or tables viewed in narrow windows require horizontal scrolling.

Selectability tends to be confusing, because you are focused on a cell, but when you select it you might want to select it, its row, or its column, so you need a way to distinguish these three kinds of selection. Also, it is not obvious whether selection automatically follows focus or requires a separate action.

External editing controls are distant from much table content, so when you are looking at the controls the selected row may be out of sight, making you forget which row you selected.

Screen readers have poor support for tables and often give wrong header information about cells.

If you asked what users wanted, most probably would not tell you they want to see hundreds of alphanumeric facts arranged in a grid. For editing data, most users might want (1) a way to find the desired data and (2) a way to edit those data. Displaying all the data in a table is unlikely to be a user-friendly method for achieving either #1 or #2.

Clever rendering methods may fail under common conditions. For example, above the cited table is a horizontally scrollable top list of table types. On a narrow device, the right end of the list cannot be scrolled into view.

In principle, tables can be WCAG-accessible. In practice, tables, especially if large, complex, or operable, are usually inferior to other solutions in usability and accessibility.

Jonathan Pool
  • 369
  • 1
  • 9