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

Apologies for the long comment. Hopefully it's at least clear.

I think there are three fundamental states for focusability: an element is 
- not focusable (a plain `<div>`), or it is 
- programmatically focusable`*` (`tabindex=-1`), or it is 
- user focusable (`<button>`, `<textarea>`, `<a href>` `<input type=*>`, etc).

I think the logic behind Safari's choices around how a user may focus certain elements is something along the lines of:

- Everything that is user-focusable is mouse-focusable by default (exception below)
- Editable form controls are tab focusable to enable rapid form filling from the keyboard
- Non-editable form controls are tab focusable because they are form controls, but _not_ mouse focusable because they aren't interactive in practice
- Links (and `<button>`) are not keyboard focusable by default (but users may opt in) because for mixed-modality users filling out a form rapidly they are more likely to get in the way if included in the tab order (e.g. "more info" or "reset password" links when you mean to navigate to the submit button)
- In addition, elements with `tabindex=0`, plus some other elements like `<details>`, `<audio controls>` and `<video controls>` are also always tab-focusable in Safari.

I think that comes down to three classes for built-in "user focusable" elements:
- mouse focusable, always tab focusable (form controls, things with `tabindex=0`, etc)
- mouse focusable, opt-in tab focusable (links, buttons)
- not mouse focusable but tab focusable: non-editable form controls

_If_ we ruled out wanting to emulate non-editable form control behaviour`**`, that would come down to whether something is:
- always tab-focusable (tabindex=0), or
- UA decides (link, buttons - always focusable in some UAs, selectively focusable in others)

So that comes down to four categories:
- unfocusable
- programmatically focusable
- user focusable: UA decides`***` about tabbable
- user focusable: always tabbable

That seems both simpler and more robust than using ARIA roles, in particular since we don't yet have parity between ARIA roles and HTML elements (there's no `video` role, for example).

---
`*` in my experience, having an element with `tabindex=-1` be focused on click causes many more problems than it solves, so I'm explicitly ignoring that behaviour here

`**` it would be straightforward enough to just add a click listener with `preventDefault()`, for example

`***` a UA could also use other signals, such as form participation, to decide whether this should be treated as "always focusable"

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