WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Interactive table grids - Multiple questions

for

From: glen walker
Date: Dec 21, 2022 10:22AM

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