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!
