E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: megha patangi
Date: Mon, Dec 19 2022 5:39AM
Subject: Interactive table grids - Multiple questions
No previous message | Next message →

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

From: Francesco Mammetti
Date: Mon, Dec 19 2022 9:35AM
Subject: Re: Interactive table grids - Multiple questions
← Previous message | Next message →

Hi I can try to answer the question (I hope others do too)

*Question 1:*I believe the column header with related markup is needed for
accessibility as it says link to source WCAG <http://source/>; (open new
window). I believe that upstream the cell data should be reworked and
redirected into meta-categories through perhaps a card sorting and thus
create headers for the columns.

*Question 2:*
I just did a test with google sheets + chromevox, going to a cell, it
automatically reads the complete word, by pressing enter you enter the cell
and using key combinations you can spell the word or read word by word or
read all the content, so I don't think it's necessary to do everything
modal.

*Question 3:*
Speaking of usability, it would be preferable to use pagination, because it
allows the user to cognitively have the coordinates of where to find that
row, cell, with the infinite scroll method, if the user has to go to row
140, how many scrolls must he do? How many lines are scrolled? This means
that the result is not even predictable and makes the experience
frustrating for any type of user.

Regards
Francesco

From: glen walker
Date: Mon, Dec 19 2022 3:35PM
Subject: Re: Interactive table grids - Multiple questions
← Previous message | Next message →

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 ADDRESS 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
> > > > >

From: glen walker
Date: Wed, Dec 21 2022 10:22AM
Subject: Re: Interactive table grids - Multiple questions
← Previous message | No next message

Just a few remaining thoughts based on your update.

Question 1
I know JAWS, NVDA, and VoiceOver on iOS announce row/column numbers when
navigating through a table (unless, as mentioned, the user turns off those
settings). I didn't try VoiceOver on the Mac or Talkback on Android so you
may want to confirm those.

Having a column header for your selection checkbox is good. I'm not saying
that you shouldn't have an individual label for the checkbox itself.
There's a WebAIM article on this situation that recommends using
aria-labelledby on each checkbox and point it to the column header.

https://webaim.org/techniques/forms/advanced#multiple

Question 2
This is an issue between the two modes of the screen reader: browse mode
and forms mode. (The two modes might be called different things in each
screen reader but I'm using "browse" and "forms".) This might be too basic
of information so I apologize if you know this already. Browse mode is
when all keystrokes are sent to the screen reader for interpretation first,
such as the down arrow key to move to the next DOM element in the
accessibility tree or the 'B' key to move to the next button. Forms mode
is when all keystrokes are sent to the browser for interpretation, such as
the down arrow key to scroll the page down or the 'B' key to type the
letter B into an input field.

By default, most screen readers will switch between the modes
automatically. The switching depends on the type of element that gets
focus. Here's a list of those elements. Grid is one of them.

https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#x6-1-fundamental-keyboard-navigation-conventions

That is why you can't (by default) navigate char by char or word by word
when you're in a cell, because the screen reader switched from browse mode
to forms mode and the keystrokes are being sent to the browser.

However, even if the screen reader switches modes automatically, the user
can still switch back to the other mode manually, so they can still
navigate by character or by word while in the grid cell.

I just wanted to make sure that was understood before you did a lot of work
trying to create a modal just to give the user a way to navigate by
character or word.

On Wed, Dec 21, 2022 at 4:52 AM megha patangi < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi Glen,
>
> Thank you for your responses and definitely they gave a bit of clarity to
> me.
>
> Answering to your questions:
> Yes grid is like a spreadsheet which user can edit and so we needed
> role="grid".
>
> With respect to answer 1:
> I liked the answer for row number, as screen reader already announces
> the row number and now if we give custom label to it, then it might be
> redundant announcement and there can be chances that default render
> versus custom render may not match.
> And yes the first column containing radio button/ checkbox has column
> header, both visual and associated for screen reader.
> Thus, you recommend that individual label to these controls in each
> cell is not required?
>
> With respect to answer 2:
> Using keyboard a user cannot navigate using left/ right arrow keys
> inside cell to read character by character as we haven't enabled those
> keys to navigate when focus is inside the cell as they were bringing
> other complications to our table, as developers can author any sort of
> data type inside the cell.
> this actually added to complexity and we had to go with modal approach.
> Actually for list of links inside a cell, where there are more than
> three for all users it will open modal. Just in use cases of till 3
> link list we have different interaction for keyboard users in modal.
>
> With respect to answer 3:
> yes user can tab to interactive element present just after table. New
> data appears only on clicking down arrow within the table, from last
> row.
>
> Regards,
> Megha
>
>
>