Accessibility for screen readers

[Menelion]

As per this discussion, Ace is totally inaccessible for screen reader users.
this highly impacts all visually impaired (especially, blind) developers which are quite numerous. And, as online courses are the most accessible learning form for such users, please make an effort to improve the accessibility of your great editor.
If I could help somehow (testing, patching, ...), I'm open to collaboration.
Thanks!

[pamelafox]

I just got a bug report from a teacher of a blind student going through our curriculum on Khan Academy. This is what the problem was specifically:
"For some reason, his screen reading software will NOT read the code he inputs when he is reviewing it with his arrow keys. The software DOES read his code as he inputs it, but will not read in the review process with arrow keys."
Has any investigation gone into better screen reader support since this issue was opened?

Thanks!

[gjtorikian]

I'd like to see if I can work on this, as it interests me for a variety of reasons. I'm curious to know what the expected technical behavior is. Like, is there a good source of information for what the DOM markup should look like so that a screen reader could process the information? Is an aria-label enough? I really don't know.

As @KevinB7 mentions elsewhere, it's probably possible to coat the current lines on screen with a DIV containing the underling information. IIRC, Ace calls these layers, and there's one for a bunch of different reasons:

Whether or not that's a good idea depends again on what the actual markup needs to be, though.

[Menelion]

Thanks @gjtorikian. Actually, the question is more difficult. I don't believe that aria-label will be enough because the input field contents is not read neither by arrow keys, nor when you, say, erase text with BackSpace. I wonder why that happens at all since if you use a plain textarea this doesn't happen. If we learn why this is so, we will be able to determine what (additional) markup is needed.

[nightwing]

I think input field is not read because textarea in Ace is used only for capturing input and usually remains empty.
Is there a way to trigger reading with javascript, e.g by setting aria-label on textarea or setting some text into textarea?
Ideally there would be a javascript api similar to chromevox so that we could do something like https://github.com/ajaxorg/ace/blob/master/lib/ace/ext/chromevox.js

[gjtorikian]

Is there a way to trigger reading with javascript, e.g by setting aria-label on textarea or setting some text into textarea?

It sounds like arrow keys are the primary navigation here. What if you listened for those on keyup and set the aria-label underneath the textarea?

[accdc]

Hi,
Actually ARIA won't work like this, aria-label only provides the label for designated role types, but it's not a typing alert mechanism.

I was asked if I could help out with this, and I'm happy to, but I'm not familiar with how the controls are being rendered and which elements are being interacted with. If you could point me to an online demo I'll be happy to check out the markup further.

In the meantime, you can sometimes use contenteditable container elements to achieve this behavior, such as
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20Simulated%20Edit%20With%20Right%20Click/demo.htm
The markup includes the requisite roles and attributes, though this one has an attached menu which may not be relevant.

To learn more about how ARIA works, the following training guide may be of assistance:
http://whatsock.com/training

Please let me know if there is a live demo of the editor and I'll be able to help further.

All the best,
Bryan

[Menelion]

@accdc, thanks Bryan!
A live demo can be seen here, for example. Sorry, I would like to give you a mode direct URL, but, it seems, there is no way. Just sign in (they accept Facebook and something else, or you can just sign up) and start any programming language course like JavaScript.
It seems that the Go playground also does use Ace but I'm not sure anymore.

[accdc]

Will do thanks. I’m working on several projects at the moment, so will try to have some details for you by Wed.

All the best,

Bryan

From: Andre Polykanine A.K.A. Menelion Elensúlë [mailto:[email protected]]
Sent: Monday, March 30, 2015 11:27 AM
To: ajaxorg/ace
Cc: Bryan Garaventa
Subject: Re: [ace] Accessibility for screen readers (#2164)

@accdc https://github.com/accdc , thanks Bryan!

A live demo can be seen here http://codecademy.com/ , for example. Sorry, I would like to give you a mode direct URL, but, it seems, there is no way. Just sign in (they accept Facebook and something else, or you can just sign up) and start any programming language course like JavaScript.

It seems that the Go playground http://play.golang.org/ also does use Ace but I'm not sure anymore.

—
Reply to this email directly or view it on GitHub #2164 (comment) .

[nightwing]

Online demo can be found at http://ace.c9.io/#nav=about, go playground uses a textarea.
In Ace we have textarea focused, which is used for capturing input and it's value is being reset after each keystroke. Visible text is not a part of the focused element, and selection is just a div. So we need to somehow set what screen reader says, based on the selection data which is not present in the dom.
We can't use contenteditable because of it's bad performance.

[nightwing]

What if you listened for those on keyup and set the aria-label underneath the textarea?

@gjtorikian sounds like a good plan. The question is when we need to set it, to trigger the screen reader.
Btw it might be interesting to take a look at http://www.typescriptlang.org/Playground it seems to handle this better than Ace but i am not sure how much better it is.

[accdc]

Thanks, that demo helps a lot.

So, from what I understand, the textarea is actually layered beneath the visibly displayed code on the Div layer? Is this correct?

If the textarea is hidden visually offscreen, is there any reason why it cannot include the same text as the styled layer? Textareas are already accessible to screen reader users. I'm referring to screen readers that support virtual offscreen models, such as JAWS and NVDA on Windows.

If you need to synchronize selection, you can do this in reverse if the visible layer has selected content, where you can then programmatically select the same text within the textarea:
http://help.dottoro.com/ljtfkhio.php

The same technique can be used in reverse if a screen reader selects text within the textarea, in order to visibly highlight the relevant text within the visible layer.

As long as the textarea is positioned offscreen beneath the visible layer, sighted users would never encounter it directly, but it would be accessible nonetheless, because both the visible content and offscreen content would be programmatically synchronized.

Also, the textarea does need a label too, which could be achieved by adding the aria-label attribute to the element.
E.G aria-label="Code editor"

As Google found out when implementing the Docs editor, ARIA methods for announcing textual content without providing access to it within a standard edit field are not reliable enough to be widely supported, nor can they convey critical information such as punctuation and correct upper/lower case feedback, as is needed for code editing by non-sighted screen reader users.

Please let me know if I've misunderstood how the control functions regarding the textarea field.

[nightwing]

Putting whole file into textarea will make editing unusably slow

[accdc]

I understand.

The issue you are dealing with, is that focus is not on a control that includes the content you are supposed to be editing, so an AT like a screen reader sees nothing when typing or interacting with that control.

Using a label will only set a form field label on that textarea field and won't convey any contextual information to the user when typing or navigating, and using a live region won't convey any contextual information either as would be needed for coding, so the options currently for making something like this accessible are very limited.

Basically, you need to get the screen reader to interface with an editable control that contains the text that should be edited, and on the web, the only two methods available for an RTF editing purpose are contenteditable or textarea.

This is why Google hasn't been able to figure out how to make this accessible using JAWS, because there is no way to force this interfacing to occur given the availability of current technologies. There is work being done to enable this functionality, not just on desktops but also on touch screen devices as well, but this is still down the road a ways, because it requires the control to tie into the native OS in order to tap into its editing capabilities.

Also, JAWS has a bunch of legacy code that scrapes the DOM for use in IE, so it doesn't tie into the Accessibility API as well as it does within Firefox, making things more difficult when using ARIA such as live regions for this purpose.

So it really depends on what you wish to accomplish. You might be able to replicate what Google has done for Docs and enable some level of speech announcement using screen readers such as NVDA and ChromeVox only within Firefox and Chrome, or you can use an offscreen control that can be interfaced for basic code editing by other screen readers such as JAWS in IE and FF even if at a performance hit. It's important also to keep in mind that JAWS holds the majority of the market.
http://webaim.org/projects/screenreadersurvey5/#primary

[nightwing]

and using a live region won't convey any contextual information either as would be needed for coding

What kind of contextual information is needed? Maybe we could give that by leaving only some of the text in textarea we already have.

So it really depends on what you wish to accomplish.

I am not sure about this, it depends on what people using Ace will need, but I think that if this introduces any noticeable performance hit, it should be opt in and disabled by default.

[zersiax]

I don't have a lot of experience in actually coding something like this, but I do have a few ideas for how to get around this problem.
The first idea is demonstrated here: https://github.com/bgrins/codemirror-accessible
CodeMirror uses a reasonably similar approach to how ACE does things, and the solution shown here, though not ideal, does make it a lot more useful.
A second approach might be to cut ACE out of the equation entirely. Aria-hidden the actual ACE editor and make an sr-only multiline edit field where code is displayed. Copy the contents of the sr-only multiline edit field to the actual ACE editor on blur. Not sure how much of a performance hit that would be though.

[ndarilek]

Any updates on this?

Also curious that no one has mentioned EtherPad. They're different domains, but the EtherPad accessibility story is somewhat better (though it doesn't do very well with adding style information to documents.) Might be a good reference to start with.

[ahicks92]

I am a blind programmer, primarily C++ and Python but dabbling in Rust. This also shows up in the Rust playground. I've opened an issue, rust-lang/rust-playpen#198
Aria live regions are a fail for this because the screen reader does not have the information required to tell that the intent is to read by character. Consequently, arrowing over i.e. space and new lines and such just says nothing at all, and many punctuation marks are read differently or require different settings to actually hear. Obviously this would render the editor useless for C++ or Rust or whatever, and Google Docs is already bad enough just for vanilla English text. While we do have the web speech API coming along, ChromeVox is used by almost no one and making us switch screen readers to your own custom implementation is analogous to saying that a sighted person has to switch OSes to use it.
So, what can you do? As far as I know you have three choices that might work but only two of them work everywhere:

• Use contenteditable. This is coming along. NVDA has some support for it in Firefox. The problem is that this support is buggy last I checked, and I don't think Jaws or anyone else has even started.
• Sync the editor with an invisible edit field so that it works visually, then use Aria (or something else) to hide the visual version. I know this has performance concerns.
• Finally, implement a toggle that turns the editor into a textarea.

Of the above options, the last is probably the quickest to code and almost certainly the one that's most likely to work everywhere. Doing anything else is going to require testing across probably 12 screen reader and browser combinations. For the last two, you can use an invisible (but visible to screen readers) link which opts in. It would be useful if the setting was remembered, however.

Finally, something has to be done about line numbers. The problem is that screen reader users have to arrow past them and they cannot be conveniently skipped. Every single control for code entry that offers line numbers has this problem, and one of my friends has taken to blocking the line numbers with Adblock+ rules because it is truly that annoying. Imagine if you printed the line numbers before the code, each on their own line. It's like that.

Putting them before the line of code makes the editing experience horrible. I'm not saying they're unimportant, but there needs to at least be a toggle that kills them if nothing else and this setting must be remembered.

CC @jcsteh, who might be willing to give us more useful input as long as I don't CC him too often, and thus far I don't think I have.

[jcsteh]

Contenteditable is probably the way to go. If you're seeing bugs with NVDA in Firefox, we probably don't know about them and they need to be filed. AFAIK, JAWS does support contenteditable in Firefox at least and probably IE as well. That said, it's true that textarea is probably simpler to implement and test, but it does mean an accessibility specific mode and it means you'll never get any kind of semantic/formatting info, which kinda sucks. I guess that isn't a huge problem for a code editor. Regarding line numbers, if the line numbers and code are in two separate columns of a table, you can walk through the lines only using the next and previous row commands in your screen reader. This is how I review code on GitHub, for example.

[ahicks92]

On line numbers, yes, a table technically works. GitHub does it. But I reach for the View Raw link very quickly. I don't like the ergonomics of table navigation for reading documents. But the better question is how you handle selecting? Maybe there's a way to do it, but I'm not aware of one that doesn't also have the screen reader grabbing the line numbers. Last time I used it, Jaws was even worse in this aspect of it: it used to copy things like the beginning of lists by inserting what it would have said into the clipboard, so you ended up having to fall back to weird tricks or changing settings for an actually faithful copy. If we are going to seriously consider this approach, we need to answer both questions.

I'm not sure it matters though, as presumably you have a control for editing and not a separate view mode. I will say that having the info of which line I am on available would be helpful, but not if it's announced all the time and not if it's done as most code editing controls I've seen do it.

The last time I used something that used contenteditable, it was a memorable experience and not in a good way. Admittedly it has been a while. Nevertheless, I still have weird bugs that are hard to reproduce in Thunderbird, and was under the impression that the Firefox contenteditable editing code and the Thunderbird rich editing code are the same. If this is in fact the case, I should put actual effort into figuring out how in the world to make reproducible test cases. It is of course possible that this will never hit those bugs as presumably code doesn't need nearly as many rich text features. I could be wrong about them being the same thing in the first place, of course.

[ignacevdv]

Please take a look at www.codebender.com and make a profile and try to add and edit the code into the codefield.
I've problems with this site to editing my code for arduino projects. The method of copy and paste from a plaintext as NPP or Notepad doesn't work at all.
I would be happy when it will works fine using my JAWS for Windows. All of the webbbrowsers I was tried doesn't give me a solution. I think when there is a goodwil, we will have a solution at all to continuing our projects as blind programmers and users of pc's/portables/smartphones/....
Many thanks to give it a try for us as blind programmers and users.
Many thanks in advance!

[timhunt]

I've been thinking about this in the context of making CodeRunner (http://coderunner.org.nz/) more accessible.

I think there are two main issues:

• ACE is no good for screen-reader users, and fixing that is hard. They would be better with a plain text area.
• ACE eats keyboard focus. If you tab in, you can't get out, because Tab and Shift+Tab are the natural shortcuts for Indent and Outdent.

What do people think of this solution:

• No change at all if you enter the editor by clicking with the mouse, or touching a touch-screen.
• But, if you attempt to transfer focus into the editor any other way, then you don't get to the editor. Instead, the editor is covered by a light-box with two links:
  • Activate code editor
  • Activate plain editor
• You can either tab through these links to get to the next focussable element on the page ...
• or if you activate one of these links (e.g. by pressing enter) you get into the editor.
• When in the editor, if you press Escape, you get back to the light-box, so you can either continue tabbing thorugh the page, or switch to the other type of editor.

If other people think this sounds like an OK idea, I could probably have a go at coding it (although I have not contributed to ACE before).

Reasons I like this:

• Because you have used Enter to get into the editor, it is reasonably natural to use Escape to get out. (But it may also require some help.)
• No extra UI clutter normally visible on-screen for switching editors - something most users will rarely do.

Comments please?

[sukiletxe]

Only problem: we blind users also use touch screens! I wouldn't code
anything large with them, but who knows...

[timhunt]

Thanks for the feedback @sukiletxe. Just to help me understand this better: are you saying that you would use touch to move input focus into a code editor area? And, if you did, you might then need to use Tab to move keyboard focus out again? Thanks.

[gtritchie]

Ace isn't totally inaccessible to screen readers, not sure if that's the result of improvements in screen readers and browsers, or work having been done in Ace, or both.

For example, with Kitchen Sink, using Chrome on Windows-10 with NVDA, as I navigate up/down with arrow keys, the current line is read. If I go left/right, then the characters are announced. It will also announce small selections, and characters as I type them.

Not perfect, but better than being completely inaccessible as described when this issue was first opened.

There are a variety of quirks and problems, though. especially with specific screen reader / browser / OS combos.

Chrome / Chromium on Mac with VoiceOver has an issue that will cause the wrong line to be read. This also impacts VSCode, though less often due to their use of keeping more lines at once in the hidden text area. This is a long-standing Chromium on macOS issue: https://bugs.chromium.org/p/chromium/issues/detail?id=912689

Safari / VoiceOver on Mac doesn't read character-by-character when left/right arrowing through text. #4150

FireFox / NVDA on Windows: left/right arrowing through text causes NVDA to read a single letter of the enter line over and over.

Probably others, haven't tried JAWS / Narrator.

[celtichawk]

I'll chime in and give this a nudge since I've been talking with someone bout this since they use this editor and I was made aware of it.

In this implementation, on Orca and Linux, I don't get the above described behavior. It does not show up as a text field and does not read the text in any given field for me under Firefox however using the Ares MUSh 0.96 web portal that uses this text editor however.

[BlindHunter95]

It's been almost 2 years, and nothing has been done about this. I'm not expecting this to be fixed immediately, but I sort of hoped in 2021, when the issue at least had a few eyes on it, that something would've changed. The amount of projects that depend on ACE, and thus are not accessible, are many.

[andrewnester]

@BlindHunter95 there is some work done by the team to improve Ace accessibility, for example, #5008

Unfortunately, we don't track this specifically as a project on GitHub, therefore some lack of transparency. But in general, accessibility topic is on the team radar and we should be seeing more improvements

[akoreman]

We've made a bunch of changes to improve accessibility, they can be enabled by setting the enableKeyboardAccessibility option to true. Verified that Ace content is now read by the major screen readers when keyboard navigating through the code in the editor.

[sukiletxe]

Is this setting enabled by default? If not, is how to do so clearly stated to the user when visiting a site which embeds ace?

[akoreman]

It has to be enabled when by the embedder when embedding Ace, when the embedder enabled it, no work is needed from the end user.

[sukiletxe]

OK thanks! Is it enabled or disabled by default when embedding it? Can it be enabled by default, or the docs and examples modified so that it is enabled there?

[akoreman]

It's disabled by default, to not break embedders who already built a11y improvements on top of Ace before this option was released.

We haven't modified the docs, but that's a good point, we should :)