Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Contents of editor can not be reviewed by screen readers #12431

Closed
mjanusauskas opened this issue Jan 8, 2017 · 61 comments
Closed

Contents of editor can not be reviewed by screen readers #12431

mjanusauskas opened this issue Jan 8, 2017 · 61 comments
Labels
scope: a11y Threads for addressing accessibility issues.

Comments

@mjanusauskas
Copy link

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.
@Bouncey Bouncey added scope: a11y Threads for addressing accessibility issues. scope: UI Threads for addressing UX changes and improvements to user interface labels Jan 8, 2017
@Bouncey
Copy link
Member

Bouncey commented Jan 8, 2017

\cc @FreeCodeCamp/moderators

@raisedadead raisedadead added status: discussing Under discussion threads. Closed as stale after 60 days of inactivity. help wanted Open for all. You do not need permission to work on these. labels Jan 8, 2017
@raisedadead
Copy link
Member

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.

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 8, 2017 via email

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 8, 2017 via email

@raisedadead
Copy link
Member

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

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 9, 2017 via email

@raisedadead
Copy link
Member

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?

@erictleung
Copy link
Member

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

@raisedadead
Copy link
Member

Ah, thanks @erictleung!

@raisedadead
Copy link
Member

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

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 9, 2017 via email

@raisedadead
Copy link
Member

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.

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 9, 2017 via email

@dhcodes
Copy link
Contributor

dhcodes commented Jan 9, 2017

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

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 9, 2017 via email

@raisedadead
Copy link
Member

@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

@QuincyLarson
Copy link
Contributor

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

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 20, 2017 via email

@systimotic systimotic mentioned this issue Jan 22, 2017
Closed
@zersiax
Copy link
Contributor

zersiax commented Jan 22, 2017

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

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 22, 2017 via email

@mjanusauskas
Copy link
Author

mjanusauskas commented Jan 25, 2017 via email

@erictleung
Copy link
Member

@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/

@systimotic
Copy link
Member

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?

@zersiax
Copy link
Contributor

zersiax commented Jan 25, 2017

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

@zersiax
Copy link
Contributor

zersiax commented Jan 25, 2017

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

@QuincyLarson QuincyLarson mentioned this issue Dec 23, 2017
Closed
@inscriptioelectronicaaustralia
Copy link

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?

@jhomme
Copy link

jhomme commented Dec 28, 2017 via email

@QuincyLarson
Copy link
Contributor

@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.

@inscriptioelectronicaaustralia
Copy link

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?

@JimHomme
Copy link

JimHomme commented Dec 28, 2017 via email

@QuincyLarson
Copy link
Contributor

@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.

@zersiax
Copy link
Contributor

zersiax commented Dec 30, 2017

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: codemirror/codemirror5#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.

@inscriptioelectronicaaustralia
Copy link

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.

@QuincyLarson
Copy link
Contributor

@inscriptioelectronicaaustralia @zersiax @jhomme It sounds like from reading codemirror/codemirror5#4604 (comment) 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.

@inscriptioelectronicaaustralia
Copy link

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?

@raisedadead raisedadead mentioned this issue Jan 2, 2018
Closed
@marijnh
Copy link

marijnh commented Jan 2, 2018

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.

@raisedadead
Copy link
Member

raisedadead commented Jan 2, 2018 •
edited

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.

@marijnh
Copy link

marijnh commented Jan 2, 2018

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.

@Bouncey
Copy link
Member

Bouncey commented Jan 2, 2018

@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.

@svinkle
Copy link

svinkle commented Jan 3, 2018

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.

@raisedadead
Copy link
Member

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.

@QuincyLarson
Copy link
Contributor

@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.

@QuincyLarson QuincyLarson added status: blocked Is waiting on followup from either the Opening Poster of the issue or PR, or a maintainer. and removed scope: UI Threads for addressing UX changes and improvements to user interface beta status: discussing Under discussion threads. Closed as stale after 60 days of inactivity. help wanted Open for all. You do not need permission to work on these. labels Jan 9, 2018
@raisedadead
Copy link
Member

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.

@raisedadead raisedadead removed the status: blocked Is waiting on followup from either the Opening Poster of the issue or PR, or a maintainer. label Jun 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
scope: a11y Threads for addressing accessibility issues.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests