Accessibility: Console keyboard focus is trapped

[snide]

Problem

The focus state is trapped in any of our code editors.

• Users can't use the usual tab / shift-tab to move throughout the form because that's use for indentation.
• Users also can't tab through the options underneath the "Wrench" icon menu.

Proposed solution

The code editors we use should set the "ESC" key to unfocus the cursor on the editor. Futher, we should use an advanced settings accessibility toggle within Kibana to turn off indentation tabbing if set to True.

[cjcenizal]

@snide @aphelionz @timroes

How about we adjust the UX slightly:

1. Tab to focus on the editor element as a whole.
2. "Enter" key enters the "edit" mode, so now all keypresses affect editor content.
3. "Esc" key exits "edit" mode, restoring focus to the editor element.

This makes the actions to enter and exit symmetrical and explicit, so users are less likely to unexpectedly end up in a "tabbing cul de sac".

I looked for an ARIA role which could communicate this interaction model, but couldn't find anything. The closest thing I could find was the textbox role, but that doesn't suggest any special interaction model.

Anyone have any thoughts on how can we communicate to the user that they can interact with this component with enter/esc keypresses? Maybe we can display text instructions once you focus on the element, which we can reference via aria-describedby?

[snide]

@cjcenizal Assume enter wouldn't be needed for mouse users? They'd just click in correct?

[cjcenizal]

Right, I think people should still be able to just click on it to enter the editing mode.

[timroes]

@cjcenizal I find the idea very good! I guess the textbox role would be fine. Maybe the application role might be an option, but I am not sure if that is not "too much". I would also show a description below the box once it's focused and reference that with aria-describedby.

[timroes]

Waiting for reviews on #13339 to reuse it in this issue.