WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Interactive table grids - Multiple questions

for

From: glen walker
Date: Dec 19, 2022 3:35PM

Side question first. Is your "grid" like a spreadsheet in that you can edit
cells directly, such as typing new text into a cell? Or do your table
cells just contain interactive elements such as buttons and checkboxes? If
the latter, then a grid might not be necessary. I suppose it depends if
you want users to be able to navigate through the table using the arrow
keys.

There are several issues in question 1.
The first is that most (all?) screen readers will announce the row number
as you navigate vertically down a column regardless of whether you have row
headers. It's typically an option that is on by default but the user can
turn it off. That's what I do, personally. I turn off the table
coordinate announcement because I find the row number announcement a bit
"noisy". If you force the row number to be announced, you'll be going
against some user's wishes. For me, if I want to hear the row number, I
can use a shortcut such as Ctrl+Alt+5 in JAWS. (Other screen readers may
or may not have a shortcut key to read the table row number.)

Second, I understand that you might not know the best column to use for the
row header. That's a difficult one. It really should be left up to the
developer creating the table. You should have an option for the developer
to specify which column should be the row header. If they don't choose,
then just use the first column. It might not be great but is usually better
than no row header.

For the radio/checkbox used to select the row, is there a column header
and/or input label so that the user knows the widget is for selecting the
row? I'm guessing you have cases where only one table row can be selected,
and thus you use a radio button, and other cases where multiple table rows
can be selected, and thus you use a checkbox.

Question 2.
Pressing ENTER to go into "edit mode" for a cell sounds reasonable. I've
done that before. I've also implemented F2 to change a cell from "browse
mode" to "edit mode".

I didn't follow why a user couldn't navigate by character or by word
directly in the cell instead of bringing up your dialog.

I also didn't follow why having a dialog for keyboard users makes it
"consistent".

If a mouse user can directly interact with an element in the cell, why
can't a keyboard user do that too? That would feel "consistent" to me.

But to answer you specific question about keyboard functionality, yes, WCAG
2.1.1 says that all "functionality" of the page must be available to
keyboard users. It does not say that all interactive elements must be
available to keyboard users, although that's usually a best practice.

Question 3
That sounds a little like infinite scrolling, although you're not scrolling
to cause new data to appear, you're just pressing the down arrow key.
Infinite scrolling is often not a great experience, especially from an
accessibility perspective.

Do you have an interactive elements after the table, even if in the footer
of the page? If so, can the user TAB to those elements without new data
being added to the table? That is, is new data added *only* when the down
arrow is pressed when you're on the last row?

A sighted keyboard user can see new rows being added, right? So the screen
reader user should be notified as well. That's easily done with an
aria-live region.


On Mon, Dec 19, 2022 at 5:39 AM megha patangi < <EMAIL REMOVED> >
wrote:

> Hello Web Aim team,
>
> I am an Accessibility Specialist, and working with developers
> currently on interactive tables (role="grid")
> As per business requirements, there are complex use cases in our
> tables and have following few questions with respect to it.
>
> Question 1:
> In our tables we currently do not have associated row headers and
> technically it is also doesn't seem possible. We work in a low code
> environment and the consumers of these tables can place any sort of
> data in any column, thus, to identify unique data containing columns
> to mark them as row headers is not possible. For this we have come up
> with a solution to provide row number announced by SR while navigating
> within the table grid using up/ down arrow keys.
> These tables have radio button/ checkbox in their first column to
> select rows, so is our approach to have row number is enough?
> Can we even go with not having either row header or row number? Means
> nothing read contextually for each radio button/ checkbox?
>
> Question 2:
> Now, for cells having multiple interactive/ non-interactive assets
> inside it we are currently going with approach to let keyboard user
> hit enter on cell, which opens a modal dialog and then interact or
> read here (instead of going inside cell and then interacting). What we
> are trying to solve is to bring consistency, and also making it easy
> for screen reader users to read the content word by word, or character
> by character which is not possible directly inside the cell.
> But, for mouse pointer users, they can still interact directly with
> cell content and modal never opens for them.
> Is it fine to have different functionality for keyboard users versus
> mouse pointer users, when each of them are able to enjoy complete
> functionality, but in different ways?
>
> Question 3:
> As we move below the table rows using down arrow, new rows keep on
> loading. And since table can have huge data, the entire table is not
> rendered in DOM. Only the rows visible on UI along with few buffer
> items above and below the visible rows are rendered on DOM.
> Is any dynamic announcement of new rows being loaded required for
> screen reader users? If yes what can be best approach to meet
> accessibility requirements?
>
> These are all for now.
> Looking for help from experts.
>
> Thank you,Megha
> > > > >