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

ITenthusiasm left a comment (WICG/webcomponents#762)

Just wanted to follow up on my [previous comment](https://github.com/WICG/webcomponents/issues/762#issuecomment-3289994814) now that I have more insight.

## Why `[tabindex="-1"]` Was Needed

It seems that the reason my `listbox` was being focused was that it contained enough `option`s to become scrollable, and [Google Chrome makes scrollable containers focusable by default](https://developer.chrome.com/blog/keyboard-focusable-scrollers) (if they don't have focusable children).

In general, the idea sounds like it helps accessibility. But it's problematic for more advanced components like `combobox`es, and (in retrospect) it probably would have been better to instruct developers to set `tabindex="0"` on the appropriate scroll containers instead.

The whole point of `aria-activedescendant` with `combobox`es  is that developers _don't_ have to manage true focus from within the `listbox`. Instead, they can manage a "virtual focus" from the `combobox`. This means users can search `option`s _and_ navigate them from a single place. With this functionality, focusing the `listbox` is completely useless for two reasons: 1) The content can already be scrolled from the `combobox`, and 2) The `listbox` won't have any `option`-interacting functionality because such functionality was implemented solely on the `combobox` (intentionally).

So, to circumvent Chrome's behavior, I put `[tabindex="-1"]` on the `listbox` explicitly (similar to putting `[role="list"]` on modern `<ul>`s :pensive:). But this caused more problems, and now across _all_ browsers:
- I now need `event.preventDefault()` on `mousedown` to prevent Mouse Users from accidentally focusing the `listbox`.
- VoiceOver now tries to focus the `listbox` when the cursor moves to it due to `[tabindex="-1"]`. But the `combobox` collapses when it loses focus. So I have to add clever `blur` listeners to keep the `combobox` open using `relatedTarget` so that I don't close the `combobox` when focus moves between the `combobox` and its `listbox`.

I would like to have never needed to implement this JavaScript to begin with (or rack my head trying to figure out why these issues happened). **For this reason, I would _desperately_ ask that however this standard finalizes (if it finalizes), developers be given a way to _completely_ disable focusability on Custom Elements.** Being able to say, "This element is `[tabindex="-1"]` by default",  is **_not sufficient_** to resolve the above dilemma.

## Aggressive Browser Defaults Need Overrides

Sidenote, but still relevant: When browsers lowkey go against the standard by trying to fix developers' a11y mistakes (e.g., by making styled `ul`s no longer `list`s, or making all scrollable containers focusable) instead of telling devs to fix their mistakes, they inevitably produce other problems. This gives those who take a11y seriously a harder time (while leaving other devs' broken apps still broken overall).

Ideally, browsers wouldn't need to do this. But if they're going to do it anyway, I believe the standard needs to give developers a way to break out of these defaults (like being able to explicitly apply `[role="list"]` when appropriate) so that they don't have to write more convoluted code (like what I described earlier for the `combobox`).

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

Message ID: <WICG/webcomponents/issues/762/5969838249@github.com>