Accessibility/AndroidNotes

From MozillaWiki
Jump to: navigation, search

This page is a collection of notes about Android Firefox accessibility being collected in the October '11 accessibility meetup.

Background

We started working on a self-voicing solution for Firefox on Android with the hope to control the end-user experience and provide a very usable mobile browser despite Android's accessibility shortcomings. Recently, Firefox Mobile has made an abrupt switch to a native UI instead of XUL. On one hand this raised the issue of a consistent experience between the native UI being spoken in TalkBack (Android's screen reader), and the self-voicing of the browser's content. On the other hand this presents an opportunity for us to make a similar abrupt change in direction and provide a homogeneous experience under TalkBack.

We have the opportunity of being accessible by default, with no need for extra downloads or sighted assistance. This will be a first in the Android web browser world.

Supporting the platform API also gives the opportunity to be disability agnostic and allow other ATs to use our accessibility features. For example, when proper braille support is introduced in the platform, Firefox users will benefit from it.

Android Accessibility API

Accessibility was first introduced in Android API version 4 (Froyo). There has been a significant refresh in version 14 (4.0, Ice Cream Sandwich), which is very encouraging. I think we should support the earlier, version 4 API since it is much simpler to implement, easier to test and ultimately it is what Firefox Mobile is dependent on (version 5 or earlier), so users from Froyo onward will get support.

Once we have good support, and a solid testing plan in place we could think of supporting more advanced features found in API version 14.

Usability Enhancements via Extension

UI navigation in Android (pre 4.0) is limited to the directional controller. This is not good enough for continuous usage. There needs to be extra functionality like different navigation modes (character/word/block/header/link) and landmarks.

Another approach would be to integrate these features into the browser, they would be enabled/disabled via preferences and by sniffing for active ATs.

TalkBack support

There are no roles in Android's accessibility API (I know!). So for TalkBack to speak the control type like "button", it needs to infer it from the class name of the control. Each accessibility event has a class name attribute (getClassName), Talkback has "speech strategy" definition files that typically filter events by class name and have a basic template for how to utter that class. For example, an android.widget.Button would have a template defined for, something like "%s button".

Since all events emitted from Firefox would have a class name of org.mozilla.GeckoSurfaceView, we would need a way to differentiate between the event source's accessible objects. A possible way to do that would be to add the role name as a suffix to the class name, so a link would be org.mozilla.GeckoSurfaceView$link. TalkBack would need to have speech strategies for Firefox, so we would nee to contribute those to TalkBack.