Braille on Android
Over the last few months, I've been focusing a lot on Braille. Much of it is
because the Bluetooth earbuds I have, (Galaxy Buds Pro, Linkbuds S, Razer
Hammerheads), either have poor battery life or have audio lag that's just
annoying enough to make me not want to use them for regular screen reading. So,
grabbing a Focus 14, I began to use Braille a lot. I've now spend a good two
weeks using Android'TalkBack's new Braille support, and two weeks with
VoiceOver's Braille support.
In this article, I'll overview Android's passed support for Braille, and talk
about how its current support works. I'll also compare it to Apple's
implementation. Then, I'll discuss how things could be better on both systems.
Since there have probably been many posts on the other sites about iOS' Braille
support, I don't feel like I need to write much about that, but if people want
it, I can write a post from that angle as well.
BrailleBack and BRLTTY
When Google first got into making accessibility a priority of Android, back
around Android 2.3, it created a few stand-alone apps. Well, they were kind of
standalone. TalkBack, the screen reader, KickBack, the vibration feature for
accessibility focus events, and BrailleBack, for Braille support. There may have
been more, but we'll focus on BrailleBack here. BrailleBack connected to Braille
displays over Bluetooth, and used drivers to communicate with them. It started
out well for a first version, but wasn't updated much. In the years that
followed, the biggest update was to support a new, less expensive Braille
display. This has been Google's problem for a while now, having great ideas, but
not giving them the attention they need to thrive. Luckily, TalkBack is still
being worked on, and hasn't been killed by Google. At least now, Braille support
is built in. BrailleBack wasn't even installed on phones when it was being
developed, but TalkBack is. So, things may improve starting now.
BRLTTY started out as a Linux program. It connects to Braille displays using
USB, Serial, or Bluetooth, and supports a huge variety of displays. It tries to
give the Braille user as much control over the Linux console from the display as
possible, using as many buttons as a display has. It came to Android and offered
a better experience for some use cases, but the fact that you can't type in
contracted Braille, a sort of shorthand that is standardized into the Braille
system, may be off putting to some. Another issue is that it tries to bring the
Linux console reading experience to an Android phone, which takes a bit of
getting used to it.
So, here, we've got two competing apps. BRLTTY gets updated frequently, has many
more commands, but has a higher bar for entry. BrailleBack is stale, supports
few displays, but allows for writing in contracted Braille, and has more
standardized commands. So, you'd think Deaf-Blind users would have choices,
enough to use an Android phone, right?
App support matters
Let's take something that Braille excels at: reading. In Android, due to the
poor support of Braille from Google up to this point, and the fact that Braille
support wasn't installed, meaning that Deaf-Blind users couldn't easily set up
their phones without knowing about this separate app, and having sighted
assistance to install it, meant that third-party apps, like Kindle, and even
first-party apps, like Google Play Books, didn't take Braille into account
during development. The Kindle app, for example, just has the user double tap a
button, and the system text-to-speech engine begins reading the book. The Play
Books app does similar, with the option for the app to use the
high quality, online Google speech engine instead of the offline one.
This is how things are today, too. In Kindle, we can now read a page of text,
and swipe, on the screen, to turn the page. On Play Books, though, focus jumps
around too much to even read a page of text. It's easier to just put on
headphones and let the TTS read for you, so that Braille literacy, for Android
users, is too frustrating to cultivate.
So, if you want to read a book on your phone, using popular apps like Kindle, you have to use the system
text-to-speech engine. This means that Braille users are cut out from this
experience, the one thing Braille is really good at. There are a few apps, like
Speech Central, which do display the text in a scrolling web view, so that
Braille users can now read anything they can import into that app, but this is a
workaround that a third-party developer shouldn't have to make. This is
something that Google should have had working well about five years ago.
With the release of iOS 8, 8 years ago, Apple gave Braille users the ability to
“Turn Pages while Panning.” This feature allowed Braille users to read a book
without having to turn the page. Even before that, unlike Android even now,
Braille users could use a command on their Braille display to turn the page.
Eight years ago, they no longer had to even do that.
A year later, the Library of Congress released an app called BARD Mobile,
allowing blind users to access books available from the
service for the blind and print disabled on their phone. Along with audio books,
Braille books were available. Using a Braille display, readers could read
through a book, which was just a scrolling list of Braille lines, without
needing any kind of semblance of print pages. Android's version of BARD Mobile
got this feature about a year ago. And now, the new Braille support doesn't
support showing text in Computer Braille, which is required to show the
contracted Braille of the book correctly. I'd chalk this up to a tight schedule
from Google and not having been working on this for long. Perhaps version 14 of
TalkBack will include this feature, allowing Braille readers to read even
Braille books.
Now in Android... Braille
With the release of TalkBack 13, Braille support was finally included, finally.
Beforehand, though, we got a bit of a shock when we found out that HID Braille
wouldn't be supported. This, again, I can chalk up to the Braille support being
very new, and the Android team responsible for Bluetooth not knowing that that's
something they'll need to get implemented. Still, it sowered what could have
It was a great announcement. Now, instead of supporting “all” displays, they
support... “most” displays. So much for Android users being able to use their
brand new NLS EReader, right? Technically, they can use it through BRLTTY, but
only if it's plugged into the USB C port. Yeah, very mobile.
The Braille support does, however, have a few things going for it. For one, it's
very stable. I found nothing that could slow it down. I typed as fast as I
could, but never found that the driver couldn't keep up with me. Compare that to
iOS, where even on a stable build, there are times where I have to coax the
translation engine into finishing translating what I've written. There's also
this nice feature where if you disconnect the display, speech automatically
come back on. Although, now that I think about it, that may only be useful for
hearing blind people, and Deaf-Blind people wouldn't even know until a sighted
person told them that they now know all about that chat with the neighbor about
the birthday party they were planning, and that it's no longer a surprise. Ah
Well, so much for the customizability of Android. In contrast, when speech is
muted on iOS, it stays muted.
iOS doesn't sit still
In the years after iOS 8's release, Braille support has continued to improve.
Braille users can now read Emoji, for better or worse, have their display
automatically scroll forward for easier reading, and customize commands on most
displays. New displays are now supported, and iOS has been future-proofed by
supporting multi-line or tactile graphics displays.
iOS now also mostly supports displays that use the Braille HID standard,
and work continues to be done on finishing that support. This is pretty big
because the National Library service for the Blind in the US, the same that
offers the BARD service, is teaming up with Humanware to provide an EReader,
which while allowing one to download and read books from BARD, Bookshare, and
the NFB Newsline, also allows one to connect it to their phone or PC, to be used
as a Braille display. This means, effectively, that whoever wants Braille, can
get Braille. The program is still in its pilot phase, but will be launched
sooner or later. And Apple will be ready.
No, Android doesn't support these new displays that use the Braille HID
standard. It also doesn't support multi-line or graphics displays, nor does it
support showing math equations in the special Nemeth Braille code, nor does it
support automatically scrolling the display, changing Braille commands, and so
on. You may then say “Well, this is just version one of a new Braille support.
They've not had time to make all that.” A part of that is true. It is version
one of their new Braille subsystems of TalkBack. But they've had the same amount
of time to build out both Braille support, and TalkBack as a whole, that Apple
has. In fact, they've had the same eight years since iOS 8 to both learn from
using Apple's accessibility tools, and to implement them themselves.
So, let's say that Google has begun seriously working on TalkBack for the last 3
years, since new management has taken the wheel and, thankfully, steered it
well. Google now may have to take at least 4 years to catch up to where Apple is
now. Apple, however, isn't sitting still. They've put AI into their screen
reader years before the AI-first company, Google, did. How much longer will it
take Google to add things like auto-scroll to their screen reader to serve an
even smaller subset of their small data pool of blind users?
Neither system is perfect
While Apple's Braille support is fantastic, is is only rather rusty with age,
both systems could be using Braille a bit better to really show off why Braille
is better than just having a voice read everything to you. One example that I
keep coming back to its formatting. For example, a Braille user won't be able to
tell what type of formatting I'm using here on either system, even though there
are formatting symbols for what I just used in Braille. And no, status cells
don't count, they can't tell a reader what part of a line was formatted, and
the “format markers” used in Humanware displays are a lazy way of getting
around... I don't even know what. If BrailleBlaster, using LibLouis and its
supporting libraries and such, can show formatting just fine, I don't see why
screen readers in expensive phones can't.
Both systems could really take a page out of the early Braille NoteTakers. The
BrailleNote Apex not only showed formatting, but showed things like links by
enclosing them in Braille symbols, meaning that not only could a user tell where
the link started and ended, just line sighted people, they could do so in a way
that needed no abbreviated word based on speech. BRLTTY on Android shows switches
and checkboxes in a similar way, using Braille to build a nonvisual, tactile
interface that uses Braille pictograms, for lack of a better term, to make
screen reading a more delightful, interesting experience, while also shortening
the Braille needed to comprehend what the interface item is. This kind of stuff
isn't done by anyone besides people who really understand Braille, read Braille,
and want Braille to be as efficient, but enjoyable, as possible.
Another thing both companies should be doing is testing Braille rigorously.
There is no reason why Braille users shouldn't be able to read a book, from
start to end, using Google Play Books. There's also no reason why notifications
should continue to appear on the display when they were just cleared. Of course,
one issue is much more important than the other, but small issues do add up, and
if not fixed, can drag down the experience. I really hope that, in the future,
companies can show as much appreciation for Braille as they do for visuals,
audio, haptics, and even screen readers.
Until then, I'll probably use iOS for Braille, image descriptions, and an
overall smoothe experience, and use Android for its raw power, and honestly
better TTS engine, well if you have Samsung that is. With the ability to
customize Braille commands, iOS has given me an almost computer-like experience
when browsing the web. Android has some of that, but not the ability to
customize it.
Conclusion
I hope you all have enjoyed this article, and learned something from my diving
into the Braille side of both systems. If so, be sure to share it with your
friends or coworkers, and remember that speech isn't the only output modality
that blind, and especially Deaf-Blind, people use. As Apple says on their
accessibility site, Braille is required for Deaf-Blind users. Thank you all for
reading.
You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!