[This is an edited and corrected version of the article I posted on 2/21/2014. As always, when a factual correction is presented, I go back and fix the problems. I’ve listed the two factual corrections in a section following the Introduction section. I’ve also made a few grammatical changes but these change nothing at all in the theme of the article.]
Thus far, we’ve explored Android accessibility from my personal perspective a (totally blind user who doesn’t read braille) and from the view of a deaf-blind person who access his computational devices using braille only. The results of these extensive bits of research (I spent three months using a Google Nexus/7 on a daily basis and Scott tested as much as possible with braille only) demonstrate that, from the perspective of these two classes of user, that, out-of-the-box, the Android accessibility experience is dismal. This article, the third and probably last entry in my Android series demonstrates why, according to a number of blind Android developers, this is the case.
I was under the impression that the Android GUI was based in Gnome’s GTK. I had heard and had this confirmed by a Google employee and a pair of experts in such things. After posting the article, Matt Campbell (author of the SystemAccess screen reader as well as all of the other programs from Serotek) sent me an email saying that I had got this detail wrong. Later in the day, Peter Korn, the guy behind the excellent accessibility framework in GTK, posted a comment correcting me as well and, well, if anyone would know it is Peter so I’ve removed references to the relationship between Android and GTK from this article and replaced it with a generic paragraph on accessibility API from which Google could have used to, to misquote Isaac Newton, “stand on the shoulders of giants like Peter, the Apple and Microsoft teams, Aaron Leventhal and all of us who participated in some way in working on the excellent accessibility API on the other platforms.”
Steve Nut, the guy from Serotek’s “That Android Show” posted a largely erroneous comment (see below) in which he stated that Kindle on Android is “accessible” which, given my high standard for the definition of the word “accessible,” it is not. He is correct in his assertion that, indeed, Kindle does exist on Android so I added the adjective “accessibly” after the word “exists” in the paragraph where I mention it. In a comment below, I’ve asked Steve (a really good guy in spite of his fan-droid fixation) to write a specific definition of the word “accessible” so I might understand how he can conclude that, indeed, Kindle is “accessible” on Android. I sincerely hope he posts such as I honestly do not understand how anyone can use the word “accessible” to describe something that does nothing more than talk and is completely, 100% inaccessible to our deaf-blind friends like Scott.
Lastly, I decided to remove the word “Kindle” from this article entirely. When I tried using it on Android, I found a pile of accessibility problems. There are workarounds to the biggest problems I found and, frankly, including Kindle in this article is just a distraction as, while some find it accessible enough to use, I don’t want to spend any more time thinking about it.
Who Am I?
For readers who do not know my background, I’ve been programming computers since 1971 when I wrote my first program at age eleven in the computer science area of Lawrence Berkeley Labs (LBL) in California. I became a professional computer programmer when I accepted my first job in the business in 1979 at Lincoln Savings (don’t blame me, I was only 19 years old and never met Charles Keating). In 1983, I moved to the Boston area and jumped into personal computer software development. When, in 1998, after taking a couple of years off from making software as I had lost the last of my vision, I accepted a job as Director of Software Engineering and later would be promoted to the VP position at Freedom Scientific. Needless to say, I understand how to make software as I’ve been doing so for the majority of my life and, baby, we’re not so young anymore.
Nonetheless, I have never even tried to write a program on the Android platform. I do not know the Java programming language which is what most Android software is written in. I’m mostly a C/C++ and assembly language programmer and I don’t know a whole lot about more modern programming systems, languages, UI and so on. Thus, for the purposes of this article, I took a number of posts from the email@example.com mailing list written by blind programmers whom I know personally and have called a few blind Android programmers on the phone for further clarifications. These other programmers have all made fully accessible software on Windows, iOS, OSX, Gnome and have done so in multiple versions of these OS over the years. These people work at APH, in the PhD program at NC State University, EZ Fire and, in one case, had worked on the popular “Q Read” book reading software for Windows.
My personal expertise in this subject comes from having a solid understanding of how software is made and, having worked on the committee that whose work product was intended to be a cross platform accessibility API but that, instead, led to the Gnome, Apple and Microsoft (UIA) accessibility API which, while incompatible with each other, provide a full set of features that developers can use to easily make their software accessible.
A Generic Look at Accessibility API
Over the years, there have been a number of books, articles, web sites and other sorts of publications that provide a list of all of the controls needed in a graphical user interface (GUI). I will not take the time here to summarize them as this isn’t an article on GUI but, suffice it to say, all modern GUI with any popularity (Windows, OSX, Gnome, iOS and Android) provide all of these different types of control for programmers to use in their software.
On Windows (XP or newer), OSX (Tiger or newer), Gnome (2.0 or higher) and iOS (version 3 or higher), every one of the 20 or so controls available in the GUI has a corresponding element in the accessibility API. The most complicated of the popular controls is the “web view” which a programmer might use to add HTML information to a piece of software and, of course, the web control should behave identically to a web browser when a user of access technology encounters such.
The Android Accessibility API
For a long time, most of the three months I spent with the Nexus/7, I made the wild assumption that most of the accessibility problems Scott and I had encountered and documented in the previous articles were the result of the Google branded apps ignoring the accessibility API, a programming crime if one intends to do no evil as such programming decisions enforce discrimination against our population. While this action is horribly wrong, especially at a company that can easily afford to get it right, it is easy to fix. To put all controls into the tab/swipe order, to ensure that all controls have labels, help text and such is nothing more than typing and can be remediated easily by an intern with the IDE in hand.
Then, my friend Tyler Spivey tried to port Q Read, an Windows based epub reader to Android and I started to learn that the Android accessibility API, the infrastructure necessary to ensure a fully accessible GUI, was sorely substandard when compared with Windows, iOS, OSX and Gnome.
What makes this all very confusing is that the Android accessibility is the newest in a line of increasingly powerful accessibility frameworks on the market today. When MSAA was the only accessibility API it was the “best” one by default. MSAA wasn’t very good but it was the first and developers concerned with accessibility learned a lot from it. The next generation of accessibility frameworks, Gnome/GTK, iAccessible2, UIA, OSX (in Tiger) showed dramatic improvements with concepts like “relationships” and “contexts” making their first appearance as well as being the first group of accessibility API to support large blocks of text and complex objects like web controls. The latest generation of accessibility API come from Apple on iOS and Google on Android. Having had the shoulders of giants on which to stand, how did Apple continue to show progress and innovation in the iOS accessibility API while Google, given mountains of reference materials and access to every accessibility professional on Earth (we all have our price) showed a major step backward in this type of technology?
Making An Accessible Book Reader for Android
Tyler Spivey, a blind Canadian hacker of tremendous skill and reputation for doing what other programmers cannot (among those in the know), tried to port Christopher Toth’s popular epub reader, Q Read, to Android. The first step in this process is to create a text control in which the app can stuff its data. As this is 2014 and that every other major operating system (Microsoft’s Windows, Apple’s iOS and OSX and GNU/Linux running the Gnome desktop) provides a text control that is fully accessible out-of-the-box, Tyler expected that Android would also provide such and, sadly, he was greatly disappointed.
In any operating system other than Android, one gets an accessible text control “for free.” Using pseudo code, to add a text control that allows a screen reader (for instance) to provide features like reading by object type (headings and the like), semantic elements (word, sentence, paragraph, character), filling out forms and performing every other task available in virtually all other systems, one writes code that looks like the following:
MyAccessibleTextControl = new GenericTextControl;
That’s right folks, a programmer who wants a fully accessible text control in his app only needs to write a single line of code and it will work with any useful screen reader on that platform. For those of you who enjoy attacking me with ad hominem and repeat that my opinion is colored by a “love” I have for iOS, I’ll remind you that this example is true not just on iOS but also on Windows, OSX and Gnome.
The substandard Android accessibility framework will allow for making a text control accessible. I don’t know every type of control used by Barnes and Noble in their Nook app so I’m uncertain if the main reading window is a standard Android text control or if it’s entirely custom but B&N have obviously spent a tremendous amount of time and money to make an accessible book reader for Android, time and money that is not required to do so on any other OS.
An Inaccessible Web Control
In current software, especially on mobile platforms, many programmers like including a web control in their app so they can display HTML information and use the web control to drive features in the app itself. Like every other popular OS, Android provides a web control in its UI library. Unfortunately, largely because the web control is built on top of the Chrome code base (this only beam true when Google released the Kit Kat revision of Android) and Chrome, as a stand alone app or as a web control, is simply not accessible in the way that web controls are in Windows, Gnome, iOS or OSX.
Again, using pseudo code to illustrate the issue, making an accessible web control on the other popular operating systems would look something like:
MyAccessibleWebControl = new genericWebControl;
What We Lose Due to Having No Accessible Text or Web Control
Let’s take a look at a lot of popular software used by blind people on other operating systems. We have programs like Q Read, VoiceStream, NLS Bard Mobile and others that depend on having an accessible web and/or text control. These useful and popular programs do not exist or are not fully accessible on Android. In two cases, I’ve had the opportunity to communicate directly with the developers of these programs and asked them why they hadn’t ported their software to Android. The answer was identical in all cases, “we tried porting to it, we do not have the resources to make the web or text control accessible.”
If you want to point to some of the very accessible apps available on Android, programs like the popular Nearby Explorer for instance, I need only remind you that these are usually “self voicing” applications that work around the broken accessibility framework by talking directly to a speech synthesizer. These “ghetto” apps are used exclusively by blind people and dash the notion of universal design by ignoring such principles. Ghetto software was a necessary evil in the days before accessibility API as making a mainstream app fully accessible was very difficult. The excellent accessibility frameworks on iOS, Windows, Gnome and OSX obviate this requirement as, with the new technology common to all platforms other than Android one can make a mainstream app as accessible as anything targeted specifically to the population of people with print impairment.
Some apps designed specifically for our community, apps that perform special tasks that most mainstream users wouldn’t care for should have their UI designed using the same principles of universal design as the mainstream apps. Some of these apps will be useful to people with print disabilities unrelated to blindness and the AT they employ needs the same compliance as do programs used by blind people.
Is Making An Accessible Web Control Too Hard For Google?
If one simply takes a look at the Android version of the FireFox browser, developed by Mozilla Foundation, a group with a budget when rounded to integers comes to 0% of the Google revenue stream, they will find as accessible a browser window as exists anywhere, on any OS, ever. If a team with no money at all (when compared to Google’s dollars) and a staff tiny in comparison can do it, making a fully accessible web control and, indeed, making Chrome into a useful solution, cannot possibly be too difficult for a company like Google to accomplish. Similar companies, Microsoft and Apple have done it for years now, the Gnome Foundation does it really well, what, therefore, is the cause of Google’s failure to comply with generally accepted accessibility practices?
What Does Google Need to DO to Remedy These Problems
At the API level, to make Android as accessible as is the generally accepted standard, they must:
- Make the accessibility API more “automatic” as it is on the other OS. It should be nearly impossible to use a standard control, whether something simple like a button or complex like a web view and not get the accessibility by doing more than typing a few words into edit boxes in the IDE.
- Fix Chrome, both as a stand-alone browser and as a control in other apps, to be as accessible, using the same generic accessibility techniques as the other OS, as IE, FireFox or Safari on various other platforms.
- Fix the text control in the same manner as the web one.
To make Google branded apps accessible, Google must:
- Enforce its own internal accessibility standards on its own product teams as part of the the other requirements for releasing software to the public. This is, perhaps, the most frustrating part of Google’s poor accessibility as accomplishing this simple goal would be very inexpensive in terms of engineering hours, testing and so on. That Google doesn’t already do this demonstrates that they do not have a corporate wide accessibility policy but, instead, leave the decision as to whether to enforce segregation against this population up to individual product teams.
- Make sure that all of its web apps, Google Docs, Analytics and such are fully compliant with the Web Content Accessibility Guidelines (WCAG 2.0) at its AA level. Soon, this will be the requirement for all US federal government sales under the Section 508 Refresh so, if they hope to sell to America’s largest customer, they should probably get started on this effort now. Of course, if “doing no evil” is part of their actual strategy, Google should do all of this because discrimination is evil and they should stop doing it on purely moral grounds.
The only conclusion I can come to regarding Google’s accessibility, from the perspective of a career software engineer, is that it is a failure. It is probably not irreparable but, as they are one of the wealthiest and most powerful technology companies on Earth, that they claim to have an accessibility strategy, that they’ve released products with the claim that they are accessible, that zero Google branded apps on a Nexus/7 running Kit Kat are entirely accessible, that Google Docs, Analytics and other of their web apps completely ignore WCAG and a long laundry list of other Google accessibility failures, I must conclude that poor accessibility in Google products is intentional as, otherwise, what is the logical conclusion?
I’m sure this article, although entirely based in fact, data and the impressions of experts, will draw me a pile of ad hominem from the fan-droids. If you are one of these people and you want to tell me that I write these articles only because I “love” iOS or Apple in general, I ask that you first read an article I wrote when I did the BlindConfidential blog. It’s called “Apple Just Sucks” and describes the opinions I then held of that company before they set out on their excellent accessibility effort. When I write that something has excellent accessibility, it is because I’ve tested it extensively and when a new player comes along with something better, I revise my opinions based on the new realities. In the BlindConfidential days, if one goes back and reads all of the articles about screen readers I wrote then, they would notice that, when I started, I wrote that JAWS in Windows XP was the best solution and, at the end, I had switched to Macintosh. I had used a Windows Mobile T-Mobile Dash running the Code Factory screen reader for a few years as it was the best thing out there, then, when Apple released the 3GS with built-in screen reader and all, I switched.
The opinions I hold are not based in my own personal preferences, that would mean I’m speaking from a statistically insignificant sample size of one. To make matters worse, my personal preferences tend toward UNIX like command line shells, using emacs for a whole lot of things and, generally, having a very “nerdy” view of technology. When I write about accessibility, I do so with one eye on generally accepted standards and guidelines and the other eye on usability when compared to systems people with vision impairment are already accustomed to using.
People yell at me, you just want Android to be the same as iOS,” which is true on the macro level, I want Android to be (rounded to integers) 100% compliant with its own, internal, defined entirely by people at Google, accessibility API the way that iOS is already. Apple even takes iOS accessibility a step further in that, along with being 100% compatible with its internal accessibility API in all of its apps that come out-of-the-box in an iOS/7 device, all Apple branded iOS apps that one can download from its AppStore are also fully compliant with its accessibility framework. I do not insist that Android have the same apps, the same functionality, the same user interface or any of the features that, competitively, would make a difference, I just insist that it become fully compatible with its own standards the way that Apple and, to a lesser extent, Microsoft and the Gnome Foundation have already done. That isn’t “bias” toward Apple but, rather, a strong inclination toward generally accepted standards for accessibility.
I thank the people on the “Eyes Free” blind Android user mailing list for setting me straight about so many facts that I had gotten wrong in my early analysis of the Nexus/7 I bought back in October. They also pointed out what, in fact, in my assertions were purely opinion and, as a result, forced me to work much harder on these articles than anything I had previously written on this blog. Typically, when I do a technology review, I would have spent between hours and a few days evaluating such; with the series of Android articles, I spent more than three months doing the user research and many hours reading email posts, doing quick and dirty statistical analysis of the type of problems reported on Eyes Free versus user lists for iOS and Windows and much more. That these articles have become some of the most popular in the history of this blog reflects the extra work as the articles are fact and data driven and, since I published the revised and corrected versions of the articles (I’ve fixed a few relatively minor things people have reported as incorrect) in the series, not a single fact has been disputed by thousands of readers.
So, if you love Android so much and want to yell at me, feel free. I’ve never edited a comment for anything but to remove racist and sexist epithets and, as you can read here and in the BlindConfidential archives, you can see that I’ve allowed any commenter to say whatever they want about me. I do request (not insist), though, that you try to attack my articles with some level of intellectual clarity. Saying, “Well, I love my Android device,” is a nice statement of opinion but it neglects any notion of best practices, standards and guidelines and, frankly, it’s an entirely selfish view of things as the standards were developed in such a manner as to address issues faced by people with a panoply of different disabilities and, just because you can use something, doesn’t mean that it is accessible to everyone else. This specific point is illustrated greatly in Scott’s article about the experience of a deaf-blind user of Android which, unlike my first article, received absolutely no criticism. Sadly, if Google’s accessibility API actually worked properly and they were faithful to using it in their apps, Scott would be enjoying using an Android tablet today, alas, it is impossible for him to use.
If you insist that Android is accessible just because you can enjoy it, you are, by making the claim that Android is accessible, is no more than dooming others who, for any variety of reasons from disabilities other than yours too having a different aptitude for technology, to a miserable experience compared to that which they can enjoy on iOS, Windows, GNU/Linux/Gnome or OSX. The fact is, whether you like it or not, “accessibility” due to laws like CVAA and ADA Restoration Act are growing a legal definition and, if the level of accessibility out-of-the-box in an Android system is allowed to pass as “accessible” we will be lowering the bar for the definition of “accessible” when compared to all other major operating systems. It is essential that we, as a community, push the highest bar that currently exists as the minimum standard for accessibility as, otherwise, we’ll never get anything better.