This page is deprecated. Redirecting to https://developer.android.com/studio/intro/accessibility.html

The IDE is implemented in Swing, which supports accessibility in general, but the IDE is using a lot of custom components, and these do not yet have accessibility support.

The biggest hurdle is the source editor, and the accessibility work for that is discussed in a separate source editor accessibility document.

The code editor makes use of popup dialogs for activities like code completion and show documentation. Note however that even while this popup is showing, the focus remains in the source editor, such that you can continue to type, or use the arrow keys to navigate in the completion popup. This is not working well with the screen reader today, which doesn't handle this "split focus" concept. Now that we have basic screen reading working, this is the next task to make the editor screen-reader friendly.

The IDE has a custom implementation of tabs (JBTabsImpl), which does not extend the Swing tab container -- and needs accessible support such that it can be navigated by the screen reader. This is relatively straightforward. Note however that it should not be done for the specific usage around the source editor!

When I first implemented accessibility support in JBTabsImpl, I could no longer directly jump between the project outline and the editor; I had to iterate via the editor tabs each time. That's pretty inconvenient, and the IDE has many primary actions for navigating between files. Therefore, we should customize the editor specific tabs implementation to not register itself as an accessible component, such that the screen reader skips right past it and dives into the editor directly.

Every time you switch between apps, at least on OSX, the system screen reader reads out the application title. And the application title in the IDE is really long -- often the name of the application, the version, as well as the full path to the current project.

The accessibility framework lets us customize the name and description of elements, so we should customize the description here to something much shorter, such that when you jump between for example the IDE and the browser, it just says "Android Studio" (or "IntelliJ") when you return to the IDE, rather than a verbose 10 second readout.

This should in theory be done by the following CL: https://android-review.googlesource.com/136520.

However, when I tested it on the Mac, it did not work. I suspect that this is due to the screen reader support for Java on OSX being hardcoded to read out a JFrame title rather than looking up the accessibility description (similar to how the text support on OSX is hardcoded to only work with JTextComponents as discussed in the source editor document). I'd like to try this on other platforms (Windows, Linux) to see if it works there or if we need to do something else.

There are some other custom widgets in IntelliJ (many of them in the com.intellij.ui package); we need to check all of them to make sure that even if they extend Swing base classes with accessibility support, they also override the accessibility support to be correct if necessary.

IntelliJ is optimized for fast navigation by keyboard. But that doesn't mean that it makes the IDE completely navigable by keyboard. For example, consider the "textfield and button" component:

The Text field and browse button here is a custom component, and the code for this in IntelliJ is optimized to make the Browse button not focusable. That means that if you hit Tab, it will skip past the "..." button and move the focus on to the Text button. For many users, that's a feature, you can type your answers in the text fields and rapidly hit Tab to jump from one text field to the next. But for somebody without access to a mouse, it does mean you can't actually reach the file chooser button, so if you depend on it, it's an accessibility problem.

We could "fix" our accessibility bugs by making all widgets like this (there are other examples, like hyperlink labels etc) focusable. But that would come at a price of slower keyboard navigation for many users. So perhaps a better solution would be to make this an option, since there are trade-offs involved that will differ from user to user.

Here's what MacOSX does (under Preferences > Accessibility > Keyboard)

The default in OSX is Text Boxes and lists only; I've changed the default on my system for accessibility testing. In the IDE we'd probably also default to the skip mode, but for users who want to reach every single component, they'd have the option to do that (and we'd need to make sure that they can reach and toggle this setting by keyboard only!).

There were many dialogs and windows you could not navigate by keyboard only. In Android Studio 1.1, we tried to address all the ones added by the Android plugin itself, but we need to test the rest of the IDE and potentially fix issues.

We should make sure that you can reach all widgets via the keyboard. There were several bugs in this area that we fixed for Android Studio 1.1, but we focused only on the Android specific UI added by the Android plugin, not the overall IDE, so we need to broaden the testing and fix the remaining UI, if any.

We should also try to do some automated validation of this (for example, in EAP builds, have code which walks through the UI hierarchy and checks focus traversal and ensures that everything is reachable).

IntelliJ is already highly themable (and ships with multiple different schemes), so (modulo any potential theming bugs) we should be in good shape.