Update explainer heuristic. Consider ignoring meta, alt/option, control keys.

[robdodson]

Current behavior

This is currently what's in the explainer example heuristic

The heuristic used to decide the current modality should not be defined normatively. An example heuristic is to update modality on each style recalc: if the most recent user interaction was via the keyboard; and the key pressed was either Tab, Shift + Tab, or an arrow key; then the modality is keyboard. Otherwise, the modality is not keyboard.

The above snippet does not match the polyfill or the experimental implementation in Chrome—both of which turn on keyboard modality if focus was proceeded by any key press (including meta and modifier keys).

Proposed behavior

@alice and I were discussing if this behavior should be changed so any key would trigger keyboard modality unless the keypress included a meta key (⌘ Command / ⊞ Windows), option / alt key, or control key.

Modifier keys, like shift, would still trigger keyboard modality (for instance, shift + Tab).

The example heuristic text would be updated to something like:

The heuristic used to decide the current modality should not be defined normatively. An example heuristic is to update modality on each style recalc: if the most recent user interaction was via the keyboard; and the key press did not include a meta, alt/option, or control key; then the modality is keyboard. Otherwise, the modality is not keyboard.

TODOs

• Update the explainer's example heuristic.
• Update Chrome's :focus-visible impl. to match.
• Update :focus-visible heuristic in CSS4 spec.
• Update the polyfill to match.

@alice, please let me know if I'm mistaken about any of the above 😸

[alice]

I think that example heuristic text looks good 👍

I can work on updating the Chrome native implementation and adding some WPTs.

[robdodson]

Assigning to myself to create CRBug for chrome impl.

[bradkemper]

The option key on Mac doesn’t seem to be triggering keyboard mode.

In Safari, there is a checkbox setting to “press tab to highlight each item on a web page (including links and all form items, instead of just text fields and pop ups (drop downs)). Using the option key reverts that behavior temporarily. If the checkbox is not checked, using the option key will temporarily make it act as though it is checked.

Chrome on Mac has a similar setting.

But using the option key in this way isn’t showing the focus ring the way it does without it.

[alice]

The option key on Mac doesn’t seem to be triggering keyboard mode.

To clarify: do you mean that the expected behaviour is that [option] + [tab] on Mac should behave identically to [tab] on its own, and currently it does not behave that way because we treat [option] + [tab] as though it might potentially be a system shortcut?

[skrichten]

The option key on Mac doesn’t seem to be triggering keyboard mode.

To clarify: do you mean that the expected behaviour is that [option] + [tab] on Mac should behave identically to [tab] on its own, and currently it does not behave that way because we treat [option] + [tab] as though it might potentially be a system shortcut?

Pretty sure that is indeed what @bradkemper is saying. I don't know what the solution is, Safari is so annoying. I ran into this today and it caused quite a bit of confusion/frustration for me. Sorry, I know this is an old issue, but it would be nice to see some solution or at least a note about it in the documentation. I did not expect the option key to cause the tab to be ignored.

[bradkemper]

Yeah, it is more of a Mac thing than just Safari. The tabbing behavior on Macs is usually just text fields, and the browser setting is to switch that to tab to more things. Holding the option key down while tabbing temporarily causes the tabbing behavior NOT indicated by the setting. So option tabbing should be treated the same as normal tabbing for this heuristic.