Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
timhunt opened this issue Nov 25, 2016 · 9 comments
Closed

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

timhunt opened this issue Nov 25, 2016 · 9 comments

Comments

@timhunt
Copy link

timhunt commented Nov 25, 2016

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
Copy link
Member

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
Copy link
Author

timhunt commented Dec 2, 2016

Thanks for the feedback.

@asgeir-inspera
Copy link

This sounds like a good solution.

@eah13
Copy link

eah13 commented Jul 18, 2017

@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
Copy link
Author

timhunt commented Jul 19, 2017

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
Copy link

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
Copy link

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
Copy link

Proko8 commented Mar 19, 2021

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

maxpatiiuk added a commit to specify/specify7 that referenced this issue Aug 5, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Aug 22, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Aug 22, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Oct 4, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Oct 19, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Nov 8, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Nov 20, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Dec 7, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Dec 27, 2021
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
maxpatiiuk added a commit to specify/specify7 that referenced this issue Jul 1, 2022
Esc disables Ace's focus trapping and reenables the default browser
behavior for the `Tab` and `Shift+Tab` keys.

On macOS `Option+Tab` and `Option+Shift+Tab` seem to work too

See ajaxorg/ace#3149 (comment)
@whazor whazor added this to To do in Accessibility Mar 1, 2023
@akoreman
Copy link
Contributor

akoreman commented Apr 12, 2023

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

Accessibility automation moved this from To do to Done Apr 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

10 participants