[vip_students] Testing Android Accessibility, a review!
- From: "[NCBI] Support" <support@xxxxxxx>
- To: <vip_students@xxxxxxxxxxxxx>
- Date: Fri, 10 Jan 2014 16:08:20 -0000
Testing Android Accessibility: I Give Up
By Chris Hofstader
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 today 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.
Introduction
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.
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.
Conclusions
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 failure.
,
* 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.
*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:
General Issues
Human Factors
*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.
Gestures
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
Why do all 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 whim and not science.
Navigation
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.
Basics
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
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
Setup
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.
Home Screen
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.
Apps
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:
Chrome
*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.
Currents
*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.
Play Books
*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.
YouTube
*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.
Calculator
*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.
Afterward
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.
This entry was posted in Technology Review and tagged Accessibility,
Accessibility API, Android, failure, iOS, Nexus/7, NVDA, TalkBack, Windows
on January 9, 2014 by chris.admin.
Post navigation
← Fighting Plate Tectonics
3 thoughts on “Testing Android Accessibility: I Give Up”
Yadiel
January 9, 2014 at 11:58 am
Sadly, this is almost the same experience I had. Even though it is usable,
and android has some great points in favor. Accessibility wise is to buggy
and incomplete.
Reply ↓
serrebi
January 9, 2014 at 1:07 pm
Totally agree with your findings. You should go find the homesample apk
http://frankkie.nl/android/
Displays all apps on one page, with small touch points only blindy’s can
deal with ahhaa. I believe in the future of android. I think sometime soon
some blind people will see it as an option. I just hope they add better
navigation for websites e.g. granularity control for moving around on
webpages before then… Firefox is a temp solution for me. I hate having to
do three finger gestures before the web UI is displayed to me. Also sharing
an android device with a sited person is kind of a joke right now. Just try
it and see. Sometimes you won’t be able to switch because talkback will
toggle for no reason, even though you’ve turned it on in the other profile.
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Follow us on Facebook:
https://www.facebook.com/ncbiworkingforpeoplewithsightloss
Follow us on Twitter: www.twitter.com/ncbi_sightloss
Check-out NCBI's Mícheál Ó Muircheartaigh appeal on the following link.
http://youtu.be/25P2tiuCi0U
NCBI Group - CRO No 26293 CHY 20902
NCBI Services - CRO No 527862 CHY 4626
NCBI Retail - CRO No 527863 CHY 20619
NCBI Charitable Foundation - CRO No 527864 CHY 12673
********************************************************************
Information in this email (including attachments) is confidential. It is
intended for receipt and consideration only by the intended recipient. If you
are not an addressee or intended recipient, any use, dissemination,
distribution, disclosure, publication or copying of information contained in
this email is strictly prohibited. Opinions expressed in this email may be
personal to the author and are not necessarily the opinions of NCBI.
If this email has been received by you in error we would be grateful if you
could immediately notify the IT Service Desk by telephone at +353 1 8821911 or
by email to service.desk@xxxxxxx and thereafter delete this e-mail from your
system
********************************************************************
===========================================================
The vip_students mailing list
Manage account or unsubscribe: //www.freelists.org/list/vip_students
Archives: //www.freelists.org/archives/vip_students
Administrative contact: support@xxxxxxx
===========================================================
Other related posts:
- » [vip_students] Testing Android Accessibility, a review! - [NCBI] Support
