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

> Based on that, I don't think text-control is right, but maybe accepts-text-input? That's the distinction macOS (and Mac Safari) is trying to draw. Other things similar to list boxes (e.g. table/grid controls) should also accept tab focus by default.

I think if that's the critical concept, that it should be a concept in its own right: it also determines things like on-screen keyboard display and is an input into `:focus-visible` matching.

Which brings me back to my original proposal in https://github.com/w3c/webcomponents/issues/762#issuecomment-542509589 of four distinct categories:

- unfocusable (default)
- programmatically focusable (for things like list item elements or [tabpanel](https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel) tabs) which shouldn't be in the tab order but which should be able to have focus sent to them programmatically)
- user focusable: UA decides about tabbable (using whatever API allows an element to opt in to "texty" behaviour)
- user focusable: always tabbable (for something like `<select>`)

Naming-wise, perhaps:

`focusability`
`default`
`programmatic`
`auto`
`sequential`



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