919711 - [a11y] Make CodeMirror more accessible

Status: RESOLVED FIXED

(DevTools :: Source Editor, defect, P2)

Description

[Brian Grinstead [:bgrins]]

Accessibility support in CodeMirror is not great.  I've been researching what changes would be required to add screen reader support to CodeMirror.  I have documented some of my findings here: http://bgrins.github.io/codemirror-accessible/.  I found a way to make selection movement work by updating the contents and selection of the focused textarea that CodeMirror is using behind the scenes.

I'm open to feedback about the implementation.  I'm particularly interested in feedback from someone who has accessibility experience and and who could comment on if it seems suitable (see the live demo on the project page).  I outline more details on the project page, and added a screencast with a quick demo.

This implementation is not ideal, since it relies on a timeout to help NVDA catch changes.  So we need to find a better way to do this.

Also, see https://bugzilla.mozilla.org/show_bug.cgi?id=816756#c39 for more information.

Comment 1

[Brian Grinstead [:bgrins]]

A comment from Max Li via email:

> Tried this out a bit. The basic functionality does seem to work. With 
the current approach, you can't read back the current line you're on 
(e.g. in NVDA, pressing insert+up (depending on keyboard layout) should 
read the current line you're on). I wouldn't be surprised if other 
similar things wouldn't work either. Also tried quickly using JAWS (the 
most popular commercial screen reader on Windows). It does seem to work 
with the demo'ed functionality. It does seem to exit from editing mode 
randomly when pressing the up or down arrow rapidly. I vaguely remember 
having this issue in Orion; setting an ARIA role of "application" either 
on the focused element or a container of it would probably fix it.

> With respect to the moving in/out of the keyboard, using Escape to blur 
the editor is probably not a good idea. I  think both NVDA and JAWS use 
escape for their own purposes. The (somewhat suboptimal due to 
discoverability) option taken in Orion was to follow the ARIA Guide and 
use Ctrl(+Shift)+M to move in and out. In any case, you'd probably have 
to consider what keys aren't consumed by the most common screen readers.

> Max

Comment 2

[Anton Kovalyov (:anton)]

How's the progress going? Any blockers?

Comment 3

[Brian Grinstead [:bgrins]]

(In reply to Anton Kovalyov (:anton) from comment #2)
> How's the progress going? Any blockers?

I have not made any more progress on this.  The issue is that, at least with NVDA, it does not respond well to the textarea value changing right before setting the textarea selection.  Meaning that it intermittently fails when trying many different solutions that *don't* involve keeping the entire contents of the textarea in tact at all times and allowing input directly into the textarea.  This requires large changes in the internals of CodeMirror.  I will spend some more time looking into it unless if anyone else wants to.

Comment 4

[Rob Campbell [:rc] (:robcee)]

cc'ing Marco.

Comment 5

[Marco Zehe (:MarcoZ)]

Yes, role="application" may be a good way to go here, to prevent screen readers from exiting their focus/forms modes. Also, it might be worth looking at what other rich edit controls are doing, such as the Microsoft Office Online, TinyMCE Editor or CKEditor. The latter two are using contentEditable instead of a textarea, and Microsoft may be using some hybrid markup, too.

Comment 6

[Marco Zehe (:MarcoZ)]

The code editor is an important part, but without labeling the other stuff first, this should be following. Setting to P2 for now.

Comment 7

[Florian Beijers]

More and more editors are using the codeMirror approach behind the scenes. That is great for this project, but as long as these access issues aren't taken care of that also means more and more places are using inaccessible code editors. I did find a very accessible implementation of a code editor in the Stanford public online courses like the cs101 course. 
Right now the link in the OP's post works a lot better than the standard implementation of CodeMirror. Perhaps at least adding that patch upstream would at least lessen the problems for screenreader users even if it isn't a complete fix yet, because frankly the editor is quite useless the way it is now when you use a screenreader. :)

Comment 8

[Brian Grinstead [:bgrins]]

(In reply to Florian Beijers from comment #7)
> More and more editors are using the codeMirror approach behind the scenes.
> That is great for this project, but as long as these access issues aren't
> taken care of that also means more and more places are using inaccessible
> code editors.

The CodeMirror author commented about switching back to contentEditable here: https://bugzilla.mozilla.org/show_bug.cgi?id=1088804#c12.  I'll follow up there to see if there has been any progress.

Comment 9

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 919711 - Add a CodeMirror inputStyle to make it accessible; r=bgrins.

This is by no mean finish, only a patch to test
that it works as expected.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/979503384353
Add a CodeMirror inputStyle to make it accessible; r=bgrins.

Comment 12

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/979503384353