Keyboard only: how to escape textarea effectively and move to next focusable?

[jasonday]

A couple of thoughts:

• There should be an option to turn off [tab] capture.
• There needs to be a keyboard only way of navigating away from the textarea to the next focusable.
  • Rather than change default browser behavior, [tab] should move to the next focusable and a special [tab]+[something] key combination should insert the tab space into the editor.

[LeaVerou]

I strongly agree there should be a keyboard-only way of tabbing through to the next element, but strongly disagree that it should be just Tab, and that Some other key + Tab would enter spaces. This would be terrible for usability:

• The most common case of tabbing in a code editor is to indent. This proposal would make the most common case more cumbersome to accommodate the much rarer case, a usability antipattern. Especially given that efficiency is important in writing code, this would be catastrophic for the editor's usability.
• It is also externally inconsistent: No code editor, on the Web or native, works this way.

It would be interesting to see what other editors use, so that we can be externally consistent and use the same combination, if one exists. If there is none, then we can pick our own (Some combination of keys + Tab).

[AgentEnder]

@LeaVerou vs-code and any microsoft products that feature text entry typically use the keystroke alt, followed by tab. We could implement this, but it would be important to maintain that it is 2 keystrokes so as to not override alt+tab.

https://microsoft.github.io/monaco-editor/ might be a good base here, since it is the editor behind vs code.

---

I no longer recommend this approach, in chrome at least this is used to tab through the action bar.

I would be against the following:
alt+tab: Overrides a common shortcut
ctrl+tab: Overrides a less common short cut, tabbing through browser tabs
alt tab: Overrides moving to action bar with alt, potentially an accessibility concern.

[jasonday]

Note:

• [tab] and [shift + tab] currently have the same behavior in prismJS
• I don't necessarily agree that keyboard users expecting tab to navigate to next focusable is a small use case
• Rich text editors often do not capture [tab] instead relying on a button to indent
• Workarounds
  • Use [esc] to toggle or back out of [tab] capture mode. This key would be discoverable by keyboard/assistive tech users as it's a common pattern for escaping/closing the current "thing" such as a modal, tooltip, etc.
  • It appears that some of the major rich text editors, such as CKEditor, do not capture [tab]
  • VS Code uses [ctrl + m] to switch between 'modes' - this would likely need to be communicated somewhere

[jasonday]

• Ace9 discussion: Accessibility: Ace traps the Tab key, so keyboard users cannot escape ajaxorg/ace#3149
• In the version 1.0 of WAI-ARIA recommendations, [ctrl + m] was recommended, but that recommendation is not in the latest version: https://ux.stackexchange.com/a/41425/31485

[AgentEnder]

@jasonday it's worth noting that this is a code editor, not a rich text editor. I agree that rich text editor's do not typically capture tab, but I have not seen a code editor that does not.

Looking at the Ace9 discussion I could see the 4 step behavior noted as working.

1. When keyboard focus first goes into the editor, it sets itself to non-capturing mode.
2. As soon as you type something, the editor goes into Tab-capturing mode.
3. Pressing CTRL+M switches between the two modes (as recommended by https://www.w3.org/TR/wai-aria-practices/#richtext).
4. Pressing Esc switches to non-capturing mode (seems like the kind of thing people might try if stuck with an interface).

That said, the discussion started 4 years ago and the current control on the ace9 site does not implement this pattern, so I'm not sure what the status of that incident is.

I did verify that [control + m] works in the monaco editor microsoft uses, I feel like that is a good path to go @LeaVerou . Adding escape as another method to set tab mode to move focus would be a nice touch.

[LeaVerou]

I am mildly opposed to introducing a mode for this, as a non-visible mode is a usability antipattern [NNGroup], and making it visible adds another UI component that users have to customize to fit their website. And it's well established in the literature that even visible modes lead to mode slips.

@jasonday As @AgentEnder correctly points out, rich text editors and code editors are different use cases (though the lack of Tab capturing has given me a lot of pain in RT editors). Note that I said it's a rarer use case, not a "small" one. I.e. out of 100 tab presses in a code editor, how many are likely to be pressed with the intention of indentation and how many with the intention of changing focus? I'd argue that the focus change ones are a small minority. It is an important use case, that needs to have a solution, but for efficiency, the common case needs to be easier/faster to perform.

Btw, I noticed that on a Mac, Alt + Tab works on my Atom Editor, as well as CodeMirror, and even Prism Live! However, we do need to come up with something for Windows, since Alt + Tab is taken over by the OS there.

[jasonday]

non-visible mode is a usability antipattern [NNGroup]

I'd argue that this article does not take accessibility into consideration and a 'mode slip' is unlikely to have negative consequences, whereas the keyboard trap is a more serious failure [WCAG 2.1.2].

In my opinion having a mode is a compromise, and is less likely to create havoc in comparison to other potential solutions.

[LeaVerou]

This article is not the only one talking about this; NNGroup is just more easily searchable. It's well established in HCI that modes are often a usability antipattern and that mode slips are common.
Sometimes, modes are unavoidable, or an acceptable tradeoff between efficiency and (UI) safety. However, in this case, there are solutions that enable accessibility without compromising usability, so I'm not sure why you are insisting on Ctrl + M. How does a modifier + Tab create "havoc"?

[AgentEnder]

Modifier + Tab might be hard to find a workable sln here, as we want to keep regular tab as is. [control + tab], [alt + tab] are both commonly used shortcuts. The other worry for me would be discoverability of the command. Simply having the command does not solve the accessibility issue if those using screenreaders cannot find the command as well.

I agree about the danger of modes and them not being obvious, vs code and visual studio both suffer from the ease of disabling [control + space] for intellisense accidentally.

That said, if we did go with [control + m] here it would be externally consistent. A simple indicator of the current tab mode could be using an outline indication of when tab will move to the next element. For example, if when you hit tab it would move to the next element an outline would be displayed. This would be similar to how elements normally behave, with the outline indication of focus state. User's are definitely likely to hit escape when trying to move on, which was why I agreed with adding escape as a way to always move to this mode rather than a toggle.

All this said, it is your project and I don't want to over encroach. I'm just not sure what the better option would be here.

[bricebou]

Hi,

Any updates on this issue ?

Thanks :-)