Initial focus placement for dialog element: terminology for first-focusable vs first-tabbable

[scottaohara]

Per the dialog initial focus proposal, there was a lot of discussion in the orginal Google doc about the use of

focus the first tabbable descendant of the <dialog>

The reason for this is because of the user setting on macOS where not all elements that would otherwise be tabbable are by default. The following are just a few key instances of comments made in that thread to allow the conversation to continue here as necessary:

@westbrook

"first tabbable" can be different in Safari than in other contexts. Do you think there is a way that we could define this as an element that could be normalized across browsers in some way? Possibly by defining it as the set of elements that could be tabbed to...

@cookiecrook

If you're looking for a term that can replace "tabbable," I think "first keyboard focusable" may do it… But is it clear this means "keyboard focusable [by the user, not script]"? Perhaps "first user keyboard focusable element" or the more clear but verbose "first element that is keyboard focusable by the user"?

In Safari, a user can always focus any of the same elements that are "tabbable" in other browsers; but depending on the user's setting, they may press Tab or Option+Tab to get to those "keyboard focusable" elements.

"keyboard focusable" ~= "tabbable" and/or "option-tabbable"

[Note: "keyboard focusable" would not include tabindex=-1, but a more general "user focusable" term may, because you can click to focus tabindex=-1.]

I'd prefer a term other than "tabbable" if possible, but could live with the defined term if no better name arises in conversation.

@aleventhal

Do folks like the term "keyboard-focusable"? (Not sure if it needs a hyphen)

@scottohara

i think that's an alright term to use / define so long as it clearly indicates that in a group of controls where all are keyboard-focusable, but only one is meant to be reached by the Tab key at a time.The use of the term 'tabbable' was meant to mitigate against initial focus going to an unchecked radio button, or an unselected tab in a tablist. Those are keyboard focusable, but just not by Tab key when there is another chosen element in the grouping. re: the tabbability of radios.

@cookiecrook

Something about being “In a keyboard focus loop” perhaps? I think the radio group itself (which acts like a composite widget) is in the loop. The arrow behavior actually changes selection, which pulls focus along with it. Granted it is an odd special case. A note may be required to explain radio in the definition of keyboard focusable. An update after further discussion with other WebKt contributors. Similar to my suggestion above but not identical: If the the first tab-focusable* element would trigger a scroll-to-visible, then the dialog should receive focus, not the first tab-focusable element.

::We're okay using the term "tab-focusable" with the acknowledgement that this only sometimes includes links. E.g. not by default in Safari, and not when the preference has been changed in Chrome or Firefox. The tab loop is different between browsers/settings, so the resulting focused element may be different between browsers. That's okay as long as it doesn't trigger an unexpected scroll in the dialog.::

WDYT?

---

Further discussion needs to occur on alignment with Gecko, Webkit and Chromium on allowing scrollable containers to receive keyboard focus. This being particularly important when there is no focusable elements within a scrollable container (e.g., <div style="overflow: auto; max-height: 300px>lots of static text</div>").

[josepharhar]

For "first tabbable" I am planning on using the "sequentially focusable" term in the HTML spec because it seems to refer to things you can focus to by pressing tab: https://html.spec.whatwg.org/C/#sequentially-focusable

[aleventhal]

Seems fine for now, but could sequentially focusable become confusing after focusgroup becomes part of the spec?

On Tue, Jun 7, 2022, 6:08 PM Joey Arhar @.***> wrote:

For "first tabbable" I am planning on using the "sequentially focusable" term in the HTML spec because it seems to refer to things you can focus to by pressing tab: https://html.spec.whatwg.org/C/#sequentially-focusable

— Reply to this email directly, view it on GitHub https://github.com/whatwg/html/issues/7710#issuecomment-1149222178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZUHPOFX2QOBHBVCTBLVN7B6TANCNFSM5QZYEWRA . You are receiving this because you were mentioned.Message ID: @.***>

[domenic]

Regarding the question of which issues in https://github.com/whatwg/html/pull/4184#issuecomment-1072536425 should be considered blocking for writing up a spec of https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#initial-dialog-focus-logic : "sequentially focusable" is the correct spec term here. This issue should be unblocked.

I don't believe the introduction of focusgroup (in whatever form it ends up) will change how appropriate the term sequentially focusable is, but maybe I'm missing something.

[aleventhal]

Do we think that "sequentially focusable" will become a confusing term once focusgroup is introduced? The items in a focusgroup are still sequentially focusable, but with the up/down arrow keys. Apologies for the bikeshedding :) Since "tabbable" is too device-specific, perhaps "in the primary focus cycle" ?.

[domenic]

I don't really see the confusion? They're still focusable in sequence, so the term "sequentially focusable" seems fine. Perhaps you could give an example of the code you think will be confusing?

Also, this is all very speculative, focusgroup is a proposal which hasn't been sent to the WHATWG yet, and I anticipate we can have the discussion of what to call focusgroup's terms when it is?