Does anyone know if there's anything resembling a standard for keyboarding around editable fields? The kind you can't tab out of because your tab is stolen by the app to create a tab character? Thanks

WCAG seems to be very vague on this point: “ if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.” w3.org/WAI/WCAG21/qui… I'd treat Esc as a standard exit method, not sure what else.

Someone at Elastic showed me what they do for a funky editable area... users have to explicitly hit Enter to turn it into edit mode, Esc to turn that off (they then would have to tab out, so focusability is never lost... I kinda like this).

AFAIK taking control of the tab it is fairly rare, and the controls in native apps tend to be OS specific. “Components” like TinyMCE use things like Alt+F9, but I’m not aware of a standard. Does seem like something ARIA should cover, somewhere? /CC @jnurthen

It's basically used in code editors. Right now I'm dealing with a fake-SQL-query input, but of course you've got stuff like CodePen and other tabbers.

Not just code editors. Any rich-text editor either supports Tab for text indentation or has to deal with annoyed users who miss that function. (I've accidentally sent incomplete emails because I've used tab for indentation in Gmail & accidentally moved focus to the Send button!)

me in Jira (so many incomplete tickets) and me in everything with the esc key because vim trained my fingers lol

I’m not sure if this will help, but an alternate approach may be to allow Tab to move the focus point but assign another keyboard shortcut to inserting a tab. For instance, to insert a tab in a table cell in Word, you have to press Ctrl+Tab / Option+Tab.

Ctrl-Tab is always eaten by my browser, it's how I switch tabs. I'm not sure JS can override that? I thought browsers get the first go?

That’s a fair point. In that case, perhaps one might need use a different shortcut to insert a tab.

I'm wondering, if there were two tests with a decent number of users, which would fly better: keep tab doing tab in the input but change the mode like in vi, or let tab move focus and use something new to make tabs. Colleague said "spaces" but, ug.

From the perspective of a novice user, the worst-case scenario for the first option is that you end up with a keyboard trap, while the worst-case scenario for the second option is that they can’t insert a tab character into the field.

So check out what Elastic is doing... I kinda like the idea: github.com/elastic/kibana… so they tell users what they can do which is always good.

Oh, I kinda like that!

Yeah it's winning the mental election, at least for a current issue I'm having.

I’d be inclined to agree. That option seems to have the fewest overall downsides.

Yep. Basically: don't let someone get *in* to the trap without them having been explicitly told how to get out of it. And if you do nonetheless get there, Esc for escaping a focus trap (e.g., a modal) is the closest to a standard behavior that we have.

Our train of thought on that: no additional key to enter edit mode: easy to miss how to exit via escape. Mouse users uneffected by the change. Can keep tab key for common inserting tabs. Downside: one additional key press needed to start editing when focusing via keyboard. /1

Alternative discussed solution: if tabbing into input, another tab will bring you out. Tab will only insert a tab, after at least any other key was pressed (user started typing in input). Downside: very implicit behavior that's also nearly impossible to put in help texts /2

yeah that second one would be counter-intuitive to my fingers

VS Code has some documentation on what they do to mitigate tab trapping:

huh, another ctrl-m use. Only time I've seen this outside the unknown-to-users method to pick up items for drag and drop.

I think that method is better (than the one I suggested) for (web) apps where the editor is the main purpose of the app. Wouldn't suggest that enter-to-start-typing for that. But it might be a better, more explicit solution for apps with just minor tab capturing inputs.

the screen reader testing is a plus

Aha. So it turns out that's exactly what this editor is using (Monaco though). Not that users would know. So perhaps in this case, since some functionality is already built in, that the issue is that users simply need to be informed about ctrl-m. Took me a day to discover docs!

Yeah, this is really the universal problem with web apps & special keyboard sequences. You have to stay away from OS key combinations AND browser key combinations. And you have to work in all OS with different conventions. Pain in the arse.

We had a somewhat similar issue at Pearson with a math palette, where we needed a sane way to jump focus between the math input and the button palette. I suspect this stuff will crop up more.

alt+f9 is a new one to me.