Was using Atom today during a presentation.

While Atom’s not necessarily part of that evaluation, I noticed that VoiceOver thought the focus was on the close button the entire time.

Since we’re in a web browser, theoretically accessibility should be a given, but may be something to keep in mind going forward if it’s an easy fix.

//cc @muan, @nuclearsandwich, @eanakashima

7 thoughts on “Accessibility

  1. I for one can +1 this, given that I’m a blind programmer.
    I’m going to see how it performs on Windows when I get some time. Voiceover is one of the worst in terms of accessibility on the web, with all sorts of little quirks and nonstandard behavior (there is a reason that WebAIM surveys only show macs as around 30%% or less, and that’s because browsing the web is impractical at best).
    Assuming it at least works somewhat, there may be a number of simple fixes which can be done just by adding some Aria to it. Most of the rest comes for free by making the entire thing useable by the keyboard–the trick is clearly labeling everything that might get focus.
    The only major issue here may be in Atom-shell: the web view has to be accessible in the first place. I know that Chrome has been seeing some improvements of late, but have never played with stand-alone webviews. The major concern is that they’re not actually exposing Aria, in which case there may be nothing to be done without major work on Chromium.
    Unfortunately, my web expertise is limited to basics plus accessibility; I’m a C++ and DSP person, mostly.

  2. I was going to look at this, but then life happened. At the moment, I no longer have the time.
    Voiceover is not a useful test, in that Voiceover takes a very atypical and annoying approach. It is possible to make Mac apps that are accessible without even handling focus properly, and the entire experience over there is basically the opposite of friendly to the type of user who would want to use Atom in the first place. The short version is that a Voiceover user must explicitly navigate the tree of every view in the hierarchy, even if it’s inconsequential. Web browsing with Voiceover is usually broken and slower than any of the alternatives at best. The most useful target platform is Windows with NVDA: Windows because it’s where all the blind programers are, and NVDA because it doesn’t require paying large sums of money and is the most capable screen reader in terms of web browsing.
    In terms of the procedure for making Atom accessible, the first step is determining if the web view that Atom uses is exposed properly. I’m not up on the accessibility situation with Chrome and Chromium (I think this project is using Chromium, anyway), but if the web view doesn’t expose anything (which is possible), there’s at least a library upgrade and at most a great deal of work by someone who knows Microsoft Com and C++. The googlable terms here are MSAA, IAccessible2, and User interface Automation; the one that is most applicable in my opinion if someone needed to work on fixing this part is IAccessible2.
    After that, the answer is Aria. Aria is, in most cases, easy. The one difficulty is that Aria doesn’t currently provide anything for rich edit controls. Consequently, if the main textbox for entering code isn’t actually an input element or similar, the screen reader won’t be able to interact with it without some work. Google Docs has solved this with a sub-par solution, but some of the bugs there are annoying and wouldn’t actually make Atom something I’d want to use. One possible option here is to check the screen reader flag, something which Windows at least provides. The screen reader flag is set by running assistive technology and, if set, it might be possible to swap out any problematic controls for less problematic ones.
    the good news is that, if the web view is exposed properly, the techniques for actually making most things accessible are already pretty well-known and well-documented. This is most definitively not the case for the native app accessibility APIs, which also happen to generally be anywhere from 3 to 10 times more difficult to work with.
    If there are specific questions that need answering and which I can’t answer, I do know a number of people who can provide information.

  3. We agree that this is a significant problem and is something that should certainly be addressed. Unfortunately, we don’t have the resources to tackle this, rather large, problem in the foreseeable future. Because of this, we don’t feel that it is fair to leave this issue open and give the impression that it is something that we are looking into or will be working on soon.

    If anyone is interested in working closely with us on this to build an accessibility infrastructure (not just screen readers) for Atom, we would love to hear from you. See the SUPPORT doc for information on how to contact us.

    Thanks everyone for the feedback and information!

  4. Why not leave the issue open in case someone else who isn’t a core member decides to work on it? Isn’t that the point of open-source? So anyone can contribute? Either the issue is valid and unresolved, and hence should remain open, or the issue is invalid and should be closed (or is resolved and should be closed). Closing a valid but unresolved issue does not seem to benefit anyone.

  5. @lee-dohm You made a very bad decision closing this issue, You should leave it open. There are developers with accessibility skills that can help to fix this kind of issue, and so related ones. I personally do, and I’ll be glad to help to resolve them.

  6. Thanks everyone for the candid feedback here and elsewhere.

    The Atom maintainer team has been listening to what you’ve been saying and we’ve decided to reopen this issue. We realize that a number of people were upset by the team deciding to close the issue and we apologize for doing so. This isn’t meant to indicate a change in our roadmap or when the maintainer team will be able to work on making Atom more supportive of accessibility technologies, just to reopen it to make it more searchable for the community to discuss and collaborate around.

    We would also like to reiterate the invitation for people to work closely with us on creating an accessibility infrastructure. I’ve created an #accessibility channel in the Atom community Slack team for those who would like to collaborate to make this happen. We look forward to people with interest or expertise helping to make this a reality.

    We appreciate you sharing your thoughts and feelings with us on this.