Re: [w3c/webcomponents] Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? (#762)

> On macOS, with full keyboard access enabled, in many cases, each such interactive part should be in the tab order. Without full keyboard access, it shouldn't be. At the very least, that's true for tabs and tree views.

I just tested it on the macOS settings app, and tabs are one tab stop in that context. Arrow keys choose between the different tabs (and move the focus indicator).

<img width="550" alt="Screen Shot 2020-03-09 at 6 59 20 pm" src="https://user-images.githubusercontent.com/95208/76193494-3d0a5780-6238-11ea-8017-08d5c37e3392.png">

I couldn't find a tree view to test with - the files list in Finder seems to put things in a totally random tab order.

> List boxes don't give individual focus to their elements, the list box as a whole is the only thing to get focus. Likewise for menus.

Conceptually this is true, but authors often implement that concept on the web by focusing individual elements, for a variety of reasons. This is the reason `tabindex=-1` was originally added to the platform.

> For grids, I'm assuming you mean editable grids, like a spreadsheet, and those tab to each item.

It may also be a layout grid, like the Google Docs recent documents list:

<img width="1544" alt="Screen Shot 2020-03-09 at 7 13 21 pm" src="https://user-images.githubusercontent.com/95208/76194348-19481100-623a-11ea-8fec-4e1ad9a0c225.png">

In that case the entire grid is one tab stop, with arrow keys allowing movement between items. This is to prevent the grid being a de-facto "tab trap" if keyboard-only users need to navigate to content before or after.

> Are parts like that not meant to be click-focusable? What exactly sends programmatic focus to a specific piece?

It would be an event listener for either a keyboard (arrow key) event on an adjacent item, or a pointer event.

It's a valid question whether `programmatic` focusable elements should be click-focusable or not. I've tended to think they shouldn't, since click focusability has caused confusion when `tabindex=-1` has been used to make container elements programmatically focusable but non-interactive elements to simulate moving the focus navigation start point (such that the user clicks, say, a paragraph of text and a focus outline shows up), but perhaps https://github.com/whatwg/html/issues/5326 is a sufficient solution to that problem.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/762#issuecomment-596390746