Accessibility Bug - User can not move focus through editor lines logically with screen reader.

[mstelten]

When using Narrator screen reader, and Edge browser, the user can not logically move through the editor lines in Item mode. After entering item mode, focus goes through all of the line numbers (1,2,3...) before then going to the actual text on those lines. It should logically go to the line number, then the text on that line, then the next line, and so on. This is due to the structure of the DOM with line numbers being in their own div that comes before the container div of the line text. This makes it very difficult for a user using a screen reader to utilize the Ace Editor.

[nightwing]

Monaco editors sets aria-hidden="true" on the gutter element. Would that help here?

[mstelten]

Yes, I tested that out, adding it to the gutter container, and it works great! I am able to use Narrator Item Mode and get into the actual line content skipping the line numbers. I think it would still be ideal to have the line numbers included for the visually-impaired users, but that would take a lot more work to achieve.

[eah13]

@nightwing thanks for #3345. We made that same change to increase accessibility ourselves, but ultimately provided an option to disable Ace because we just couldn't fix enough of the problems (e.g. #3149).

It should logically go to the line number, then the text on that line, then the next line, and so on.

@mstelten would providing a label=[line number] to each row accomplish this for your reader? Depends on whether the label would clobber reading the content of the line I suppose. I could also see the need for a hotkey or mode to read lines or not, since line numbers aren't always relevant to the user.

When researching this a few weeks ago, the age of and lack of progress on #2164 kind of convinced us this might be a #wontfix for all intents and purposes and so we're shopping for a fork or alternative with better a11y. Not a lot of options from what I can see. And swapping out our editor would be a huge pain so if we can make incremental improvements I'm all for it.

I've been testing with ChromeVox and was able to make some core improvements to the non-Ace parts of our site but am still a screen reader/a11y novice.

[nightwing]

@eah13 tab key is needed for indenting, if you are using ace for editing text you can just remove it, for code you can add your own shortcut for exiting from the editor, it is useful not only for a11y, but depends on application and ace can't pick one for all.
If you want to trigger the default browser behavior, you can do something like

// for mac
editor.commands.bindKey("cmd-k tab|cmd-k shift-tab", editor.commands.byName.passKeysToBrowser); 

For chromevox we used to have an extension, which have been removed due to licensing issues https://github.com/ajaxorg/ace/blob/v1.2.3/lib/ace/ext/chromevox.js
https://rawgit.com/ajaxorg/ace-builds/v1.2.3/demo/chromevox.html
we could try to restoring it if it is helpful for you.

As for lack of progress on #2164, we are planning to work on improving accessibility of ace and cloud9 soon, but unfortunately browsers still do not have a good api for accessibility, so getting that work without breaking the normal workflow of the editor is not going to be easy.