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

Created on 8 Jan 2017  ·  61Comments  ·  Source: freeCodeCamp/freeCodeCamp

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.

a11y

Most helpful comment

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.

All 61 comments

\cc @FreeCodeCamp/moderators

Yup, thanks a lot for bringing this up, we are very open to idea to make the website more accessible and supporting screen readers is an important part of this.

Opening up to community for suggestions on implementations.

Comment from the NVDA screen reader lead developer:

On 1/8/2017 5:11 PM, mrugesh mohapatra wrote:
>

Yup, thanks a lot for bringing this up, we are very open to idea to
make the website more accessible and supporting screen readers is an
important part of this.

Opening up to community for suggestions on implementations.


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

Comment from the NVDA screen reader lead developer:

This is due to accessibility problems in the code editor being used.
These code editors choose to draw their content in a non-standard way,
rather than using HTML contentEditable (which is the standard way to do
editable content). Unfortunately, there's nothing we can do to support
this; the issue needs to be fixed in the editor.

On 1/8/2017 5:11 PM, mrugesh mohapatra wrote:
>

Yup, thanks a lot for bringing this up, we are very open to idea to
make the website more accessible and supporting screen readers is an
important part of this.

Opening up to community for suggestions on implementations.


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

@mjanusauskas Hey Mathew! Mind pointing us to the repo if this is opensource for raising a issue report?

I'm not sure exactly which inaccessible editor is being used.

On 1/9/2017 12:49 AM, mrugesh mohapatra wrote:
>

@mjanusauskas https://github.com/mjanusauskas Hey Mathew! Mind
pointing us to the repo if this is opensource for raising a issue report?


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-271220175,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4iUWcvbQSZedazsn7H3_sOnWCuB7ks5rQdh_gaJpZM4LdzaT.

Well we use https://github.com/codemirror/CodeMirror for the editor, but we would like to know if you could also help us with the repo for NVDA the open source screen reader to check with them as well?

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

Ah, thanks @erictleung!

Okay, I don't see any issues with the repo that relates to CodeMirror specifically. I guess we should go about, opening issues in both repos, seeking assistance on this?

/cc @FreeCodeCamp/moderators

The previous comment I shared from the NVDA lead developer came from the
issue I opened in their repo. Their position is that there is nothing
that can be done in the screen reader due to the non-standard approach
being used and that the accessibility issue must be addressed in the editor.

On 1/9/2017 12:18 PM, mrugesh mohapatra wrote:
>

Okay, I don't see any issues with the repo that relates to CodeMirror
specifically. I guess we should go about, opening issues in both
repos, seeking assistance on this?

/cc @FreeCodeCamp/moderators
https://github.com/orgs/FreeCodeCamp/teams/moderators


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-271361131,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4oyVgtLfIsZKxB51xxN08OxRhHhXks5rQnoFgaJpZM4LdzaT.

Can you help us with issue no, link, etc., we would love to understand what needs to be implemented? Without a clear technical idea of what's wrong, in the editor, it would be difficult to convince the maintainers of the editor for a fix.

Apologies, but without more info, it's tough to proceed with this, given that we would love to support as much accessibility as we can.

The issue I reported to the NVDA screen reader developers is:

https://github.com/nvaccess/nvda/issues/6707

Thank you for anything you are able to do. I would love to be able to
participate in Free Code Camp once the accessibility issue has been
resolved.

On 1/9/2017 12:41 PM, mrugesh mohapatra wrote:
>

Can you help us with issue no, link, etc., we would love to understand
what needs to be implemented? Without a clear technical idea of what's
wrong, in the editor, it would be difficult to convince the
maintainers of the editor for a fix.

Apologies, but without more info, it's tough to proceed with this,
given that we would love to support as much accessibility as we can.


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-271367297,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4rtyeVvew2edXgWaxr1eICnDpdKxks5rQn9wgaJpZM4LdzaT.

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

I'm not sure what editor is being used, or if it is helpful, but the
experience using the html and css courses and code tests on
www.w3schools.com was quite accessible as a screen reader user.

On 1/9/2017 12:55 PM, Dylan wrote:
>

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


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-271371504,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4p-8xX-xTVF0bqGhOkpAinPMDwNaks5rQoKagaJpZM4LdzaT.

@mjanusauskas Thanks a lot, Mathew.

We are looking into this on priority and best of our abilities...we might be delayed a bit, but rest assured will try to come up with some fix as soon as we can... meanwhile we welcome you to check out the wiki articles on our forum at https://forum.freecodecamp.com and the video series to keep continuing with the learning.

/cc @QuincyLarson

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

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 like that resource, it does show a working example ...does it use contentEditable under the hood?

I suspect so, but am not sure.
Currently the rather tedious work around I am using for each challenge is
to select all content in the CodeMirror editor > paste into NotePad++ >
make necessary edits > Select all and copy > Paste into CodeMirror editor >
submit.
Obviously a very poor and inefficient experience for screen reader users.

On Sun, Jan 22, 2017 at 4:19 PM, Florian Beijers notifications@github.com
wrote:

I like that resource, it does show a working example ...does it use
contentEditable under the hood?


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-274364439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4hHGQh0qVNCHAFDmlUzwq8u8DPIPks5rU9X5gaJpZM4LdzaT
.

After using the mentioned tedious work around to complete the HTML, CSS
and Bootstrap challenges I was disappointed to find that the next
challenge of building a basic tribute web page uses CodePen.

CodePen appears to have similar major accessibility issues with it's
editor. Very frustrating for a screen reader user.

On 1/22/2017 4:19 PM, Florian Beijers wrote:
>

I like that resource, it does show a working example ...does it use
contentEditable under the hood?


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-274364439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4hHGQh0qVNCHAFDmlUzwq8u8DPIPks5rU9X5gaJpZM4LdzaT.

@mjanusauskas we suggest Codepen for the integrated text editor and quick rendering. However, I don't think we limit it to just Codepen. To finish your project, all you need to submit is a URL to your project up and running. So feel free to use whatever hosting service to render your projects. An alternative is to use GitHub pages https://pages.github.com/.

Note for contributors wanting to help, here's a resource which may help alleviate this issue http://bgrins.github.io/codemirror-accessible/

I looked into this a bit. It seems like TeachAccess is using the editor component from exerslide. 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 is CodeMirror's inputStyle option. This allows us to switch the editor to use contentEditable.
I thought browser support for contentEditable shouldn't be an issue, but I did find this comment on their discourse, 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 @zersiax Do you have any tips on things I should test? Would you be willing to help with QA?

If anyone needs another example on how this should work I just stumbled across the online Orion IDE which does a heck of a lot of what I would want from a system like this. I doubt its open source though

@QuincyLarson yeah, send me a link to a sandbox where you have this running? I'll give it a whirl.

@zersiax Hi! I'm not sure how to deploy a sandbox version of freeCodeCamp. Maybe Quincy can get one up for you, or I'd be happy to guide you through installing it locally.

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

@zersiax Local is probably the fasted solution 👍 Here is the shortened version of the setup guide (full guide is CONTRIBUTING.md):

  1. Make sure Node v6 and MongoDB v3 are installed
  2. Clone freeCodeCamp
  3. Make sure MongoDB is running throughout all of this
  4. Run the following commands inside the freeCodeCamp cl:
npm install
npm install -g gulp
cp sample.env .env
npm run only-once
gulp
  1. Your local instance should now be running at localhost:3000
  2. To check out my changes, stop gulp and run:
git remote add systimotic https://github.com/systimotic/FreeCodeCamp.git
git fetch systimotic
git checkout --track systimotic/fix/accessible-editor
  1. Start gulp again, and you should be able to check out the changes again at localhost:3000

Oof, that was a bit more complicated than I imagined it to be.
I may have messed up, though. 😅 Feel free to message me anywhere if you run into any problems.

Thank you for the information. I will investigate GitHub Pages as a
possible alternative.

On 1/24/2017 11:12 PM, Eric Leung wrote:
>

@mjanusauskas https://github.com/mjanusauskas we suggest Codepen for
the integrated text editor and quick rendering. However, I don't think
we limit it to just Codepen. To finish your project, all you need to
submit is a URL to your project up and running. So feel free to use
whatever hosting service to render your projects. An alternative is to
use GitHub pages https://pages.github.com/.

Note for contributors wanting to help, here's a resource which may
help alleviate this issue http://bgrins.github.io/codemirror-accessible/


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-275020850,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4lJ8-omlWG3Xbt5soRKVVFYaKYMJks5rVtm1gaJpZM4LdzaT.

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.

+1. For the time being, it would help to put a hidden instruction that only screen-readers can read that states how to deal with this issue (copy to another editor, edit there, copy back.)

How long do we expect this to take? You can add a .sr-only class to a
span that contains that text, but if we leave it in there for too long
someone somewhere is going to forget about it and it will be just sit
there because you guys aren't actually seeing that message :)

I recently encountered this same issue both at CodePen.com and EdX.org

EdX appears to have an accessible solution in place and I am including
their comments here:

We use an open source code editor called CodeMirror
(https://codemirror.net/). We had to make some modifications to it to
make it work within edX Platform. Some of those modifications included
some accessibility improvements so the user may not have the same
experience on other sites that use CodeMirror. Because we had to
customize it for edX, we were not able to push our changes upstream.
However, CodeMirror is actively working to fix these issues, according
to their github repository Issue tracker. Another custom change we made
to our fork of CodeMirror is the inclusion of screen reader and keyboard
user-specific instructions that precede the editor in the TAB order. The
user needs to be aware they they can hit the ESC key twice and then TAB
to move focus beyond the editor. This is necessary because in a code
editor, it is very common for a user to want to insert a TAB sequence,
and NOT move the current keyboard focus, which is what the TAB key does
by default.

On 1/31/2017 4:01 PM, Florian Beijers wrote:

How long do we expect this to take? You can add a .sr-only class to a
span that contains that text, but if we leave it in there for too long
someone somewhere is going to forget about it and it will be just sit
there because you guys aren't actually seeing that message :)


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-276506570,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4h-s2_aSFUDNSIRXnc8v7bmlNqhnks5rX69UgaJpZM4LdzaT.

Here is another example of a working solution to this critical issue:

https://github.com/jsbin/jsbin/issues/936

On 1/31/2017 4:01 PM, Florian Beijers wrote:

How long do we expect this to take? You can add a .sr-only class to a
span that contains that text, but if we leave it in there for too long
someone somewhere is going to forget about it and it will be just sit
there because you guys aren't actually seeing that message :)


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-276506570,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDp4h-s2_aSFUDNSIRXnc8v7bmlNqhnks5rX69UgaJpZM4LdzaT.

hi

_Sent from my Samsung SM-A520F using FastHub_

_Sent from my Samsung SM-A520F using FastHub_

Hi,
I think I can follow these instructions now that I have the site set up locally. I'm pretty sure I need to follow the part that tells how to sync up this repository with mine. Is this correct? And if I do something wrong, I'm unsure how to back it out. A little anxious. :)

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.

@jhomme Thanks for the details on the screen readers you use.

When I use the Fangs on FireFox, and visit this URL: https://www.freecodecamp.org/challenges/inform-with-the-paragraph-element

the screenreader output is:

Page has one frame, four headings and twenty-five linksInform with the Paragraph Element vertical bar freeCodeCamp dash Internet ExplorerLinkGraphiclearn to code javascript at freeCodeCamp logoList of seven itemsbulletLink MapbulletbulletLink ForumbulletLink ContributebulletLink AboutbulletLink DonatebulletLink Sign inList endHeading level four Inform with the Paragraph Element p elements are the preferred element for normal dash sized paragraph text on websites. P is short for quote paragraph quote . You can create a p element like this colon less p greater I'm a p tag! less slash p greater Create a p element below your htwo element, and give it the text quote Hello Paragraph quote . Run tests left paren ctrl plus enter right paren Reset your codeLink Get a hint Ask for help on the forumLink Sign in so you can save your progress Create a p element. Your p element should have the text quote Hello Paragraph quote . Make sure your p element has a closing tag. EditEdit four one ​ two less hone greater Hello World less slash hone greater three less htwo greater CatPhotoApp less slash htwo greater four ​Heading level one Hello WorldHeading level two CatPhotoAppLinkLinkLink

If I'm understanding this correctly, this is the contents of the code editor as rendered by the screen reader:

one ​ two less hone greater Hello World less slash hone greater three less htwo greater CatPhotoApp less slash htwo greater four

So this doesn't seem to be an issue for the Fangs screen reader. Are you experiencing this with all of the four screen readers or just some of them?

By the way, I applaud your ambition to become the first blind person to go all the way through freeCodeCamp! We will do what we can to help you make that goal a reality.

hi Quincy,

I am experiencing this with JAWS and NVDA on PC, voiceover on Mac. I am not experiencing this with VoiceOver on IOS. I don't understand why. So far I have not tried any other screen reader. I could try Narrator and TalkbBack.

On Aug 23, 2017, at 12:01 AM, Quincy Larson notifications@github.com wrote:

@jhomme Thanks for the details on the screen readers you use.

When I use the Fangs on FireFox, and visit this URL: https://www.freecodecamp.org/challenges/inform-with-the-paragraph-element

the screenreader output is:

Page has one frame, four headings and twenty-five linksInform with the Paragraph Element vertical bar freeCodeCamp dash Internet ExplorerLinkGraphiclearn to code javascript at freeCodeCamp logoList of seven itemsbulletLink MapbulletbulletLink ForumbulletLink ContributebulletLink AboutbulletLink DonatebulletLink Sign inList endHeading level four Inform with the Paragraph Element p elements are the preferred element for normal dash sized paragraph text on websites. P is short for quote paragraph quote . You can create a p element like this colon less p greater I'm a p tag! less slash p greater Create a p element below your htwo element, and give it the text quote Hello Paragraph quote . Run tests left paren ctrl plus enter right paren Reset your codeLink Get a hint Ask for help on the forumLink Sign in so you can save your progress Create a p element. Your p element should have the text quote Hello Paragraph quote . Make sure your p element has a closing tag. EditEdit four one ​ two less hone greater Hello World less slash hone greater three less htwo greater CatPhotoApp less slash htwo greater four ​Heading level one Hello WorldHeading level two CatPhotoAppLinkLinkLink

If I'm understanding this correctly, this is the contents of the code editor as rendered by the screen reader:

one ​ two less hone greater Hello World less slash hone greater three less htwo greater CatPhotoApp less slash htwo greater four

So this doesn't seem to be an issue for the Fangs screen reader. Are you experiencing this with all of the four screen readers or just some of them?

By the way, I applaud your ambition to become the first blind person to go all the way through freeCodeCamp! We will do what we can to help you make that goal a reality.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@jhomme For some reason I cannot find the comment where you explain what it is you are encountering. What seems to be the officer, problem?

Hi Florian,
Various screen eaders do not speak when attempting to navigate or type
in the editor on the site. They just say the word blank. They speak,
though, when selecting text.

Jim

On 8/23/17, Florian Beijers notifications@github.com wrote:

@jhomme For some reason I cannot find the comment where you explain what it
is you are encountering. What seems to be the officer, problem?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/freeCodeCamp/freeCodeCamp/issues/12431#issuecomment-324309958

--

Jim Homme
http://www.jimhommewebdev.com
Twitter: @jimhomme
Facebook: http://www.facebook.com/jimhomme
LinkedIn: https://www.linkedin.com/in/jimhomme

Ahh yup, that appears to be still be a problem. As you can see in this thread it has to do with CodeMirror not being accessible. Easiest way to get around it for now is to copy-paste the code into an editor like NotePad++ or EdSharp if you must :P , then make your edits, then paste it back into the fcc editor. Tedious, but it works I guess :)

I have just found an open-source HTML code editor that is fully accessible. Could the current one be replaced with this? https://pode.herokuapp.com/ For the CodePen challenges, as CodePen is not accessible, could there be alternate instructions for users of assistive technology to use this website instead?

Hi,
Please see the below post and the one it leads to. CodePen is doable, and improving. With constructive feedback, they will be better.

https://blog.codepen.io/2016/07/14/blind-accessibility-testers-society-guide-codepen/

On Dec 27, 2017, at 5:17 PM, inscriptioelectronicaaustralia notifications@github.com wrote:

I have just found an open-source HTML code editor that is fully accessible. Could the current one be replaced with this? https://pode.herokuapp.com/ For the CodePen challenges, as CodePen is not accessible, could there be alternate instructions for users of assistive technology to use this website instead?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@zersiax Thanks for chiming in. I'm relived to hear this is just an issue with CodeMirror's accessibility, but that means we'll need to figure out a way to patch that.

@inscriptioelectronicaaustralia We will soon support building the projects right on freeCodeCamp, so CodePen's relatively inaccessible interface won't be so much of a problem. We just need to fix the issues with CodeMirror, which is an open source library we can potentially contribute to.

Quincy, it's good that the projects will soon be able to be built on Free Code Camp.

I have just looked at the Code Mirror GitHub threads pertaining to this, and they think that it is a lot of work to make this work with screen readers, so whether people contributing to this thread or them can sort out the problem will lead to a win-win situation for not only us, but also the other websites that use Code Mirror.

Looking at the situation hypothetically, are there many missing features from the Pode tool I referenced above that would affect Free Code Camp if it were to be implemented as a replacement for Code Mirror?

Hi,
Expressing my sinsere appreciation for folks looking into this. I am moving toward actually finishing JavaScript right now, and can’t wait to be able to write real code that helps people, especially FreeCodeCamp.

Jim

From: inscriptioelectronicaaustralia [mailto:[email protected]]
Sent: Thursday, December 28, 2017 2:08 AM
To: freeCodeCamp/freeCodeCamp freeCodeCamp@noreply.github.com
Cc: Jim Homme jhomme@benderconsult.com; Mention mention@noreply.github.com
Subject: Re: [freeCodeCamp/freeCodeCamp] Contents of editor can not be reviewed by screen readers (#12431)

Quincy, it's good that the projects will soon be able to be built on Free Code Camp.

I have just looked at the Code Mirror GitHub threads pertaining to this, and they think that it is a lot of work to make this work with screen readers, so whether people contributing to this thread or them can sort out the problem will lead to a win-win situation for not only us, but also the other websites that use Code Mirror.

Looking at the situation hypothetically, are there many missing features from the Pode tool I referenced above that would affect Free Code Camp if it were to be implemented as a replacement for Code Mirror?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/freeCodeCamp/freeCodeCamp/issues/12431#issuecomment-354240665, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AdDz24NBYQr6hKSp_HsEnOryzgzIkA24ks5tEz5PgaJpZM4LdzaT.

@inscriptioelectronicaaustralia CodeMirror is a widely-used project with tons of features that we use. I'm skeptical that Pode could do everything CodeMirror does. I think the best option is for us to patch CodeMirror.

Although I do agree that patching CodeMirror is the most , let's call it effective, way of solving the problem, we do have to stay somewhat realistic.
This issue has existed for the entirety of this year, it's a year old bar a few weeks, and I've been whining and growling about this problem for at least two, maybe even three years now. And it is a problem indeed; every single time I decide to give FCC a try again I'm put off by the sheer annoyance of having to work around these issues. The ease, low entry threshold and simplicity of coding and seeing your live preview update in the browser as you code just doesn't apply to people using screen readers at present, which is a lot of what makes freecodecamp effective and , dare I say, charming.
CodeMirror has shot itself in the foot by focusing on mainly rendering the code in a performant way graphically, almost completely relinquishing the standard DOM operation of yore. If you look around, even WordPress is suffering from this problem and they have not yet found a suitable way of getting around this; it has in fact stopped them from implementing codeMirror as WP's default WordPress editor and if that editor is indeed implemented as default, an opt-out for visually impaired WordPress administrators will need to be implemented to not completely break the admin experience for those people. CodeMirror isn't likely to get fixed any time soon.
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.
There's no simple solution to this problem, and patching is even less of a good idea looking at this issue: https://github.com/codemirror/CodeMirror/issues/4604
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.

Quincy, I understand that CodeMirror is clearly the superior solution (I think Pode was made to be extremely simple as it was intended just for beginners), and it would be ideal to make it accessible if that is possible. The reason I asked what features Pode is lacking is that, once the text in CodeMirror edit fields can be read by screen readers, if CodeMirror uses any other visual features to assist in coding, these should also eventually be made accessible if possible.
I was thinking about other ways to tackle this issue, and I thought that someone could make some scripts for the JAWS for Windows screen reader, and/or if possible an add-on for the NVDA screen reader (VoiceOver for macOS does not allow scripting I think), that when the user entered a CodeMirror text field, the text that was already in there would be copied into a JAWS or NVDA text buffer, which could then be edited, and with a keystroke sent back to the editor. Ideally, this "special" text field would give access to any other important features that CodeMirror offers. JAWS uses a proprietary scripting language that does have the ability to make domain-specific scripts, and NVDA uses Python for making add-ons, but I am not sure if domain-specific ones can be made for that screen reader.

@inscriptioelectronicaaustralia @zersiax @jhomme It sounds like from reading https://github.com/codemirror/CodeMirror/issues/4604#issuecomment-349920743 that @marijnh is planning to move to content editable, which should make CodeMirror significantly more usable. I commented on the issue asking whether there's anything we could do to help.

Worst case scenario, we might be able to build an "accessibility mode" that allows campers to switch from CodeMirror for Pode in the settings, thought that would be an indeterminately large amount of work.

Let's wait and see what @marijnh has to say.

I read marijnh's response, and it seems like it might be a while until we get accessibility. One thing to also take into consideration is that unfortunately, even when people say "a few months", that is rarely the case for accessibility as it too often gets very low priority. I'm not saying that this is what the developers of CodeMirror think, but it is a very disturbing worldwide trend. I have seen examples when people say "a few months", and it turns into a few more months ... then a few more ... and I think you get the picture.
As it is still possible to use the code editor as it is, I think waiting for a few months is probably the best approach, but if we get to June and nothing has changed, perhaps looking into another solution is probably worth considering. What do others think?

I have seen examples when people say "a few months", and it turns into a few more months ... then a few more ...

No one promised anything in a few months, except that work would _start_ on a new approach, which will definitely take a while to build.

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.

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.

@svinkle I would appreciated your input on this a11y issue.

Is the stop-gap suggested something that could work until the content-editable issue is resolved upstream?

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.

If I understand the approach correctly, the CM editor content would load in a textarea and the textarea would be used to edit content. Then on update/save the textarea content would be reflected in the CM editor.

Would the CM editor be hidden from view? I assume there would only be the textarea viewable, otherwise having two editing areas would be confusing.

Hi @QuincyLarson and everyone involved,

Thanks a lot for the feedbacks and considerations, in finding a solution.

There is one more consideration that we have hit which I just happened to realise with some discussions with @BerkeleyTrue about a separate topic on CM, before we go ahead with any of the monkey-patching with another textarea. 😓

On beta (our new react front-end) we are not dependent on CodeMirror directly, but on a react component react-codemirror which is a light weight wrapper on top of CM. This is so, because we need it to work with our beta platform.

We may have to update that to a different component sometime in future, but that said none of those components in discussion have the a11y support same as in the parent CM on which wrap their functionality.

So a monkey-patch may not be trivial.

@raisedadead Thanks for pointing this out. We will wait for CodeMirror to do their accessibility update, then evaluate the process of monkey patching from there.

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.

Was this page helpful?
0 / 5 - 0 ratings