A few months ago, a friend of mine who prefers Android accessibility to that available from Apple on its iOS devices, sold me a Google Nexus/7 tablet so I could try it out and, perhaps, write an article about its accessibility. Since early October,, I’ve tried to use the Nexus/7 to perform the same tasks that I enjoy on my iPhone 5S. I can say that, while accessibility on Android is better than I expected, it is still far from being a solution I can use full time the way I can with a device from Apple or Microsoft.
This article isn’t up to my usual writing standards. This is a compilation of a lot of notes I’ve taken during my time with the Nexus/7. This article contains a bit of repetition, some clunky sentences and could be more well organized. Unfortunately, I haven’t the time to do my usual amount of editing. As far as I know, all of the “facts” I present in this article are true, I’ve tested all of this software myself and these are the description of my results. Obviously, the opinions in this piece are my own and may not reflect the impressions held by others.
Usually, I provide links to many things in my articles. I didn’t do so in this one both to save some time and because this isn’t based on articles I’ve read but, instead, my actual experiencing testing accessibility on the Nexus/7.
Back in October, I got a package from UPS containing a 2012 edition, Google Nexus/7 tablet. A friend had sold me the unit for $50 so I could have an Android device in hand to test its claims of accessibility.
For research on this article, I tested only with synthesized speech as my braille skills are abysmal and I cannot write with any authority on a braille interface to anything. I am also only speaking to issues encountered by myself, a person with a total vision impairment. I’d like to be able to write about low vision and other print impairments but, in this article, I’m looking only at accessibility for speech only users with profound to total vision impairment. , In preparing this article, I did the testing alone and will only report on things I actually encountered myself.
For the most part, in this article, I focus on the accessibility of the system in its out-of-the-box condition. As we’ll see, a blind person can have a better than adequate but also substandard experience on an Android device if they install a bunch of software to replace the apps and various parts of the system including the home screen. That Android is so customizable is one of its strongest points; that a blind person really cannot use the device without a lot of customizations is an outrage. To make my Nexus/7 at all usable, I had to install a third party home screen (Apex Launcher) and a whole lot of apps that, ostensibly, exports similar functionality to the inaccessible equivalents shipped by Google on the device.
Corrections and Clarifications
After I originally posted this article, I got a little criticism (far less than I had anticipated) about its content. Some readers asked what version of Android I was running and I received one factual correction regarding a gesture I had not included in the list of such in the original version. Here’s are the clarifications and single correction:
I used the Android Jellybean release for almost all of this testing but, during the final two weeks, I had the Kit Kat release installed. I accepted all of the latest updates when I received the notification telling me to update my Nexus/7. The first thing I noticed about Kit Kat is that the default keyboard does some things, like suggesting spelling corrections and guessing at the next word you might want to type that are popped onto the screen with no feedback from TalkBack when you are in a web view. When I tried to enter my account information in the Nook app, for instance, when TalkBack said, “Submit button” and I double tapped, it replaced the text I had written with another word and ignored my attempt at pressing the button. In it’s default configuration, the default Kit Kat keyboard is not usable in web views and, perhaps, elsewhere. You can turn off the annoying word suggestions or replace the keyboard entirely though if you like but, out-of-the-box, the default keyboard has these inaccessible features turned on and would be a huge problem for anyone unaware of these issues, especially if they do not know how to turn the default features off.
The Kit Kat release fixed a few things so I removed them from the long list of defects at the end of the article. Google Play, for instance, while still not perfect, has fixed some of its tab order problems. Nonetheless, I still couldn’t find a single default app without a single accessibility failure in either version.
Later in the article, I included a list of TalkBack related gestures. I had found the list on the Google web site and, as far as I could tell, it’s the latest and most comprehensive documentation Google has published. So, when I just copied it and pasted it into the article, I assumed that, indeed, as it was the most current documentation I could find on the software author’s site, it was complete.
There are two gestures that include more than one finger. These are two finger swipe up and swipe down. They allow a TalkBack user to scroll some things. As I’ve given my Nexus/7 to a sighted friend who really likes it, I can’t try such myself but I’m told that scrolling lists in Android using these gestures is yet another example of Google implementing accessibility features in a manner entirely unfamiliar to anyone who has used any other screen reader before.
Here, I’d also like to add a response to some of the apologetics used of Android accessibility by some other blind people that had been posted by a friend and accessibility expert to the email@example.com mailing list. This is unedited and pasted “as is” because I can’t find anything to change about it, it’s clear, to the point and definitely true:
“I think that facts are very important. When I hear things like Android is young or Android is open source, it saddens me. that’s not an excuse to do worse, that’s an excuse to do orders of magnitude better. Let’s get out of this systemic complacency mode that Android accessibility is perpetually stuck in, shall we? But, more on that in a second.
“So, having mentioned facts, I present the following:
“1. Android was released on September 23, 2008
2. IOS was released on June 29, 2007
“I’ll save you the math, that’s 452 days. using an approximation of 365.25 days per year, that’s 1.24, rounded, years.
“So, the below argument [an argument that states that the community of people with vision impairment should be patient and wait for Android to catch up to iOS], if I may summarize it, is that because Android is 1.24 years younger than IOS, we should not compare them. this argument already implicitly accepts that the comparison is unfavorable in the first place, otherwise there’s no point in making the unfairness claim, but let’s move on past that.
“I put forth, that with all due respect, this is a silly and vacuous argument, and I request that we, as a community, please stop making it.
“Tesla motors is almost a century younger than Ford. Are you seriously claiming that they get a 100 year pass to suck until their cars can be compared against the modern market?
“There are thousands of little startups in the bay area and Research Triangle Park, just to name two U.S. hotspots, that are less than 2 years old. Are you seriously suggesting that they can’t be expected to compete against the likes of Microsoft, Google, Apple, Dropbox, etc. because they are younger? Never mind the fraction of the percent of budget they have compared to their competitors.
“This is not how the world works, I’m sorry.
“To paraphrase a brilliant statement that Isaac Newton made hundreds of years ago, if I can see farther than others, it is only because I stand on the shoulders of giants.
“So, please, let’s not seriously claim that Google is at some sort of disadvantage because of a 1.24 year difference in the age of an operating system.
“Also, I really don’t understand why this argument is ever made. If we subtract 1.24 years from now, and then compare modern day Android to 1.24 year old IOS, it still comes out unfavorably for Android.
“I didn’t count them each, but there are definitely a few dozen cited and evidence-based points made in Chris’s post. If someone wishes to rebut the post, then can we try using the same techniques, or should we stick to parroting marketing literature and claiming that everything will be better 1.24 years from now?”
#Here’s the original article with a few inline corrections:
My Definition of Accessible
Like anyone who hangs around in the world of access technology, I hear the word “accessible” applied to mean everything from, “fully complies with standards, guidelines, best practices and the OS level accessibility API” to “if one blind person can figure out how to use something, no matter how inefficiently, no matter what portion of the features are available to them, no matter how many items are unlabeled.” I accept only the former and reject the latter entirely.
It is definitely true that virtually every blind computer user, including me, must use software with substandard accessibility. This is the reality of the world today but it should not be the goal. The accessible technology community was asked for standards as mainstream developers were entirely baffled by the “how to” parts of accessibility before such existed. Now, for any web app, web site and any application on virtually all currently popular OS it’s all documented in excruciating detail. There is no reason whatsoever for any major company and most all small companies not to be accessible, using my 100% compliance definition of accessibility. Doing or accepting anything less is tantamount to endorsing discrimination.
Typically, I put the conclusions section at the end of my articles but, in this case, as the rest of this article is a list of specific defects and other issues with Android accessibility, I thought that putting the conclusions at the top may allow some who don’t care to read the details to get a quick idea of my experience.
- in comparison to an iOS 7 device, with zero out-of-the-box accessibility failures and only a few accessibility bugs, a Nexus/7 comes shipped with zero built-in apps that do not contain between one and many accessibility failures. The accessibility issues on Android, therefore, are not just bugs but a systemic problem at Google.
, * Some standard apps, shipped on the Nexus/7, apps like those for playing movies and television, for reading books and browsing the web, the out-of-the-box accessibility is poor at best.
A blind person can use an Android tablet to accomplish a lot of tasks but will encounter lots of accessibility failures along the way. A blind user with very strong technical skills and/or a whole lot of patience can find fully accessible software from third parties to replace those shipped by Google and the people on the “Eyes Free” blind Android user mailing list can and will help individuals navigate this process.
The PDF manual for the Nexus/7 is “untagged” and, therefore, not actually accessible. As there are all sorts of programs out there that can test the accessibility of a PDF, Google obviously intends to make its documentation inaccessible by choice or, at best, is guilty of willful negligence.
The TalkBack screen reader is, while feature poor, actually pretty good. Unfortunately, the Google developers making the apps shipped with the device seem to ignore Google’s internal standards and refuse to use the accessibility API properly. Investigation of the Android accessibility API also shows that some very standard accessibility features, like being able to create a fully accessible web view, are far more difficult than on other OS, a likely source of inaccessibility on this platform as, if an app developer wants to be fully accessible and fully comply with the Android API, they still won’t be guaranteed to have an accessible app in the end. Making accessibility more difficult on one OS than on others is not going to promote accessibility on a platform.
If you like playing around with work arounds, figuring out an interface that fails the basics of human computer interaction (HCI) and figuring stuff out, if, indeed, you like the inconveniences encountered by early adopters, Android my be for you; if, however, you are looking for a pleasant accessibility experience, you’ll avoid Android for now.
Google insults the community of people with print impairments by claiming that this device is accessible. The accessibility is, at best, a functional prototype of something better to come in the future but Google seems to believe that this is an adequate solution.
People with profound to total vision impairment must eschew all devices that provide less than the “gold standard” of 100% out-of-the-box accessibility as, accepting less than 100% will only encourage corporations to provide us with incomplete solutions in the future. If we reward Google with our dollars today, we’re telling them that this state of affairs is acceptable, a tremendously dangerous statement to make.
My Experience With Android
After receiving my Nexus/7 from UPS, I turned it on and ran the setup routines. Then, as its battery was low, I charged it up and on the next day started actually exploring it.
This is my story:
- The first thing a human factors student learns is “leverage what the user already knows.” As all other notable screen readers and every published “best practices” guidelines for accessibility says, “everything must be available in the software’s tab order.” As this simple, obvious to test task is ignored in some parts of virtually every app that carries Google’s brand name, in this case, they are ignoring their own accessibility API in a systemic manner. This is something that could easily be added to Google’s automated test procedures but, apparently, that isn’t a priority for Android accessibility.
A developer can make UI decisions that do not comply with “best practices” if and when they have done the research to demonstrate that a different approach is actually more efficient or more enjoyable for their users. This is how UI innovations come about. Google, on Android and in many of its web apps ignores published standards, guidelines and best practices regarding accessibility, including standards that they’ve set for themselves in their own API. They do all of this without publishing an iota of data that demonstrates that, indeed, people with vision impairment would prefer a departure from the best practices followed on every other system.
- Another major departure from best practices on the Nexus/7 also results from the tab order being ignored. This comes from the human factors concept of “discoverability.” It is essential that users be able to find features as easily as possible. On iOS 7 and Windows 8.1 (I haven’t tried using Gnome with a touch screen) one can find everything by just swiping. If you don’t know what you’re looking for and you miss it while exploring by touch, then there is a feature that you cannot easily discover – another violation of not just accessibility but general design principles for software.
This article is about the out-of-the-box experience I had with a Nexus/7. As no hardware keyboard comes with the device, I did not testing with a physical keyboard. I’ve heard reports that Android works poorly with an external keyboard but I cannot comment as I haven’t tried it.
Needless to say, a gesture interface is the core of how most people access a tablet. It is the fundamental interface blind people use on Apple’s iOS devices and it seems to be the interface of choice on the Nexus/7 Android tablet.
This is what I found regarding gestures on this tablet:
TalkBack uses right angle gestures, like swipe up and left or down and right. I use them without a problem but, given the amount of chatter on the Eyes Free blind Android user list from people struggling to use them efficiently, I can only conclude that Google thrust this UI decision on TalkBack users without doing any actual usability testing. on iOS 7 and Windows 8.1 blind user mailing lists, I never hear people complain that they cannot figure out how to make a gesture work after using the same device for a few weeks the way I do on the Eyes Free mailing list from a fair number of blinks trying to use Android. If more than a tiny fraction of a user population has problems with a gesture, it must be considered to be a field failure.
I had trouble finding a gesture to perform a “SayAll” like two finger swipe down in iOS. I did find a setting that would allow me to assign “read from top” or “read from next object” in the TalkBack settings for gestures. As SayAll is about as common a screen reader feature everywhere, why would, without publishing a reason for doing so based in some kind of evidence based model, this not be on by default as it is in every other screen reader that has ever existed? One can do a say all by shaking the device but this seems an inelegant replacement for a gesture.
gestures seem to be recognized slowly. I’m told this is a function of Nexus/7 hardware and not due to TalkBack but I’d like to learn how quickly things happen for sighted users as a comparison.
Why would, by default, swipe up and swipe left and swipe right and swipe down do the same thing? In general, it seems that there are far too few accessibility related gestures available to the user and wasting some of the simplest ones seems bizarre.
Accessing some other very common screen reader functions, like changing granularity, requires three gestures, a right angle followed by two circles. A bit of snark, “Draw the pentagram, dance in a circle, light some incense – was this interface designed by a coven of witches?
Default Android Gestures
While VoiceOver on iOS provides a user with a rich set of one, two and three finger gestures, Android/TalkBack provide only the following:
- Two part vertical gestures: (swipe up and down or down and then up)- Cycle through granularities.
- Swipe up then right: Open local context menu
- Swipe up then left: Home button
- Swipe down then right: Open global context menu
- Swipe down then left: Back button
- Swipe right then down: Open notifications
- Swipe right then up: Unassigned
- Swipe left then down: unassigned
- Swipe left then up: Recent apps
- Two finger swipe up and down: scroll a list
Why do all but one of these gestures use only one finger? Is it physically impossible for Android to handle multiple finger touches? Why are there two unassigned gestures when one can turn on two variations of “say all” from the TalkBack settings dialogue? Why do most of the TalkBack gestures require one to make a right angle on the screen while there are so many possibilities left unassigned? Until someone at Google answers these questions publicly, I will maintain the impression that this UI was designed by a programmer’s personal notions and not science.
Editor’s note: In One of the criticisms of the original version of this article, people have said that Apple has all of their gestures wrapped up in patents and that Google could not, therefore, use them with TalkBack. As Microsoft, in Windows 8.x, has added a set of gestures in Narrator that are nearly identical to those in iOS, I doubt this is actually a problem for Google. Theres no technical nor HCI reason for such a radical departure from the gold standard.
Here is what I found trying to navigate around the Nexus/7 system:
TalkBack, in its default configuration,, makes it impossible to read non-editable text by word, character, line, sentence, etc. One can turn on the vertical swipe gestures to allow for switching granularity but must find their way to TalkBack settings to perform this action.
In many places in apps shipped by default with the device, there are controls that one cannot get to by swiping. This makes learning what’s available to a user pretty difficult as exploration by touch is simple but, if we don’t know what we’re looking for, how do we know what’s there?
The HCI concept of “discoverability” seems to be ignored entirely as finding objects on the screen is often a “hunt and peck” process that feels a bit like playing an adventure game.
Here are some notes on basic operation of the Nexus/7:
The default synthesizer doesn’t speak fast enough. I know one can install third party synthesizers but the one that comes out-of-the-box, on its fastest setting, is too slow for my taste. Unlike iOS, though, where one cannot choose a third party synthesizer, I could buy one I like more for Android, a definite benefit to the more open system.
Most buttons and some other controls aren’t labeled as buttons so speech only says the text in them and I thought they must be headings. Unlabeled controls vastly outnumber those with something meaningful like “button.” I understand that, in some places TalkBack uses an earcon, a tone played instead of saying a word to convey information. Earcons are a terrific idea similar to the Speech and Sounds Manager in JAWS but, as TalkBack seems to use them in some places, text descriptions in others and does nothing at all to indicate a control type in many other places, the system is so inconsistent that none of the indicators are of much value as they only seem to occur randomly.
Documentation and Resources
The TalkBack documentation is either non-existent or entirely out of date when one searches for it on Google. There is an article about accessibility gestures on the Nexus/7 published by Google itself that contains some accurate and some completely wrong information.
It seems that the only way to learn how to use the various accessibility gestures available using TalkBack, is by going to the settings dialogue and read the settings as there is no other place this is written down.
Compared to documentation about VoiceOver, JAWS, Window-Eyes and the free, written mostly by volunteers, NVDA and Orca, this looks entirely like a project led by a kid in a dorm room somewhere and not a professional development team.
JustSpeak is a new voice recognition accessibility service from Google. It allows one to say things and then TalkBack will take action. This software is incomplete and incredibly buggy. There are my notes on it:
With JustSpeak running, one cannot control TalkBack volume. Why doesn’t it allow the volume rocker to work while watching a video?
JustSpeak would be a useful tool if it had a command that would tell the user what can be said in a specific context. Especially in an app where controls aren’t in the swipe order, it would be useful to be able to say, “List controls,” and hear something like, “Controls on screen: Play, Fast Forward, Rewind…” or whatever is there in an application. This would be similar to the list of objects that JAWS has via JAWS+F7 or the Item Chooser with VoiceOver.
JustSpeak seems to do really bad things to the hardware volume control. I’ve heard TalkBack say, “Volume set to zero” without the actual volume of the device dropping at all.
JustSpeak seems to have crashed while I was writing this piece but restarting it in Settings got it working again without much problem.
I think Google refers to JustSpeak as a beta but, in my mind, it’s less than an alpha and, at best, can be described as a functional demo.
The Default Android Apps
After turning the device on for the first time (the friend who sold me the device had already turned the screen reader on), I found myself in the setup routine and encountered the following list of issues:
- The on screen Keyboard is not in tab (swipe) order so, for a person new to the system who may not know that they need to first explore the screen with their finger to find it, the on screen keyboard’s location is not obvious. .
- The email one gets for setting up the device is loaded with accessibility failures. I can only say that, if Google indeed cared about accessibility, they can make their entire system compliant with web accessibility standards and guidelines.
This is what I found exploring the default Android home screen, after a few days of using it, at the recommendation of some helpful people on the Eyes Free mailing list,I installed a replacement home screen called “Apex Launcher” which is far more accessible:
- Within ten seconds, I found an unlabeled graphic announced as “Image 53, Unlabeled. If a device claims to be “accessible” it should have zero such defects. Finding and fixing such problems is trivial and could new included in the Android automated test process but, as they obviously don’t care to become fully accessible, they ignore such insults to our community.
I tried to go through every app that came shipped by default with the device. As I found none without serious accessibility defects, I stopped trying so these are the notes I’ve made on various apps that I did try:
The Google Chrome app seems to be entirely usable but, as TalkBack is fairly feature free in the browser, it isn’t actually accessible to anyone who considers “efficiency” to be part of accessibility.
Having no ability to navigate a web page by semantically useful “chunks” like heading, form control or anything other than swiping by object makes browsing excessively cumbersome. As this is a feature that has been in JAWS for more than a decade and in VoiceOver on iOS, I ask, why is Google still pushing a Model T on us?
The default Chrome home screen contains unlabeled images. Again, how difficult or expensive would it be for a massively wealthy company like Google to fix?
Trying to read Google search results without being able to navigate by heading is very time consuming and cumbersome.
I like the “ear cons” audio effects played for VoiceOver users on various web objects.
After a little while, I stopped using Chrome on the Nexus/7 and installed Mozilla FireFox. While not a default app, I can highly recommend FireFox to any blind Android user. Mozilla’s team obviously spent a huge amount of effort making FireFox accessible, very accessible on this platform. It’s unfortunate that developers need to do so much to make a fully accessible browser on this platform but Mozilla’s team has demonstrated that it is possible to make a browser on Android profoundly more accessible than Google attempted with Chrome.
This app seems to be mostly usable but has major accessibility problems.
everything is in the swipe order, reading the stories can be pleasant if it doesn’t contain too many unlabeled things.
In a read all (started by shaking the device) in a Popular Science article, speech got stuck on “Heading Image” and read it repeatedly until I stopped it.
Tapping on the title of an article most often opened a different article than the one I wanted.
This app seems to be marginally usable but it contains some areas that a user must find by moving a finger around the screen. Many items seem not to be in the “swipe” (tab) order. It’s easy to get lost..
Reading a book is difficult as navigation seems to break in many places.
I seem to have found “temporary” buttons that TalkBack announces but that disappear before one can act upon them. This is a violation of all published accessibility standards, guidelines and slaps best practices in the face.
Play Movies and TV
It was really hard getting gestures recognized while playing a movie.
With JustSpeak running, I couldn’t change the volume of the video using the rocker bar on the device.
Finding the “pause” button proved impossible for me while playing a video.
Lots of items seem not be in swipe order.
App contains at least one unlabeled image.
No buttons are labeled as such.
I can only describe the accessibility of this app as a total failure.
The YouTube app is more usable than Play Movies and TV but describing it as “accessible” would be a stretch.
When a video is running, swiping from control to control is very slow.
Many swipes resulted in a sound playing with no voice feedback. It was unclear if I was actually moving around the interface, if there was an object on which I had landed, etc.
The volume rocker, likely due to JustSpeak, causes TalkBack to announce that the volume has been set to zero (when I had hit the volume down side of the rocker a bunch of times) but the actual volume of the video doesn’t change.
I found at least four unlabeled buttons in this app.
The default Android calculator app seems to be usable but has a number of curious aspects to its UI.
The swipe order seems somewhat random as sometimes it loops back around a group and other times it goes to everything in the interface and I could not tell you why.
The calculator does not honor the setting for typing by removing one’s finger from the last spoken item.
I was really looking forward to trying out an Android tablet. Friends like Aaron and Josh speak so highly of Android accessibility that I wanted to give it a whirl. Sadly, what I found after spending a few months with the tablet is that it isn’t actually accessible the way iOS 7, Windows 8.1 and even Gnome are. The Google accessibility team must have little or no authority within Google corporate as these problems should be simple to remedy if they wanted to make a fully accessible solution.