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:notifications@github.com]
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