freeCodeCamp: Contents of editor can not be reviewed by screen readers

Challenge Say Hello to HTML Elements has an issue. User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2976.0 Safari/537.36. Please describe how to reproduce this issue, and include links to screenshots if possible.

My code:


        <h1>Hello</h1>

Tried both the free open source screen reader NVDA and also the commercial JAWS for Windows. Neither screen reader is able to review the text in the editor by character, word, etc. If you press CTRL + a to select the text then the screen readers are able to read the text. This is currently quite unusable for blind and visually impaired screen reader users.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 61 (32 by maintainers)

Most upvoted comments

Just saw that this is the actual main issue. Since I have four screen readers, assuming I can follow the instructions to get this on my machine, I will be happy to test this.

To cut down on the learning curve if you are interested in obtaining a screen reader to play with, please see below. And this is not meant as offensive in any way at all, but someone with site is not going to use a screen reader quickly on the first try, or even much after that, because the concepts are so foreign to you. I would be more than happy to test any accessibility issues involving anything other than color. just mention me or e-mail me. If I see the message I will make time.

For color contrast, look for a tool called Colour Contrast Analyzer, and see http://www.webaim.org for articles on how to use it.

On PC, the best screen reader and browser combination is going to be NVDA and Firefox, latest stable version. This is because NVDA is a screen reader that depends the most on the accessibility API, and Firefox is the PC browser that exposes the most pure implementatiion of the accessibility API. That’s the short of that ecxplanation.

See http://www.nvda-project.org to download and set up NVDA.

Once you have it set up, for easiest use, go into the Keyboard dialog and set the laptop layout, then go into the Browse mode dialog and turn off the checkbox for “Use screen layout.”

Once you have all that taken care of, you no longer need to listen to NVDA speak to do testing with it as a sighted person. Start it up, open NVDA, choose Tools, then Speech Viewer. Park that window so that you can see the text in it and the content in your browser. Size the window as desired, and then, when you go to the web, use mostly up and down arrow keys to read line by line as if you were arrowing through a Notepad document. Watch the speech viewer window very carefully and you will see text update there. The text in the speech viewer matches what NVDA would say, if it were talking.

All of this knowledge still will only be interesting, but not helpful to you, because honestly, you still do not know what should happen, so I would still be happy to test any accessibility fixes that I learn about here.

Of course, this is for selfish reasons, because I want to be the first blind persn to go all the way through FCC, then I want to use that knowledge to help with accessibility for other blind deelopers, and see more of them become web developers, and help people with all types of disabilities. And who knows, I may even get a better job or make money outside my day job.

Yes, I would be happy to help with testing and/ QA.

On 1/25/2017 6:39 AM, Timo wrote:

I looked into this a bit. It seems like TeachAccess is using the editor component from exerslide https://github.com/facebookincubator/exerslide/blob/master/packages/exerslide/components/Editor.js. From what I can tell, what it’s doing is copying all the content to the textarea.

Something else I ran into while working on #12828 https://github.com/freeCodeCamp/freeCodeCamp/issues/12828 is CodeMirror’s inputStyle option https://codemirror.net/doc/manual.html#option_inputStyle. This allows us to switch the editor to use contentEditable. I thought browser support for contentEditable http://caniuse.com/#search=contentEd shouldn’t be an issue, but I did find this comment on their discourse https://discuss.codemirror.net/t/inputstyle-contenteditable-we-may-hope-for-browser-spell-checking/608/2, which states that it’s buggy in old browsers. They do state that’s it the default on mobile, however, and it’s been working fine for us there. I think we should be fine using this option (they’ve had it for two years now). The only difference I have been able to spot in my quick test is that the cursor changes colour based on the syntax highlighting. I’m not an expert screen reader user, but from what I can tell this works fine with NVDA.

Should I submit this as a PR?

@mjanusauskas https://github.com/mjanusauskas @zersiax https://github.com/zersiax Do you have any tips on things I should test? Would you be willing to help with QA?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/freeCodeCamp/issues/12431#issuecomment-275097352, or mute the thread https://github.com/notifications/unsubscribe-auth/APDp4oqMSgwyJUBVxfaYDkwWaP23NDqMks5rV0JzgaJpZM4LdzaT.

Some Googling led me to this: http://bgrins.github.io/codemirror-accessible/ Might be worth a look

We are happy to announce that we have switched to Monaco editor on our learn platform. It has a11y built in.

We absolutely love CodeMirror and thanks to @marijnh for the awesome work that you and the team has done. Its been the de facto editor for all these years. We would still love to use it in future projects, because its just so light and simple.

Thanks @zersiax, @mjanusauskas, @inscriptioelectronicaaustralia and Everyone for chiming in and making the platform more accessible.

if you would need any coding assistance

The most useful type of contribution would be for screen-reader users and/or accessibility experts from your community to help test our new prototype, once we have it, so that issues can be spotted and addressed early on. We’ll do an announcement when we have something to show—if you want to make sure you’re notified, you can send me an email with contact data.

Hi @marijnh

Thanks for considering the re-archi of CodeMirror and we sincerely understand the efforts with everything being an open source effort.

Being a non-profit ourselves, please let us know, if you would need any coding assistance (pro-bono) from our community devs in this effort, we are around to help you in this effort, in any way we are able.

The battle tested knowledge of the CM project (and its contributors) is invaluable and hence we are dedicated to help in this effort, should you guide us with specifics on issue logged over at the CodeMirror repo.

Hi @inscriptioelectronicaaustralia

… but if we get to June and nothing has changed, perhaps looking into another solution is probably worth considering.

We sincerely understand and share the frustration, and we are prepared to dedicate efforts in any possible solution, but IMHO, helping CM become better at a11y, is the good thing to do.

I think that’s an effort well spent, as we will not only be helping freeCodeCamp community, but anywhere CM is in use for greater good of a11y everywhere else as well.

That said,

@zersiax analysis above is correct for the purposes of current state of our code base:

Quickly looking at Pode, it seems to be primarily an editor for HTML and unfortunately does not come near to CodeMirror’s functionality, so sadly I don’t think it is feasible.

The only stop-gap measure I can think of is to have some way of rendering the CM content to a regular textarea and reflect the edits made into that textarea in CM, perhaps when a keydown of tab is being detected or when ctrl+enter is preseed to run code. Until CodeMirror is either fixed (which is uncertain looking at the issue referenced above but unlikely given the track record) or discarded for another , similarly featured editor, I don’t think there’s much more that can be done on short notice.

We should start looking at implementing a interim solution, while we check with the CM team for how can we be of concrete help to them.

Either works 😃 I do have a node environment running, I would need to dust it off though 😃

A very good example of how this type of thing can be made completely accessible can be found at https://teachaccess.github.io/tutorial/#/3

On Mon, Jan 9, 2017 at 1:58 PM, Quincy Larson notifications@github.com wrote:

I just tried the CodeMirror Accessible demo that @dhcodes https://github.com/dhcodes linked to. Supposedly it is lower-performance, though I didn’t notice any slowdown when working with the ~10k line JavaScript file they had loaded in there. The largest projects I can imagine us having in a single CodeMirror text area would be maybe 1,000 lines, so I don’t think the slowdown is all that bad.

This said, I’m on a desktop.

Perhaps we should see whether we can have a button in the settings that toggles the use of CodeMirror Accessible?

CC @BerkeleyTrue https://github.com/BerkeleyTrue @zersiax https://github.com/zersiax

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FreeCodeCamp/FreeCodeCamp/issues/12431#issuecomment-271390191, or mute the thread https://github.com/notifications/unsubscribe-auth/APDp4nMFLf9Ou0z2oNBFLPZdcxZwxMoOks5rQpFPgaJpZM4LdzaT .

I just tried the CodeMirror Accessible demo that @dhcodes linked to. Supposedly it is lower-performance, though I didn’t notice any slowdown when working with the ~10k line JavaScript file they had loaded in there. The largest projects I can imagine us having in a single CodeMirror text area would be maybe 1,000 lines, so I don’t think the slowdown is all that bad.

This said, I’m on a desktop.

Perhaps we should see whether we can have a button in the settings that toggles the use of CodeMirror Accessible?

CC @BerkeleyTrue @zersiax

@raisedadead this is probably it for the open source reader https://github.com/nvaccess/nvda