Introduction
[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.
Corrections
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 accessibility@google.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;
Windows programmers may need to add a couple of lines of code to ensure that the control has properly gotten focus but this detail requires a total of fewer than five lines of code on any OS other than Android where providing a fully accessible web control in an app can require hundreds of lines of code, special JavaScript code to tell only one screen reader on Earth what to say and, in general, even in the best circumstances, will provide a sorely substandard experience for the end users.
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.
Conclusions
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?
Afterward
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.
As an Android developer myself (I wrote the Spiel screen reader, for anyone not in the know) I’d like to offer my own perspective on some of this.
First, I’ll start with the positive, if only because I’ve taken shit from folks about being too negative lately. The API is evolving at a rate greater than it once was, and in looking at the direction in which they’re going, I can see the shape of an API that provides many of the features we’d need in an accessible solution. 4.0 gained touchscreen support. 4.1 got gestures, and the ability to hook actions into a variety of common (and down-right screwed up) touch movements. I don’t recall what 4.2 got, but we now have the ability to hook keystrokes, send announcements (generic accessibility events that don’t necessarily correspond to an action, like turning a page or locking a screen) and some sort of live region/ARIA-like support in 4.4 that I haven’t fully worked to understand. So, in bright news, we’re seeing a greater evolutionary trajectory than we saw in the time between 1.6 and 4.0, during which I seriously heard someone tout “we can end calls with a press of the Power button now!” as a great accessibility enhancement.
Now on to the bad. During one correspondence with someone internal to Google accessibility who I won’t name, I was told that Google was basically doing the smallest thing they could get away with, to see how it worked, and then iterate on that. Don’t get me wrong, that’s sound thinking in some areas. If I had an idea for a startup building a social network for lizard owners, for instance, that’d make a whole lot of sense. If I built the whole network only to discover that lizard owners wanted to hide under a rock with their pets and not be social, then I’d have wasted lots of time and effort. But maybe after building the part that lets owners register themselves and their lizards, I discovered that they didn’t want to socialize but instead wanted to have orders of their custom lizard food delivered in a timely manner…then I’ve done the minimum I possibly could, learned something valuable, and I didn’t waste effort building something no one needs.
But, as you yourself have pointed out, there are and have been a variety of accessibility APIs available to study for years. Literally within days of Android 1.6 being released, I filed an issue requesting access to the keyboard via the API, since most other APIs provided that functionality. 4 years later we got it. I filed another issue that same day requesting access to WebViews, and was asked in a comment which details I wanted access to. Given that a multi-billion-dollar corporation should have the resources to do this research themselves, it baffled me as to why they expected a solo developer who at that time was in the midst of planning for a move and on limited financial resources to do so himself.
Similarly, the QA in the accessibility APIs is horrible. There was some major issue in 1.6–maybe we couldn’t arrow around text fields or something–that I found within days of beginning development. Keep in mind, my very first Android app was a screen reader, so in between learning how to set up a development environment and figuring out how to use Android in an emulator and learning how apps worked and writing one that integrates with a rather niche and poorly-documented area of the SDK, I was finding bugs in their implementation. The issue was reported, was indicated as being known six months and several major Android releases later, but I don’t think we got a fix until Android 4.0 came out in 2011. We pick on Google for not QAing their apps, but I don’t think they’re QAing their APIs either, and that’s worse. It’s building a crappy house on a rotten foundation.
I won’t say much about TalkBack, other than to note that Spiel is about 5000 lines of code, a fraction of TalkBack’s size, and while it isn’t as featureful as I’d like, what it packs into those 5000 lines is significant. I use it on my phone despite its missing features because it is faster, easier to modify, and I feel represents a better base than TalkBack. Every few months, I try doing a bit of ra-raing about how I want to continue development, how I want to push out a solid 3.0, how I’d like to blog about a roadmap and crowdfund money to work on it for months. Know why I don’t? I can’t get excited about Android anymore, and won’t until it becomes a compelling and accessible platform.
So why not just jump to IOS? I’m an odd blind person in that, while platform accessibility is important to me, platform openness is almost as if not more so. I want to write code that enables some pretty awesome stuff. Hell, my long-term goal is to sail a boat as independently as I possibly can, and integral to that is a platform that lets me write and iterate code quickly so I can integrate with whatever open systems exist in 10 years for GPS, radar, comms, AIS and the dizzying array of marine tech we have for tracking obstacles and identifying vessels. I don’t think a platform that charges $100/year for the right to install apps to my own device and requires me to develop on a platform non-native to me is that. I used to think it might be Android, if only because I wouldn’t be playing with Google’s apps if I spent most of my time in mine…but I’m starting to wonder. More and more I regard the Android codebases I’ve created for GPS navigation and map exploration as experiments, destined to be re-imagined on FirefoxOS or Ubuntu Phone or SuperFuckingAwesomeFuturePhone or whatever else exists in 10 years. And that’s sad to me, because accessibility and Google stranglehold aside, Android is a nice platform for integrating with external hardware and rendering to a touch interface. Maybe Google will pull an Apple and will start showing us the respect we deserve between now and 10 years from now. Sorry, Google, but I can’t hold my breath for that long.
Chris, a minor correction: Android is not based on GTK+. The programming language for Android is Java, and the Android Java apps execute in the Android virtual machine (Dalvik). GTK+ apps are commonly written in C and Python (and other languages for which there are GKT+ library bindings). While it is certainly the case that Google or anyone else can learn from and adapt the GNOME Accessibility API to some other platform (subject to LGPL v2 licensing where the adaptation actually involves copying code), it is not true that Google left the GNOME Accessibility API behind when they ported GTK+, for the simple reason that they did not port GTK+ as part of developing Android.
I am currently studying to become a visual rehabilitation therapist (VRT), and have been assigned to assess the accessibility of Android from the perspective of a VRT teaching clients to use such devices. My findings, confirmed by this post, indicate that as a VRT, it would be best not to discourage someone from learning and using their Android device if they come in with one, but I would not encourage someone to buy it as it is now.
In regard, to Android being useable to some but not accessible to all, iOS also has this problem, as some with neuropathy have trouble manipulating the touch screen. Of course, a Blue Tooth Keyboard would be a fairly simple solution, but the idea of mainstream accessibility goes out the window their.
Android isn’t growing as fast as Apple has. That being said we’ve seen some pick up in the accessibility side of things as mentioned above. iPhones are great for people who have just lost there sight or who are wanting an easier time with an accessible phone. If your happy with the limitations Apple enforces then iPhone is the best thing sense sliced bread. I’d take a hit to accessibility for the openness of Android. Another thing not mentioned in your article is the accessibility from Google released phones to phones carried by AT&T, Sprint, T-mobile and the other companies. Part of the accessibility hold back is due to the phone carriers not pushing the Google updates. For example I was using a galaxy S3 and I didn’t get Jelly bean until almost half a year after it was released because AT&T had to insert all there apps and totally unhelpful modifications. This plays a huge part in the day to day users accessibility. Also Apple has had years to get the accessibility aspect figured out because of voice over on the computers. They then just took that knowledge and hard coded it into there phones. I see Google catching up with in the next few years and until they do I plan on supporting Android. Does that mean I’ll I’ll ignore another phone that shows up who’s better with accessibility? Nope, I can’t aford not to keep my eyes on the up and coming accessible devices. I’ve used every accessible screen reader out there. You can’t stay stuck on one platform because every few months something new comes out that changes the world of accessibility. Apple is always breaking it’s accessibility and E-mails flood in to Apple and they’re scrambling to fix it. I see countless posts saying how everyone is going to switch from Apple because they broke the App store. So over all if your not happy with something hang tight and it’ll get changed in general. Google takes time and I do have concerns that they aren’t fully behind there accessible technology. To anyone who’s trying to compare iPhones to androids, it’s not really about the devices, it’s about your comfort level with technology and how far your willing to go to have a phone that doesn’t limit your usage. Android at this point is for the more tech savvy users and yes part of that is because android accessibility isn’t up there with Apple yet. Of course that’s like saying a first world country has a full pay load of weapons while a third world country is still trying to design it’s weapons.
Chris says:
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, Kindle, NLS Bard Mobile and others
that depend on having an accessible web and/or text control. These useful and popular
programs do not exist 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.”
So Kindle doesn’t exist on Android? Another misrepresentation that needs correcting. It does indeed exist and is accessible.
sorry but your continued bashing of android is really starting to make me very angry. I am sick of all of you iOS lovers who go after google just because your definition of accessibility isn’t met. guess what, your accessibility doesn’t work for everyone, so stop shelving this shit down our throats.
Hi Brandon,
Thanks for such a terrific comment! I do wish that you would take the time to find a single fact in the article that isn’t true and then, with a tiny bit of intellectual clarity, something I’m sure you’re capable of, send corrections and, as I did with the two other corrections (one so minor as to be laughable) I’ll post them.
I do not understand your anger as you’ve done nothing more than tell me that you are angry and make the same ad hominem statement that I “love” iOS. I went to great lengths in this article to demonstrate that, when compared to all other major OS, not just iOS, that Android is sorely substandard. If you have any evidence to the contrary, please do show them to me and I’ll reassess my position on this matter.
Changing one’s view when new evidence is presented is hard and you seem to insist, without presenting any contrary data, that your opinion of Android is valid. Please, find problems that actually exist in my articles and people who read your comments might learn something from them. If you just accuse me of a “love” that doesn’t exist in my life, readers learn nothing new as that’s unsupported ad hominem.
Logical fallacies seem to dominate your opinion generation. You seem incapable of accepting facts and reject them only with personal attacks. This is unfortunate, I had assumed you were smarter than that. I suppose I over estimated you and assumed you might actually read the article, evaluate it on the facts presented and then make a judgement. Instead, you revert to your intellectually bankrupt tendency to just announce your anger. This is too bad, you could be a useful player in the accessibility discussion.
Hi Chris, I see your at it again, waving accessible guidelines when back when you were on the eyes free list you could not show those of us who asked for them. Kindle does allow you to change to word, paragraph Char and line. Keep in mind you had a nexus7 for 3 months. Then when back to IOS became an expert over people who have used the darn platform a lot longer then you. So lets clarify what accessibility really is fore everyday use. Not some text book rehashed crap you tend to spit out. One, can I text, make and receive phone calls, surf the web and gain access to the core apps of a phone. :) Yes a nexus5 does let you do all of that and more. On android accessibility and open source goes hand and hand when you have the ability to change your texting app so no core app can be totally labeled not accessible. What chris fells to see that while in sertain situations like dialog boxes, swiping is not the most efficient method to get around on a touch screen. :) More examples folow sense “his no it all in 3 months”, what if a button labeled back was at the bottom right hand of the screen. So your going to tell a use to swipe to it? Really!, wen you could inform him or her that perhaps its best they search the corners of the screen for a back, next or cancel button. We call this exploring on android and it gets a user used to the app there in. Its best a user explore around “dragging ones finger around” the screen to get a general lay out of the screen. Last, While I do agree that android’s keyboard support does need a prayer, then some more praying, then google to get off their butts and fix it. Unlike this article never points out, “file a bug on the eyes-free bug tracker”. I will shout this statement, on the nearest mountain until my last breath is left. Lastly, do not try to discredit me by saying my comments are not based off of fact, or I do not own a IPhone. Both of which are inaccurate. My final statement “do not attempt to discredit me with the idea I do not teach people so how do I relaly know how android is used in every day use.” Again it will be sorely false on any user who post such comment.
Hi Chris,
I just thought I’d add my $0.02 in here. First I will say that I’m not a programmer so I have no way of evaluating what you state about Android’s APIs. I can tell that you have talked to numerous programmers before posting though, and I commend your extensive research on the subject. The problem with the article I have is that you equate the presence of an accessibility API with the usability of the operating system for disabled people. You have mentioned the Gnome desktop several times and its robust accessibility APIs in this article. yet when I’ve tried to use it I’ve found it frustrating to say the least. Orca crashes, is slow to respond, or sometimes repeats certain regions of web pages over and over again. I guess it’s technically accessible from a programming standpoint, but from a user experience point of view it’s painful to say the least. I have played with every version of Gnome since the one included in Ubuntu 8.04, and though progress is being made, I find it hard to use for anything more than a hobby. Let’s not forget that the accessibility laws state that products must not only be accessible, but usable by customers with disabilities. I’m not saying Android meets either of these definitions now, but I’m not sure that approach of APIs for everything would automatically correlate to a better experience than what we already have. The last thing we need is a product that can check all the boxes for accessibility and be cumbersome to actually utilize.
While I’m posting here, I should also ask you a question. You state that windows is one of the best accessibility experiences for disabled customers. Isn’t this only true if one downloads a third-party program to take advantage of those APIs? If so, why praise windows when you have frowned on the necessity to install third-party applications on the android system to work around accessibility shortcomings? Shouldn’t windows receive a pass or fail grade in terms of accessibility based on narrator?
Thank you for reading this, and keep your excellent posts coming.
John
Hello,
the one thing I miss in this article is you talking to someone who succeeded in creating a gennerally accessible app for Android. The struggles such a person went through would have been a lot more informative than reading about the frustration of those who failed. In fact we still don’t know if those authors simply took the wrong approach or if it is really so hard to create an accessible app for Android. Because you only talke do, or at least quote from people who have failed in theyr attempts, this article is not much more than a classic case of Android-bashing, you only use a lot more words than most people do.
I’m a person who is a programmer, and a computer power user. I’ve been using screen readers since 1986 when I got my first ibm compatible pc xt machine, and I’ve gone through a lot of variations of operating systems, screen readers, and computers/devices.
A quick (and by no means exhaustive list) of my current computing devices is as follows:
Iphone 4s, Ipod 3gs, Android 7-inch tablet (one produced by asus and sold by walmart). Desktop running slackware, 2 desktops running ubuntu, 1 desktop running xp pro, 1 desktop running windows 7, 1 imac, 1 minimac, and multiple DIY systems based on materials from the arduino, parallax basic stamp, parallax propeller chip, and a few other parallax products such as the javalen chip, and the spin stamp.
I don’t state all of this to be a braggart, simply to give an idea of my interests, and abilities. It was with much anticipation I purchased my android tablet, because I really really wanted to learn to use the android os. After obtaining my shiny new 4.11 tablet (4.2 had just been released, so I figure that’s why the price on this 4.11 tablet was so reasonable) I went to work.
First thing I ran into was the android market (or lack thereof on this tablet) The talkback worked, but it could only run on a 30-day demo of available voices, and after my 30-day trial ran out, the tablet talked no more. Nor could I purchase said voices, as clicking on purchase links merely brought up 404 errors, no matter which voice I tried.
Ok, well, with some digging I finally figured out that the android store this tablet was using wasn’t actually the google play store, and although talkback was installed, it wasn’t the actual version from google. So I finally got help, installed a proper talkback, and managed to get some of the free voices installed. At this point, I thought I was set. I got talkback, I got a voice to use with it, and now I can really begin using this tablet. Well, not so much.
You see, talkback crashes frustratingly often, sometimes refusing to restart, and a reboot may or may not solve the issue. Often I need sighted assistance to get the tablet operational again. So, I figured well, let’s try regular apps, instead of these already installed on the tablet, perhaps these weren’t built for talkback. So, I tried a couple web browsers. Some work, some don’t, I tried music players, some work, some don’t. I tried book readers, (you guessed it), some worked, some didn’t. Not a problem, this is what I’d expect, depending on how they were written, you gotta expect some differences in accessibility. But, I have to say, I’ve had my tablet since August, and I’m still struggling with it, trying to learn how to use it effectively, what works, what doesn’t, gestures seem to be hit or miss, (most of the time, they work, but sometimes, no matter what I do, I just can’t get my tablet to do anything and a reboot is necessary). I’m not blaming google, (after all, this isn’t a google tablet) but I have to say, that the lack of progress with my android tablet is extremely frustrating. I can’t hardly do anything with it, and it’s been six months since I bought the thing. I was up and running on my very first dos machine in just a few weeks, on osx in a matter of hours, and even on windows (after being introduced to windows, jaws, and abap all at the same time) after only a few weeks. My first slackware linux machine took me a few days to get accustomed to, and ubuntu took only a few minutes (for the terminal part anyhow, I’m still not having any luck getting orca to talk on one of my ubuntu machines) OSX took a few days, aand the ipod/iphone took me less than an hour to become proficient in it’s use. All of these things point to the fact that if I as an excited new user, well versed in screen readers, and various computer systems can’t manage to ring some simblance of normal everyday use out of this tablet after 6 months, because it’s just too frustrating to fight with it for more than an hour or so at a time, then I can’t imagine how difficult this is for new users trying to use an android device with no idea of what they’re getting into. Now, admittedly, it does appear that phones are a lot more stable/advanced than android tablets seem to be, as I’ve seen many android phone users, pick up a phone, walk through the tutorial, and jump right in using their phones with little trouble. I on the other hand didn’t want a phone, I wanted a full-blown tablet, or heck, I’d enjoy an android pc if I could get it, but having made very little progress in using this tablet I have, either because of crashes, inaccessible content, or inability to find apps that do what I want, I’m extremely unhappy with my android experience up to this point. Trust me, I’d love to become an android expert, and use my android tablet all the time, but it’s just not happening. I think the whole ios gives a consistent experience regardless of device, vs. android’s wide variety of starting points is just not doing the trick.
I like the fact that android os is opensource. I like the fact that the screen reader is opensource. I like the fact that there are a wide range of android devices, and I love the fact that development on android devices doesn’t cost a thing for someone to get started. My problem though, is the fact that it’s just plain harder to get started on the android platform than it is for other solutions. Windows is not my friend, but it’s still easier to pick up and use than this android tablet I have, which honestly surprises the heck out of me. I honestly expected my android experience to be smooth, simple, and fun, but I’ve experienced anything but, and that my friends saddens me. Why is it I can build an fm radio, a speech assistive device for my wife, and construct an RFID system for reading my MTG cards, out of commercial parts using parallax products not intended for blind use, but I can’t master a simple talking tablet which is supposed to be blind friendly. I’m not a fan of google myself, and I’ve had serious difficulties joining google groups discussion lists (largely due to the fact that I refuse to get a google id for the express purpose of using google services when I already have perfectly usable email addresses of my own, and really don’t need or even want another one), and you can see why I’ve not participated in discussion groups about talkback, eyes-free, and other topics of interest on google groups. I simply can’t get signed up w/o a google id, despite my attempts to the contrary. If someone knows how, then by all means, let me know, because just like using this android tablet, I can’t figure it out.
Isn’t it just your tablet causing problems? My daughter got a tablet recently and it crashes all the time. With talkback it crashes quicker than without TB, however it crashes Always after some minutes of usage. Our Nexus 7, which is also a tablet doesn’t suffer from these problems. So if you start off with the wrong hardware, your experience will never be great. I guess this is just as true for windows and Linux. On my previous pc Orca wouldn’t talk to me. When I built a new one last month, Orca talked straight from the backup, I still don’t know why.
What I find frustrating is the idea that Android is for the more tech savvy and that somehow, those of us who choose the efficiency of iOS are somehow slower or require hand-holding. Back when Android was in its Froyo and Gingerbread phase blind Android users celebrated the fact they were living on the bleeding edge of technology. I went through a couple different options then and wondered just whose edge was really bleeding, because to say the experience was rudimentary would have been an exaggeration. The tech savvy embrace efficiency and hate being relegated to someone else’s afterthought, but somewhere along the way the blind were given wobbly training wheels and were satisfied just to be let into the cool kids’ party, even if it was only the foyer.
Fast forward to KitKat. The experience has dramatically improved, but in some ways it has grown more frustrating. Google is significantly more advanced than Apple can afford to be. Google could make the blind experience significantly better than Apple if it made it a priority. Yet, it chooses to continue ushering blind users through the feeder roads than give them a pass onto the main highway, and yet somehow, blind consumers are still satisfied to be a blip on the development roadmap. Whatever else blind Android fan boys might believe; we all really do want Android to blow iOS out of the water. Real competition is a great thing.
I’m tired of pointing out that iOS has its own set of challenges. First, if you are tech savvy, then you already knew that. Second, Android at its best still falls short of iOS at its weakest. It’s not even remotely like comparing JAWS and Window Eyes where the usability is generally the same despite different approaches. Part of the issue is app developer communication. Part of it is the device you buy from a specific manufacturer, though this latter is ironic considering the open nature Android is supposed to enjoy, but hear hear for the value of choice and the power of a custom ROM. Of course, the tech savvy would also know that jailbreaking on iOS is equally effective.
The most ardent argument Android fanatics can produce is that Android testers did not spend enough time with the platform. Putting aside the vicious cycle of insanity born of repetition, I think the point came when we had to make a choice between exploring the different ways we might achieve a task and actually completing it. I’ve since completed it and moved on. Kudos to Chris for valiantly attempting to drag the mule to water.
I also disagree heavily that Android is for the technically inclined. I studied software development at college (C++/Perl), and grew up with DOS back in the days before I lost my sight. Here are the reasons I favour iOS, though I don’t enforce them on others who may have different priorities
I looked for information on accessibility in Jelly Bean but found no real resources, the only information about how to activate the screen reader was in reference to ice cream sandwich and I seem to recall someone on a MUD mentioning the method had changed since then, but even so I refuse to join a mailing list just to learn the basic controls.
I consider my phone to be a critical device, I may need to call for a taxi or assistance in rare cases and being without that ability because of apps which were not quality controlled or because I had been messing with the code/settings on my phone is unacceptable to me. iOS is closer to idiotproof, I find this reassuring on something so important to me.
I also use my iPhone as a reading device. Not only does it have iBooks which was accessible before the iOS Kindle app was but also the aforementioned Kindle app is perfectly accessible plus both native Audible support and an Audible app. This gives me maximum flexibility.
If I wanted something to tinker with I’d keep it away from anything I rely on regularly by using an Android tablet, Raspberry Pi or Arduino. I can see why many people may not be comfortable with Apple’s closed ecosystem, I even have some concerns about arbitrary decisions on Apple’s part regarding app rejection, but these things aren’t enough for me to give up my iPhone as my primary mobile device. (In the interests of exposition I first used an iPhone 3GS as a replacement for a Symbion 60 phone with Talks, I’ve since replaced it with a 5S because it fills my needs the best, good access to textbook style ebooks is important for me in the form of RPG and wargames rulebooks)
Hi,
You said web content is the most difficult to make accessible.
Did you find an exemple of a mainstream web app that was successfully made accessible (using android accessibility framework and talkback as a screen reader) ?