Android Accessibility Knowledge Base (updated on July 20, 2011)
What follows are category-focused discussions (extracted on 7/20/2011 from the Eyes Free Google Group) about the accessibility (or inaccessibility) of a multitude of Android devices and applications.
It is important to note that these are only discussions by end-users and developers. Everyone has an opinion. Some opinions are based in fact. Some are not. Some users and developers may not know how to correctly access certain accessibility features and complain that they don’t exist. All discussions presented here should be taken with a grain of salt.
Google’s and Apps4Android Accessibility Applications have been designed to be compatible with releases of Android as distributed to manufacturers by Google. Most manufacturers modify Android in order to deliver specific looks and feels (differentiators) requested by the carriers who purchase and distribute the Android devices.
Some additions and changes made by manufacturers render Android devices inaccessible. For example, adding images without alternate text, adding customized launchers, using customized DLLs, and a myriad of other things.
Using practices that avoid making changes to Android, software drivers and applications that negatively impact accessibility as delivered out-of-the-box is a matter of educating manufacturers and implementing carrier level contractual deliverable controls.
All Android device stakeholders should be aware of the following facts.
If an application is fully-operable, compatible and interoperable with an official release of Android as distributed to a manufacturer by Google, and that manufacturer delivers a smart phone to a carrier (their customer) that no longer enables the use of an accessibility feature that previously worked, the manufacturer changed something that broke the feature/application.
There are only two solutions to this situation.
1. Manufacturer need to make the time to acquire the knowledge necessary to make cosmetic and functional changes (as requested by carriers) in manners that do not negatively impact applications that worked before their modifications; and/or,
2. Carriers need to write “non-impact of existing, working, accessibility apps/features” clauses into their manufacturing contracts. If an OS- or software-based accessibility feature works as distributed to a manufacturer, and the manufacturer changes something that breaks it, carriers should simply not accept delivery of the devices… nor pay for them.
The comments and opinions presented above:
The above comments are based on the following development experiences of Apps4Android/ Onymous Heroes (both IDEAL Group subsidiaries) and the Google Eyes-Free Project development team.
1. Apps4Android, Inc. (as of June 20, 2011):
- Number of accessibility applications developed: 24
- Number of downloads: 2,750,0951
- Number of installations: 2,227,0043
2. Onymous Heroes, Inc. (as of June 20, 2011):
- Number of applications, utilities, developed: 90
- Number of downloads: 402,1002
- Number of installations: 368,4954
3. Google Eyes-Free Apps (as of June 20, 2011):
- Number of applications, utilities, developed: 17
- Number of downloads: 9,560,1001
- Number of installations: 8,614,7253
- Number of applications, utilities, developed: 131
- Number of downloads: 12,712,295
- Number of installations: 11,210,224
Here’s the knowledge base (finally!):
- Code Factory
- Eyes Free Shell
- IDEAL Group
- Marvin Shell
- Screen Reader