Hi,
You sent me a snapshot of the editor on July 27th and that seems to be working great. haven’t actually looked at the code that powers it, but as far as functionality goes, it works just like a standard text field for me. The only thing I’ll say is that the line numbers are hard to match up with their corresponding lines, and I don’t know an easy fix for that. A hypothetical “accessible” mode could replace those numbers with one text field that shows the current line number and allows the user to enter a new one, or you could include that in the main interface if you thought that would be useful to other users. Alternatively (or additionally), each line number could be clickable so the user could just jump their cursor to a given line.
Here are the questions; hopefully they make some sort of sense. You can always DM me if you have questions and I’ll try and edit this to clarify.
Which screen reader do you usually use?
Non-visual Desktop Access (NVDA), but VoiceOver for Mac and iOS, JAWS, and Narrator are also installed.
Do you use different screen reader settings for code and for other content? If so, what is different? Is this configured per app? Do you know of a way a piece of content can tell the screen reader that it should use a code profile, or is switching always manual?
Switching is unfortunately very manual, but I can easily change the punctuation, indentation reporting, and other settings to have NVDA read as much or as little as necessary. I can’t configure this per website (although JAWS can do that), but this might come soon and I can configure it per application for now. It’s not a big deal to me right now, and I use notepad for coding for the most part.
Do you use indentation information to navigate code? Do you have your reader read whitespace to you, or do you access indentation information some other way?
NVDA can be configured to report indentation information verbally, at the beginning of the first line where it changes. It can also indicate this with audio tones. I’m not so sure that JAWS has a way of handling this. If the website were configured to indicate this somehow, I wouldn’t recommend having it as an “always on” setting because some people will be using Braille displays to skip-read the code and look for indentations, and others will be using NVDA’s indent reporting system. Having a way to jump to the next or previous indentation change would be quite useful though.
How do you prefer tabs to be read? Not at all, or with a description of "tab"? Or maybe "\t" is read meaningfully on your reader?
Same as above. It might be good to have that as a setting if it’s possible, but I wouldn’t want it to always be on. NVDA can already report this.
What are common screen-reader interactions while editing code (beyond reading the current line and the typed input)?
Nothing big beyond the normal text-field navigation commands. I use a slightly enhanced notepad for a lot of code editing.
How do you navigate long lines?
I just use ctrl+left/right arrows to go by word, which catches most punctuation separation as well. This would be something a code editor could probably fix. Having a keyboard command to go to the next or prevous major event (e.g. the end of a function or a closing quote) would help a lot. It would have to report the next major piece of text to the screen reader though.
CodeMirror will often redraw the text that is being edited (for example to update syntax highlighting). Are you aware of any problems this might cause?
I could see it lagging out NVDA a little, but if the cursor doesn’t change position I think it will be fine. Depends on how it does it. It might be a good idea to add an option to turn that off just in cae.
Is there any way to make syntax highlighting helpful to you? I’m guessing reading the token type before every token would be way too much—but maybe there are more subtle ways to communicate such info?
There is an option in most screen-readers to manually or automatically report formatting info such as font and color, so you can always just let it work normally and have the user decide if they want those changes to be reported. Just like indentation, they’ll only be reported when they change, not once per line, but there’s a keyboard command to check the current cursor position for formatting info.
In other editors, do you use any addon or tool that helps you navigate the code by structure? How does this work?
I don’t. I am a fairly uncomplicated person who just uses notepad. This is not necessarily the most efficient way to edit code though, and I’m sure other more experienced coders have other methods.
Do you use a braille reader for coding? If so, what advantages does it provide and how does navigating code with a braille display differ from voice screen reading?
It certainly makes it easier to take in punctuation and indentation quickly, but I don’t personally use one (though I have one to test with). In general they’ll just read whatever NVDA would normally read out loud and allow navigation within the available text, so no changes will need to be made specifically to adapt for one.
What does the ideal screen reader workflow for autocomplete look like?
Within a text editor, the typical way seems to be to just highlight the autocomplete suggestion, whereupon NVDA will read it automatically as it would a normal piece of selected text. However, this is up for some discussion. The default behavior for a screen reader is to interrupt whatever is being spoken with every press of a letter. So if you make an autocomplete suggestion announce itself once, it’s easy to miss. Some developers solve this with repeated announcements, but as someone who turns off that interrupt function, I can say that it’s very annoying to hear the same thing continuously spoken if it’s not necessary. Depending on the type of alert, it can also interrupt whatever else we might be doing to announce itself, which is basically equivalent to the entire screen going dark except for the alert in the middle. The best approach might be to have a single announcement when the suggestion is available, a keystroke to repeat it, and another to insert it. This, again, depends on how the current implementation works (I’m doing this before I do my testing). If there are multiple results available, it would be alright to present a menu of them as long as it could be navigated with arrow keys and would drop my cursor right back where it was afterward.
In a code editor (inside a website), would you expect tab to insert a tab or to move to the next control? If tab is overridden, how easy is it for you to escape a focusable field?
If I’m going to be tabbing around a lot to get to other controls on the website, I’d prefer tab not to insert a tab. I’m also completely fine with using spaces instead of tabs, so I might be in the minority here. However, I realize tab is the default behavior for a lot of these editors and am fine with it (maybe there could be an option to turn it off). All screen readers have a way of escaping most focusable fields and getting back to the rest of the page.
Do you agree with the principle that accessibility should not be a separate mode, but the default view should be accessible? Or are you okay with apps providing an explicitly enabled accessible mode (which for example changes the behavior of tab)?
I agree with the principle, but I realize it’s not always realistic. However, in this case I don’t think you would need to change the interface very much to make it better for us, so having a few checkboxes or maybe a master “accessible mode switch” is not going to cause the “accessible” version to become unmaintained or something. That principle comes from cases where an entire second copy of a website is built and maintained just for blind people, and I don’t think it applies here.
Do any things that code editors often get wrong come to mind? How could they do better?
I don’t think I’m qualified to answer this question because I haven’t used many of them at all. However, the one thing I’ll say is that there are a ton of websites which overuse alerts and announcements instead of making the actual interface accessible (for instance, making a custom toggle button for a specific mode or setting, and announcing its state to the screen reader every time it’s pressed, rather than making it behave like a standard checkbox that the screen-reader can see as being “checked” or “not checked”.) This mentality causes a lot of extra headache for developers because they have to code an exception for every single thing, and can break very easily. Often there’s a way to take an interface element that sighted people can interact with, and make it fully accessible to a screen reader without having to code the website to “talk” to the screen-reader.### Which screen reader do you usually use?
Non-visual Desktop Access (NVDA), but VoiceOver for Mac and iOS, JAWS, and Narrator are also installed.
Do you use different screen reader settings for code and for other content? If so, what is different? Is this configured per app? Do you know of a way a piece of content can tell the screen reader that it should use a code profile, or is switching always manual?
Switching is unfortunately very manual, but I can easily change the punctuation, indentation reporting, and other settings to have NVDA read as much or as little as necessary. I can’t configure this per website (although JAWS can do that), but this might come soon and I can configure it per application for now. It’s not a big deal to me right now, and I use notepad for coding for the most part.
Do you use indentation information to navigate code? Do you have your reader read whitespace to you, or do you access indentation information some other way?
NVDA can be configured to report indentation information verbally, at the beginning of the first line where it changes. It can also indicate this with audio tones. I’m not so sure that JAWS has a way of handling this. If the website were configured to indicate this somehow, I wouldn’t recommend having it as an “always on” setting because some people will be using Braille displays to skip-read the code and look for indentations, and others will be using NVDA’s indent reporting system. Having a way to jump to the next or previous indentation change would be quite useful though.
How do you prefer tabs to be read? Not at all, or with a description of "tab"? Or maybe "\t" is read meaningfully on your reader?
Same as above. It might be good to have that as a setting if it’s possible, but I wouldn’t want it to always be on. NVDA can already report this.
What are common screen-reader interactions while editing code (beyond reading the current line and the typed input)?
Nothing big beyond the normal text-field navigation commands. I use a slightly enhanced notepad for a lot of code editing.
How do you navigate long lines?
I just use ctrl+left/right arrows to go by word, which catches most punctuation separation as well. This would be something a code editor could probably fix. Having a keyboard command to go to the next or prevous major event (e.g. the end of a function or a closing quote) would help a lot. It would have to report the next major piece of text to the screen reader though.
CodeMirror will often redraw the text that is being edited (for example to update syntax highlighting). Are you aware of any problems this might cause?
I could see it lagging out NVDA a little, but if the cursor doesn’t change position I think it will be fine. Depends on how it does it. It might be a good idea to add an option to turn that off just in case.
Is there any way to make syntax highlighting helpful to you? I’m guessing reading the token type before every token would be way too much—but maybe there are more subtle ways to communicate such info?
There is an option in most screen-readers to manually or automatically report formatting info such as font and color, so you can always just let it work normally and have the user decide if they want those changes to be reported. Just like indentation, they’ll only be reported when they change, not once per line, but there’s a keyboard command to check the current cursor position for formatting info.
In other editors, do you use any addon or tool that helps you navigate the code by structure? How does this work?
I don’t. I am a fairly uncomplicated person who just uses notepad. This is not necessarily the most efficient way to edit code though, and I’m sure other more experienced coders have other methods.
Do you use a braille reader for coding? If so, what advantages does it provide and how does navigating code with a braille display differ from voice screen reading?
It certainly makes it easier to take in punctuation and indentation quickly, but I don’t personally use one (though I have one to test with). In general they’ll just read whatever NVDA would normally read out loud and allow navigation within the available text, so no changes will need to be made specifically to adapt for one.
What does the ideal screen reader workflow for autocomplete look like?
Within a text editor, the typical way seems to be to just highlight the autocomplete suggestion, whereupon NVDA will read it automatically as it would a normal piece of selected text. However, this is up for some discussion. The default behavior for a screen reader is to interrupt whatever is being spoken with every press of a letter. So if you make an autocomplete suggestion announce itself once, it’s easy to miss. Some developers solve this with repeated announcements, but as someone who turns off that interrupt function, I can say that it’s very annoying to hear the same thing continuously spoken if it’s not necessary. Depending on the type of alert, it can also interrupt whatever else we might be doing to announce itself, which is basically equivalent to the entire screen going dark except for the alert in the middle. The best approach might be to have a single announcement when the suggestion is available, a keystroke to repeat it, and another to insert it. This, again, depends on how the current implementation works (I’m doing this before I do my testing). If there are multiple results available, it would be alright to present a menu of them as long as it could be navigated with arrow keys and would drop my cursor right back where it was afterward.
In a code editor (inside a website), would you expect tab to insert a tab or to move to the next control? If tab is overridden, how easy is it for you to escape a focusable field?
If I’m going to be tabbing around a lot to get to other controls on the website, I’d prefer tab not to insert a tab. I’m also completely fine with using spaces instead of tabs, so I might be in the minority here. However, I realize tab is the default behavior for a lot of these editors and am fine with it (maybe there could be an option to turn it off). All screen readers have a way of escaping most focusable fields and getting back to the rest of the page.
Do you agree with the principle that accessibility should not be a separate mode, but the default view should be accessible? Or are you okay with apps providing an explicitly enabled accessible mode (which for example changes the behavior of tab)?
I agree with the principle, but I realize it’s not always realistic. However, in this case I don’t think you would need to change the interface very much to make it better for us, so having a few checkboxes or maybe a master “accessible mode switch” is not going to cause the “accessible” version to become unmaintained or something. That principle comes from cases where an entire second copy of a website is built and maintained just for blind people, and I don’t think it applies here.
Do any things that code editors often get wrong come to mind? How could they do better?
I don’t think I’m qualified to answer this question because I haven’t used many of them at all. However, the one thing I’ll say is that there are a ton of websites which overuse alerts and announcements instead of making the actual interface accessible (for instance, making a custom toggle button for a specific mode or setting, and announcing its state to the screen reader every time it’s pressed, rather than making it behave like a standard checkbox that the screen-reader can see as being “checked” or “not checked”.) This mentality causes a lot of extra headache for developers because they have to code an exception for every single thing, and can break very easily. Often there’s a way to take an interface element that sighted people can interact with, and make it fully accessible to a screen reader without having to code the website to “talk” to the screen-reader.