Event fired or strategy when transferring focus due to 'insert + space' in a 'grid' role HTML element?

[turjmner8]

I am working on a 'grid' role implementation for a web component library, and have been testing with NVDA. I am curious how focus is transferred when switching between Browse and Focus modes. Specifically, if I get to the grid using the 'T' shortcut, and navigate through the cells using 'ctrl + alt + arrow key', what type of event or strategy is used to actually 'focus' that cell when a user presses 'insert + space' to sitch to Focus mode?

My specific implementation uses aria-activedescendant instead of something like a roving tabindex, but it seems like the only type of event I recieve is a focus event on the overall base grid element, which doesn't have any context of what cell the user was on prior to switching modes.

In JAWs for example, it looks like they simulate a click event which I can listen for (which has its own issues really...), but I'm not sure if there is a similar way for me to actually focus the 'current' cell unless my grid implementation switches to using something like a roving tabindex implementation with all cells having a tabindex of -1 or 0 instead.

Thanks for any help here.

[Adriani90]

cc: @jcsteh maybe you have some useful thoughts on this.
@turjmner8 out of interest, what is the reason behind choosing aria activedescendant instead of tabindex?
Aria activedescendant works only for interactive elements which are owned by the grid, so if the cells themselves are list boxes or text boxes or combo boxes or the like, then NVDA should move the focus accordingly. That means of course aria controls mus be used properly to define which element is owned by the grid. If the elements are visible or scrolled into view when focusing, then there should not be a problem. Actually NVDA simulates a mouse movement or click when switching from browse mode to focus mode or when activating an element from browse mode with the enter key.

In case you are using cells with elements that are not suported by aria activedescendant I think NVDA can focus them only when you use tabindex, but I am not sure.

Here you can find more details on this:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-activedescendant

[turjmner8]

Thanks for the help here - I believe there were a few reasons for using activedescendant rather than a roving tabindex. The main one was that our grid uses react, and re-renders can sometimes trigger focus loss from underlying elements when mutations occur. Attempting to track / manage these losses of real browser focus due to a re-render vs a user actually navigating out of the grid can be challenging, and can be avoided when using an activedescendant approach.

We use a combination of activedescendant along with shifting real browser focus when a cell contains something like a button or text box. I believe this approach will continue to be acceptable for our use cases if combined with tabindex values of -1 on the cells themselves to handle these additional NVDA (and other screen reader) behaviors.

[jcsteh]

When you switch from browse mode to focus mode, NVDA asks the browser to focus the element under the browse modecursor. This is equivalent to calling .focus() on the element in JS and can only work if the element is focusable; e.g. has a tabindex. Note that tabindex="-1" means that the element is still focusable, but not tabbable.

There is no way for NVDA to ask an element without a tabindex to get the focus. That would require some other kind of event, though that introduces privacy issues because it explicitly signifies to the website that the user is using assistive technology and thus is unlikely to ever be introduced into the web platform.

The only way you can achieve what you want is to use tabindex.

[turjmner8]

Thanks for confirming - this all makes sense and I should be able better support this by adding tabindex values of -1 and handling focusin events.

[jcsteh]

Note that NVDA simulates a mouse click when you activate an element in browse mode by pressing enter or space. It's inappropriate to do this when switching to focus mode (NVDA+space) because the user may not intend to "activate" the element. That's an important distinction, since focusing indicates an intent to interact, but activating might trigger some actual action.