Accessibility: Ace traps the Tab key, so keyboard users cannot escape

[timhunt]

I have split this out from #2164. That issue is really about the fact that screen-readers can't read the editor contents. I want to talk about a simpler accessibility problem:

If you have Ace in a form, and you are tabbing through the form from field to field, then once you get into Ace, you are stuck, becuase then Tab indents the current line of code (which is very natural). This is a problem for us, and the best solution I have been able to come up with is this:

We introduce two modes for each instance of the editor:

• Tab-capturing mode: Tab and Shift+Tab indent/outdent.
• Non-capturing mode: Tab and Shift+Tab move keyboard focus to the next/previous control.

Given that, the behaviour is as follows:

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).

Due to 1), you can just tab your way through the whole form without getting stuck, as you would expect. Due to 2), once you are typing code, Tab indents the current line, as you would expect. 3) and 4. Make it possible to escape.

This is not perfect. I see some issues: Is this discoverable for new users? Shoudl there be a visible (or auditory) indication of which mode you are in? I feel that an indication might be good. On the other hand, taking up any screen-space, or having the screen-reader speak anything (when you want to concentrate on what you are typing, or where you are in the form) seems undesirable. If the behaviour was natural enough, it would not matter.

If people like this suggestion, I am happy to try coding it.

[nightwing]

This idea sounds interesting, and will be useful as an optional extension, i am not sure about enabling it by default since many sites have their own way of navigation between elements, e.g. on Cloud9 there are shortcuts to focus specific elements like file tree or terminal, and ctrl-cmd-arrow to switch focus between editor panes.

[timhunt]

Thanks for the feedback.

[asgeir-inspera]

This sounds like a good solution.

[eah13]

@timhunt did you end up coding this up? We'd use it either directly in our fork or as an extension. Happy to do our own code extraction if it's open somewhere and you don't have time to clean it up.

[timhunt]

Sorry no - at least not within Ace. We were using Ace inside the CodeRunner question type for Moodle, and it turned out to be easier to implement what we wanted in the glue layer: https://github.com/trampgeek/moodle-qtype_coderunner/blob/master/amd/src/aceinterface.js.

However, you are welcome to copy any of that code.

[cayhorstmann]

I am running into the same issue with Ace, and this is the workaround that I came up with.

Use the setCommandEnabled function from https://stackoverflow.com/questions/24963246/ace-editor-simply-re-enable-command-after-disabled-it

Then configure the editor like this:

        editor.on('focus', function() {
          setCommandEnabled(editor, "indent", true)
          setCommandEnabled(editor, "outdent", true)
        })

        editor.commands.addCommand({
          name: "escape",
          bindKey: {win: "Esc", mac: "Esc"},
          exec: function() {
            setCommandEnabled(editor, "indent", false)
            setCommandEnabled(editor, "outdent", false)
          }
        });

It works tolerably well. Hit Escape and Tab/Shift+Tab, and you escape the Ace editor and the next/previous focusable element gets focus.

[mayilvahanan1]

Using Ctrl + [ instead of Shift + Tab and Ctrl + ] instead of Tab works on ace editor so just removed tab command and no trap now
aceEditor.commands.removeCommand(aceEditor.commands.byName.indent);
aceEditor.commands.removeCommand(aceEditor.commands.byName.outdent);

[Proko8]

On Mac I was able to use Option + Tab to escape

[akoreman]

in version1.17.0 we introduced an option to prevent focus trapping. See #5114 for more details.