I know I really shouldn’t write this, but at this point it doesn’t matter. I’ve ran away from those who will most likely look upon this with disdain, as if I don’t look upon myself with even more than those on the outside can. I was reading a post from someone who mentioned “the right kind of disabled.” That struck something in me that I’d been looking for for a long time. I thought I was the only one. Maybe I am. But it needs telling anyway, so why not.

Acceptable disability

You know those blind people who can get around an area they’ve barely been to, or cook on a stove, or even communicate well with body language and such? I’m sure many in the blind community know of, or are one of these. These blind people don’t need much. They don’t ask for help, they know their way around, and workplaces are proud to have the acceptable kind of person with disabilities, because they barely notice that the person is blind.

And that’s the key, isn’t it? The person that can hide their disability so well that no one really stops to think about it.

The wrong kind of blind

Yep, it’s one of those blog posts. If you want something more cheerful and full of Christmas bullshit, there are lots of Amazon sales going on I’m sure. So, I’ve been blind since birth. You’d think I’d be adjusted to it and know how to do every little thing. You’d think I’d be one of those web accessibility experts by now, talking about Alt text and ripping web devs a new one because they used a div instead of semantic HTML. But nope. I’m the other kind of blind person. The kind the media doesn’t want to talk about. The kind organizations are ashamed of. The kind they had to put into a corner and hope he doesn’t rock the boat.

Nope. Instead of web accessibility, I’m all into OS and app accessibility. Instead of bravely taking on my problems, I run from them. All the way away from them. Yes, that’s why I left Mastodon. No, I didn’t kill myself; I’m far too cowardly for that. I’m the weird one that’s all into text formatting, Markdown, and understanding things like that which almost no other blind person cares about. I’ve tried Seeing with Sound. I use AI. I feel passionate about free open source software, even though I keep those feelings locked up tight so I’m not too disappointed in it.

While just about all blind people I know love parties, loud noises are sometimes physically painful. If I hear a pot clang, or a door slam, it’s like a stinging feeling in my arms or shoulders. So I stay home and chill. I joke to the people around me that I’m the most chill person they’ll meet. But it’s sadly not a joke. Everyone else wants to go somewhere, or do something, or get out of the house. My house is my vacation.

So what?

Being the way I am comes with a ton of downsides. I’m not as quick or persevering as the acceptable blind person. I was once in a meeting to help make an operating system more accessible, in which we needed to open a document and work on it. It was using a web app that the organizers said would be accessible. I had issues with it, and so I spent the five minutes we had, trying to find accessibility documentation for the web editor. There was none. And then when I asked about it everyone was all quiet like it was an intrusion and I shouldn’t be there and why was I even trying. And then the people seemed to shrug their shoulders and go on with the meeting. I can never forget that.

Side note: If any corporation, company, or organization says they take accessibility seriously, or that they put accessibility front and center, they’re most likely lying to you, and mocking you cause who dares tell someone they’re not doing enough in “the good fight?” Lol, Microsoft. We know you. Windows 11 speaks for itself.

And now, at this point, I’d give tips on how you, yes, you, can help the unaccepted blind. But I won’t, mainly because it’s all over every other blog post about dealing with neuro-divergent people. Listen, then act. Of course, the listening part is really, really important. But then acting is what’s actually going to make the person trust that you actually give even a single damn. Lots of companies, organizations, and nonprofits are great at listening. They have issue trackers, support lines, ticket systems, help desks, and open-door policies. But then when it comes to acting, well… We need more people to make us do it, we need more feedback, maybe next year, this should be sent to IT instead because I can’t actually help you, RIM is too expensive; see if you can make a deal or cut down the price for us, we’ll make a committee for this as a part of DEI even though they have lots of other stuff and none of these people are blind so yeah good luck haha, well we should do it but it’s hard, we don’t want to do it because other software should do it for us. Just kinda try not to lean on these excuses, and you’ll be good. And if all you’ve got left is “We can’t help with accessibility,” then just tell us. Tell us you don’t care enough, or can’t do it, or have tons of other priorities, so we can go somewhere else.

I’m sure all this has been said many times before, but all I’ve been able to find so far is this article on Alt-Text which isn’t what I’m going for here. As a side note , I get that most members of society can only improve accessibility by adding Alt-text to the visual media they create, but isn’t it time we move a bit passed just image descriptions? Guides for Alt-text are everywhere. I am not about to make yet another. This will, however, be a longer article than the usual, and I wouldn’t blame you for coming up for air during this one.

In this article, I’ll talk about accessibility, for blind people, not just in regards to the screen reader, which also gets talked about, but also the operating system, and the activity the blind person is trying to do. In writing this article, I hope to zoom out a bit and show developers and others interested, that accessibility encompasses everything about the device, operating system, accessibility stack, screen reader, app, and person using the device. There is no solitary part of that stack.

How to introduce a screen reader

I know this is going to be an edge case. But honestly, people in the accessibility space should be used to edge cases by now, and this happens much more than you’d think. We have our blind person here: a person who, up to now, has been fully sighted, but lost her sight instantly due to an accident. No, I’m not going into details because there are tons of ways a person can lose their vision. No, this isn’t a real person, and I’m not, in any way, saying that this is how instant sight loss occurs or effects people, but I know that if I lost my sight this way, this is probably what would happen. And I know I’m not the only one that struggles with depression and anxiety.

So this person, let’s name her Anna, is trying to get used to having an entire sense, just gone. Maybe she’s in pain, or maybe her mind is numb in trying to process everything. Or maybe she’s about to give up and find a sharp knife in which to end it all, searching and searching in the now permanent dark. But she remembers learning about Hellen Keller in school. Thinking back though, she didn’t remember covering any more than her childhood. Anna wants to find a book on the rest of Keller’s life, so stores that in the back of her mind, with a note to figure out how to get an audiobook.

Now, you may be considering this amount of personal story to be a bit much, or over the top, or inappropriate for an informational post. This honestly makes blind people into nothing more than a test subject to be observed, and understood on a sort of acquaintance basis. I, for one, am tired of that. I, and every other blind person, am a living, thinking, feeling person. Notice that I didn’t say “blind user” above? No. A user is some case number or hypothetical list of assumptions to be grabbed, accounted for, and discarded at the end. But a person, well, they’re alive. They deal with their everyday trials and triumphs. They breathe and speak and change and grow and learn. A person is a bit less easy to discard, or to mock as “just another ‘luser’”. And yes, I’ve had to learn this too, over my years of teaching blind people

Now, Anna got some help with her mental health, and she’s trying to learn to deal with being blind. She’s learned to feel for the light switch, to see if a light is on or not, since she can’t see them. She’s learned that she needs to keep everything in order, so that she can find things much easier. She’s even started making her own sandwiches, ham and cheese and some mayo, and pouring some cereal, even though she makes a bit of a mess with the milk. She now keeps a towel on the counter, for that reason.

But today, she’s gonna do something that she thinks would be impossible. She feels around on her nightstand for the slab of glass. Her iPhone. She hasn’t touched it since she went blind a week ago. Or has it been a few weeks? A month? She takes a deep breath, and lets it out. She breathes for a moment, then starts to examine the device. A flat screen with two horizontal lines for the earpiece. Buttons on both sides. A flat piece of glass with the camera on the back. You get the idea.

She then decides to try using Siri. Siri wasn’t especially useful to her before, but it’s all she has now. She tries some simple requests, like asking for the time, or the weather. She then decides to be a little more brave. Taking a deep breath, she asks “How can a blind person use an iPhone?” Siri responds, “Here’s what I found on the web. Check it out!”

Anna waits a moment, remembering what this screen looks like. She waits, thinking that maybe Siri would be so kind as to read it out to her. Siri, it turns out, is not so kind. Her room is silent. Tears to not make a sound as they fall.

She sits there for a moment, trying to pull herself together. Trying to gather up the pieces that had just went flying everywhere. She breathes in, and breathes out. She grips the phone in her hands, and tries the last thing she can think of. Because if this doesn’t work, then this expensive phone is nothing but expense to her. She tells Siri to call her mother. “Okay, calling Mom.” Her heart stops to listen. Her mind strains to hear. And the phone finally rings. And, after a moment, she hears her mother’s voice.

Now, this is without any kind of outside agency helping her, and I shudder to think of how many blind people go through this. They use Siri to text and call, read their texts and notifications, create a note and read it out, and set alarms. But apps, well, Youtube and books and anything besides texting, those are lost to them. Yes, having the ability to make a call or send a text is really important. And in this case, it’s probably what made the difference between barely surviving to possibly thriving. Because I’ve known people who come in with their iPhone and only know Siri. And maybe they’ve tried to use VoiceOver. But here’s where that falls apart.

Anna waited for the doctor to hang up the phone. She hated this part. The doctor hung up, but the automated system on which the call happened, well it takes a minute. Finally, she heard the static and click. She’d been noticing more of that kind of thing. How the tone of the milk changed as she filled a cup, or the way her foot falls echoed when she was near a door. She’d kind of started making sounds, clapping her hands or stepping a bit louder, just to experiment with the sounds. Not too much though. She never knew if someone was looking in through the window at that weird blind girl clapping at nothing or stomping her feet.

Anna smiles at the memories, but reminds herself that she’s got a thing to try. Through some miracle, her mom had found an app on the iPhone, called VoiceOver. It was supposed to read out what is on the screen to you, and guide you through tasks on it. So, she told Siri to “Turn on VoiceOver.”

Immediately, VoiceOver turned on. She heard a voice say “VoiceOver on.” And then it read the first app on the Home Screen. She was impressed, but wasn’t sure what to do next. The voice then said “double tap to open.” She tapped the screen twice. It read another app on the screen… Twice.

She continued playing with it, but couldn’t make much sense of it. She could feel around the screen, but then what? When she tapped on an item to open it, it just read that item. She tapped twice like it said, but it just read the item again. In frustration, after hearing “double tap to open” for the hundredth time, she quickly jabbed at the phone. Miraculously, the app opened. She had been touching the weather app. She felt around the screen, hearing about, well, the weather. Exasperated, she put the phone down and took a nap. She deserved it.

And here we have the meat of the issue. Yes, I tried that question to Siri, about how a blind person would use an iPhone, and she gave that “here’s what I found on the web” answer. This is even on iOS 17 beta, where Siri is supposed to be able to read webpages. But Siri can’t even ask the person if Siri should read the page or not. Because that’s just too hard.

Siri could have easily been programmed to tell the person about VoiceOver, and at least give tips on how to use it. But no. If there’s a screen, people inherently can view the screen, and a digital talking assistant shouldn’t get in the sighted person’s way. Right?

So, let’s look at accessibility here, in the context of a voice assistant. The voice assistant should never, ever assume that a person can see the screen. Like, ever. If it’s pulled up a long article, the assistant should offer to read the article. It doesn’t matter if a screen reader is on or not. As you read above, Anna didn’t even know the concept of a screen reader, let alone that one is on the iPhone.

Mobile phones have an amazing accessibility potential specifically because of the voice assistant. This voice assistant is in popular culture already, so a newly blind person can at lease use Siri, or Google Assistant, or even Bixby.

So, an assistant should be able to help a blind person get started with their phone. The digital assistant can lead a blind person to a screen reader, or even read its documentation like a book. If Amazon’s Alexa can read books, then Apple’s Siri can handle reading some VoiceOver documentation.

Moving forward, Anna had no idea how to use VoiceOver. Performing a double tap is incredibly difficult if you don’t have another person there who already knows, and can show you. You may think that it’s just tapping twice on the screen, but you have to do it very quickly compared to a normal tap. A little too slow, and it just thinks you’re trying to tap twice. And even when that’s done, the person has to learn how to swipe around apps, type on the keyboard, answer and end calls, and where the VoiceOver settings are to turn off the hints that are now getting in her way and making her lose focus on what she’s trying to do.

It’s been more than a decade since VoiceOver was shipped. It’s seriously time for a tutorial. And yes, while I know that there are training centers for the blind across the US, I’m pretty sure there are plenty of blind people that never even hear about these centers, or are too embarrassed to go there, or can’t go due to health reasons.

The screen reader, VoiceOver, in this case, was even less helpful than the voice assistant. Imagine that. A voice assistant helped Anna make a phone call. VoiceOver, due to the lack of any kind of usage information, just got in her way. That’s really sad, and it’s something I see a lot. People just turn back to Siri because it’s easier, and it works.

The idea that blind people just “figure it out” is nothing but the shirking of responsibility. Training centers should not have to cover the basics of a screen reader. But we do, and it takes anywhere from two weeks to a month or more of practice, keeping the student from slipping back into the sweet tones of Siri that can barely help them, and showing them all of what VoiceOver can do, which Apple just can’t manage to tell the person. Because it’s so much easier to show off a new feature than to build up the foundations just a tad bit more.

Context matters. Yes, an advanced user won’t need to know all of VoiceOver’s features and how to do things on the phone. But someone who has just gone blind, or someone’s first iPhone, they need this. I don’t care if it’s Siri introducing the screen reader after the person asks how a blind person can use a phone, or if VoiceOver asks the user if they’d like to use it after a good minute or two of being on the home or Lock Screen with no activity, or if a tutorial pops up the first time a blind person uses VoiceOver. But something has got to change, because there are newly blind people every year. It isn’t like we people who were born blind are dying off and no blind people are replacing us, so that VoiceOver looks like this temporary measure until 50 years from now when there are no more blind people left, and VoiceOver can be left to rot and die.

Disabilities, whether we like or not as a society, or even as a disability community, are going to be with us for a long time to come. You see how much money is poured into a big company’s accessibility team? Very little. That’s about how much money is also poured into medical fixes for disability. If it weren’t so, we’d all be seeing, and hearing, and walking, and being neurotypical, and so on, right now. They’ve had a good 40 years of modern medicine. They are not going to fix this in the next 40 years, either. Even if they do fix it for every disability, some people don’t want to typical. They find pride in their disability. That’s who they are.

How a screen reader and operating system work together

For the sake of my readers, the ones left at this point, and myself, I’m going to continue to use Anna for this section as well. Let’s say she has figured out the iPhone thanks to her mom reading articles to her, and now her time to upgrade her phone has arrived. But she’s not found a job yet, and an iPhone is way out of her current budget. Oh, did I tell you she was “gracefully let go” from her old job at Walmart? Yeah, there’s that too. Her bosses just knew that she couldn’t possibly read the labels on the goods she normally organized and put on the shelves, because they don’t have Braille on them.

Now, Anna is looking for a new phone. Her iPhone X is getting slow, and she’d finally paid off the phone with the help of her new SSDI bill, and her mom where needed. She doesn’t like to ask people to do things for her unless absolutely necessary.

So, she goes to a phone store and picks out the best Android phone she can find. It’s not a flagship phone by any means. It’s not even a flagship killer. It’s just a Samsung phone. She pays for it, down a good $250, and walks out with the phone.

Knowing how things generally are now, she holds down the power button, feels a nice little buzz (but not as nice as her iPhone could make), and asks her mom to read her some articles on how to use a Samsung with… whatever VoiceOver it has.

So to make a long story short, she turns on TalkBack, goes through the tutorial built right into the screen reader, and is instantly in love. She can operate the screen reader, without her mom even needing to read her the commands and how to do them. She hits the finish button on the tutorial, and is ready to go.

She first wants to make sure she’s running the latest version of everything. So, she opens the Galaxy Store, and feels around the screen. She finds a link of some kind, then a “don’t show again,” and a “close” button. Puzzled, she activates the close button. Now, she’s put into the actual store. She feels around the screen, finding tabs at the bottom. She’s not really sure what tabs are, but she’s seen them on some iPhone apps. She finds a “menu” tab, and activates that. Feeling around this new screen, she finds the updates item, and double taps on it. Nothing happens. She tries again, thinking she didn’t double tap hard enough, or fast enough, or slow enough. No matter what she tries, nothing happens.

Frustrated and confused, Anna swipes to the left once, and finds a blank area. She decides to double tap it, thinking maybe that’s just how some things work on Android, like how sometimes on a website, a text label is right before a box where the information for that label goes. And she’s right. The updates screen opens, and she’s given a list of updatable apps.

She then decides to look at the Play Store. She’s heard of that before, in ads on the TV and radio, where people are talking about downloading an app. She finds this app a bit easier to use, but also a lot more cluttered. She finds the search item easily, but cannot find the updates section. She decides to just give that a break for now.

She decides to call her mom on her new phone, and see how that works. So, she double taps and holds on the home button to bring up Google Assistant. She knows how to do this because I don’t feel like making up some way she can figure that out. Oh and let’s say her contacts were magically backed up to Google and were restored to her new phone.

TalkBack says “Google Assistant. Tap to dismiss assistant.” Startled, the command Anna was about to give is scattered across her mind. She finds and double taps on the back button. She tries again. The same thing happens. She’d never had that issue before. Trying to talk passed TalkBack, she talks over the voice saying “tap to dismiss assistant,” and says “call”… TalkBack then says “call”. TalkBack then says “double tap to finish.” Assistant then says “Here’s what I found.”

Anna is done for the day. She puts the phone away, and from then on, just uses Samsung’s assistant that I don’t remember how to spell right now. Maybe after a year or two of this, she goes back to an iPhone. Let’s hope she finds out about a training center and gets a job somewhere, and lives happily ever after. Or something.

Having a screen reader work with an operating system requires tons of collaboration. The screen reader team, and indeed, every accessibility team that deals with an operating system, should be in the midst of operating system teams. From user interface elements to how a user is supposed to do things like update apps, or talk to an assistant, these things should be as easy as possible for a person using a screen reader. You, as a developer far removed from the user, don’t know if the person interacting with your software has just lost their vision, or is having a particularly suicidal day, or anything else going on in their lives. It’s not that far of a stretch to say that your software may be the difference between a person giving up, or deciding that maybe being blind isn’t a life-ending event after all.

Let’s go through what happened here. TalkBack, in this case Samsung’s TalkBack that’s still running 13 even though 14 has been out for months now, does have a built-in tutorial. It’s been there for as long as I’ve used it. And that’s extremely commendable for the TalkBack team. Also, they keep updating it.

Now, let’s focus on the Galaxy Store for a moment. An ad wasn’t a big deal in this case. It didn’t jumble up and slow down the screen reader, like some other ads tend to do. It was just a simple link. But in a lot of cases, these ads aren’t readable as ads. They’re just odd things that show up, with buttons to not show the ad again, and to close the ad. It’d be kinda nice if the window read “ad” or something before the ad content.

Now, for the worst thing about the store. The download and update buttons are broken now, with no fix coming any time soon. Operating system developers, even if they’re developing from a base like Android, need accessibility teams including a blind person, Deaf person, and so on. And those disabled people need to have enough power to stop an update that breaks a part of the experience, especially one as important as updating apps.

A screen reader can only read what an app tells it to read, unless there’s AI involved. And for me, there was. When TalkBack landed on that unlabeled item, it said something like “downloads” so I knew to click on that instead of the item label that’s just sitting there outside the actual item. A screen reader is only part of a wider system. A app has to be labeled correctly. An operating system has to be able to tell the screen reader about the item label. And the person has to know how to use the screen reader, and operating system, and app.

And finally, the Google Assistant. Context matters a lot here. What is the user trying to do? Talk to a digital assistant. Would you like it if the person you are talking to suddenly talks over you, and then begins repeating the things you’re saying? No? I thought not. In these kinds of contexts, a screen reader should be silent. The digital assistant, if needed, should be reading any options that appear, like choices for a restaurant or phone number. There should be no doubt here. There are times when a screen reader should be silent, and this is one of the most important. If you are wondering about this, ask a blind person. We do exist, and we’ve had enough of these stupid issues that could be resolved if we are just asked.

Conclusion

Alt-text is just the tip of the iceberg of accessibility. After all, if a person isn’t told how to use the screen reader, what good is Alt-text if they can’t even get to the site to read it? A screen reader is not enough. An app has to be built to be accessible and easy to use, or a person won’t know where to go to do the thing they want. An operating system has to have a good enough accessibility framework to allow a screen reader to, say, turn off its own touch interaction methods to allow a person to play a video game, or play a piano. All of these pieces create the accessibility experience that a person has. And this isn’t even getting into Braille and tactile interfaces.

I hope this post has shown some of what we as blind people experience. After a decade of development, you’d think some of these things, issues, and capability for issues, would be resolved a long time ago. But developers still don’t understand that they’re not developing alone, and that it takes constant cooperation to make things not just accessible as in every button is labeled, but great as in the user is confident in how to use their screen reader, the app they’re in, and the operating system as a whole. Until then, these problems will not be resolved. A company-wide, cultural mindset does not fix itself. Blind people are so used to this that very few even know that they can contact Apple or Google developers, and fewer still think it’ll do any good. They see developers as ultra-smart people in some castle somewhere, way out of mind of the people they develop for, and there’s a reason for that. Developers are going to have to speak with the people that rely on what they build. And not just the people that will tell the developers what they want to hear, either. Developers need to be humble, and never, ever think that what they’re building is anywhere close to good enough, because once they do, they start to dismiss accounts of things not working right, or a need for something better, or different, or more choices. Until these things happen, until people can trust developers to actually be on their side, these kinds of stories will continue, unnoticed and undiscussed.

I’ve talked a lot about Android on this blog. I love the idea, and the operating system is nice, but accessibility could be so much more. I’ve had my Galaxy S20 FE (5G), for about a year and a half or so. I’ve seen the changes from Android 11, to 12, and finally to 13. TalkBack has improved steadily over that year and a half, adding Braille support, which I thought wouldn’t come for another five to ten years. Spell checking was added in TalkBack 13. Text recognition in images and unlabeled buttons was added in TalkBack 12.1. Icon descriptions were added in TalkBack 13.

In this article, though, I’ll overview the changes in TalkBack 14, the ones I have access to, that is. I’ll get to that later. I’ll also talk about the problems facing Android that isn’t really about TalkBack, but is more about the accessibility framework, and what apps can and can’t do. So this will be a sort of continuation from my other Android articles, more than just a “what’s new in TalkBack” style article.

TalkBack 14, Lots of Braille

TalkBack 14 is a good iteration of where TalkBack 13 started. TalkBack now has many more commands, both for Braille displays and for its Braille keyboard. One can now move around an edit field by words and lines, not just characters, using the onscreen Braille keyboard. One can also select text, and copy and paste it using the same keyboard. You don’t have to dismiss the keyboard just to do all that. To be fair to iOS, you can do that with Braille Screen Input, but the commands are not documented in either Apple’s documentation, or in the VoiceOver settings. In TalkBack settings, those commands are clearly documented and explained.

TalkBack 14 now supports the NLS EReader, which is being freely distributed to NLS patrons. By the end of the year, all 50 states will have the EReader. You do have to connect the display to your phone via USB C, and the cable I had on hand shorted out, so I have to find another one. But I was able to use it with a USB hub, which further made the setup less mobile, but it did work. The commands, though, were rather more complicated than I expected. I had to press Enter with dots 4-5 to move to the next object. Space with Dot 4 was used to move to the next line, and Space with Dot 1 was used to move to the previous line. So I quickly moved back to using the EReader with the iPhone. I’ll practice with it more, but for now it just doesn’t feel as practical as using the EReader, over Bluetooth, on the iPhone, with its simpler commands.

A window into Images

TalkBack 14 has a new screen of choices, where you can enable options regarding image recognition. You have the usual text recognition, and icon recognition, but the screen refers also to “image recognition,” similar to what VoiceOver can do. This is something I’ve wanted for a long time. Some people have a third option, “image descriptions,” but I don’t have that option. Google often rolls out features to a small subset of users, and then rolls it out to everyone else after weeks or months of testing. We’ll have to see how that works out.

Of note, though, is that whenever one gets an iOS update, one gets all the new features right away. There is no rollout of features for VoiceOver, it’s just there. TalkBack 14, as a public release, should have all the features available to everyone at launch, in my oppinion. They could always label image descriptions as “beta.”

The Accessibility Framework

As I’ve said before, the operating system is the root of all accessibility. If the accessibility framework is limited, then apps are limited in what they can do as far as accessibility is concerned. This is why I’ve been so critical of Google, because Android’s accessibility framework, and what apps can communicate to TalkBack, is limited. I’ll give a few examples.

Kindle

I love the books I can get on Kindle. I love that I can read them on just about all of my devices. But not all Kindle apps are created equally. The app on the iPhone is great. Using VoiceOver, I just swipe down with two fingers and the book is read to me. I can move my finger up and down the screen to read by line. I can use a Braille display and just scroll through the book, no turning pages required since it happens automatically. On Android, however, the Kindle app is more limited.

When you open a book in Kindle for Android, you find a page, with a “start continuous reading” button. All this button does is pipe the text of the book out to the Android speech engine. This distinction is important. On iOS, since VoiceOver is controlling things, you can quickly speed up, slow down, pause and resume, or change the voice quickly. On iOS, you can read by word or letter, and most importantly, read easily with a Braille display.

On Android, you can move your finger down the page to hear lines of text, which are sent to TalkBack as announcements. But if you try to have TalkBack read the book, it won’t get passed the current page. The same is even more true with Braille; you have to turn pages manually, using the touch screen because its not actually TalkBack that’s turning the page. So you have to keep touching the phone’s touch screen in order to continue interacting with the app. Braille displays have keys for a reason. You shouldn’t have to use the touch screen to do anything while using a Braille display with your phone. Most Braille display users keep their phone in their pocket while they use it from their displays.

With a lot of other book-reading apps, you can just lock the screen, and just listen to the book. Many blind Android users love that, and find it superior to reading with a screen reader. However, the Kindle app doesn’t even satisfy that. Whenever the screen times out and locks, after that page is finished, the page is turned, but the speech stops. You have to unlock the screen, and then press “start continuous reading” again.

Now, if TalkBack could read the book, and turn the page, the experience would be much better. But Google’s accessibility framework has moved at a glacial pace, throughout the ten or fifteen years of Android, and iOS, development. While Apple opened up API’s to developers, so that VoiceOver could turn pages while reading, Google has not even added that feature to their own reading app. Instead, Play Books uses a web view, and just detects when the user has gone beyond the last element on the page, and then just turns the page. At least, that’s what I think is happening. I obviously don’t have access to the source code of the Play Books app.

Mortal Kombat

Games are becoming more and more important in the mobile ecosystem. Mobile games are, in some cases, more popular than console games. But mobile games are sometimes very hard to make accessible. Take the Mortal Kombat game. You have an interface where you choose a game mode, make a team of fighters, upgrade cards, and change settings. Then, you have the fight mode, where you tap to attack, swipe for a special attack, and hold two fingers on the screen to block. On iOS, the developers have made the buttons visible to VoiceOver, and added labels to them. They’ve shown the text elements, where you “tap to continue”, to VoiceOver, and allowed the double tap to advance to the next screen. That part, I believe, could be done on Android as well.

The real fun is in the battles, though. Once a fight starts, on iOS, VoiceOver is pushed out of the way, so to speak, by a direct touch area. This allows taps and swipes to be sent directly to the app, so that I can play the game. While I’m fighting, though, the game sends text prompts to VoiceOver, like “swipe up,” or “Tap when line is in the middle.” I’m not sure exactly what the last one means, but “swipe up” is simple enough. This allows me to play, and win, battles.

Unfortunately for Android users, though, this “direct touch area” is not possible. Google has not added this feature for app developers to take advantage of. They theoretically could, but they’d then have to make an accessibility service for the app, and then make sure that the service is running when the app runs. Users are not going to turn on an accessibility service for a game, and developers are not going to spend time dealing with all that for the few blind people, relatively speaking, on Android.

Catching the Apple

Google, for the last few years, has been trying hard to catch up to Apple. They have a long way to go. Apple, however, hasn’t stayed still. They have a decade worth of built-up experience, code, frameworks, and blind people who, each time they try Android, find that it falls short and come back to iOS. I’m not saying Apple is perfect. And each time a wave of blind people try Android, a few find that it works for what they need a phone for.

As more and more blind people lean into using a phone as their primary computing device, or even their secondary computing device, accessibility is going to be more important than ever. We can’t afford half-baked solutions. We can’t afford stopgap measures. Companies who build their services on top of these platforms will do what they can to make their apps accessible, but they can only do so much. In order to make better apps, developers need rich, robust API’s and frameworks. And right now, that’s Apple. And I’ve gotten tired of holding my breath for Google. I’m just going to let out that breath and move on. I’ll probably keep my Android phone around, but I’m not going to use it as my primary device until Google gets their act together.

Some Android users will say that I’m being too harsh, that I’m not giving Google enough time, or that I’m being whiny, or radical, or militant. But it took Google ten or so years to add commands that used more than one finger. It took them ten years to add Braille support to their screen reader. It took them ten years to add spell checking. I’m not going to wait another ten years for them to catch up to where Apple was a good three years ago.

The debate over AI rages on, and I find myself caring less and less as the tug of war between the sides, one saying that AI is a threat to humanity and the other side saying that AI can do lots of amazing stuff, and definitely couldn’t take our jobs, becomes more fierce. No, AI cannot take our jobs. Rich people can take our jobs and give it to AI, though.

This post isn’t going to be about the rich people that bend AI, and anything else they can, to their will. This post is about why I use large language models, especially multimodal ones, and why I find them so useful. A lot of people without disabilities, particularly those who aren’t blind, probably won’t understand this. That’s okay. I’m writing this for myself, and for those who haven’t gotten to use this kind of technology yet.

Text only models

ChatGPT was the first large-language model I used. It introduced me to the idea, and to the issues of the model. It couldn’t give an accurate list of screen reader commands. But it could tell me a nice story about a kitten who drinks out of the sink. From the start, I wondered if I could feed the model images. I tried with Ascii art, but it wasn’t very good at describing that. I tried with Braille art, but it wasn’t good at that either. I even tried with an SVG, but it couldn’t fit the whole thing into the chat box.

I was disappointed, but I kept trying different tasks. It was able to explain output of some Linux commands, like Top, which doesn’t read well with a screen reader. It was even able to generate a little Python script that turned a CSV file into an HTML table.

As ChatGPT improved, I found more uses for it. I could ask it to generate a description of a video game character, or describe scenes from games or TV shows. But I still wanted it to describe images.

My Fascination with Images

I’ve always wanted to know what things look like. I’ve been blind since birth, so I’ve never seen anything. From video games to people to my surroundings, I’ve always wondered what things look like. I guess that’s a little strange in the blind community, but I’ve always been a little strange in any community.So many blind people don’t care what their computer interface looks like, or what animations are like, or even if there is formatting information in a document or book. I do. I love learning about what apps look like, or what a website looks like. I love reading with formatted Braille or speech, and learning about different animations used in operating systems and apps. I find plain screen reader speech, without sounds and such, to be boring.

So, when I heard about the Be My Eyes Virtual Volunteer program, I was excited. I could finally learn what things look like. I could finally learn what apps and operating systems look like. I could send it pictures of my surroundings, and get detailed descriptions of them. I could send it pictures of my computer screen, and understand what’s there and how it’s laid out. I could even send it pictures from Facebook or Twitter, and get more than a bland description of the most important parts of the image.

I began trying the app, with saved pictures and screenshots. The AI, GPT4’s multimodal model, gave excelent descriptions. I finally learned what my old cat looks like. I learned what app interfaces like discord look like. I sent it screenshots of video games from Dropbox, and learned what some video game characters and locations look like.

Now, it’s not always perfect. Sometimes it imagines details that aren’t there. Sometimes it doesn’t get the text right in an image. If a Large Language Model is a blurry picture of the web, I’d rather have that than a blank canvas. I’d rather see a little than not at all. And that’s what these models give me. No, it’s not real site. I wouldn’t want to wait a good 30 seconds to get a description of each frame of my life. But it’s something. And it’s something that I’ve never had before.

Feeding the Beast

A lot of people will say that these models just harvest our data. They do. A lot of people will then say that I shouldn’t be feeding their Twitter posts, video games, interfaces, comic books, and book covers into the models. My only response to that is that if all these things were accessible to me, I wouldn’t have to feed them to the models. So if you don’t want your pictures in OpenAI’s next batch of training data, add descriptions to them. If you don’t want your video game pictures used in the next GPT model, make your game accessible. If you don’t want your book covers used in the next GPT model, add a description to them. That’s just all there is to it. I’m not giving up this new ability to understand visual stuff.

Over the years, I’ve owned a few Android devices. From the Samsung Stratosphere to the Pixel 1 to the Braille Note Touch, and now the Galaxy S20 FE 5G. I remember the eyes-free Google group, where TalkBack developers were among us mere mortals. I remember being in the old TalkBack beta program. I remember when anyone in the Eyes-free group could be in the beta. And now, that is no longer the case.

In this post, I’ll talk about the Accessibility Trusted Testers program, how it works in practice, in my own experience, and how this isn’t helpful for both TalkBack as a screen reader, and Google’s image as a responsive, responsible, and open provider of accessibility technology. In this article, I will not name names, because I don’t think the state of things results from individual members of the TalkBack or accessibility team. And as I’ve said before, these are my experiences. Someone who is more connected or famous in the blind community will most certainly have better results.

The outer ring

When you open the link to join the accessibility trusted tester program, you’ll find this text:

Participate in early product development and user research studies from select countries.

After signing up, you’ll get an email welcoming you to the program. Afterwards, you get emails about surveys and sessions you can do. This isn’t just for blind people, either. There are a lot of sessions done for people with visually impaired people, Deaf people, and wheelchair users. And yes, there are a lot more of them than blind people. A good many of them require that you be near a Google office, so require transportation. I won’t go into detail about what the sessions and surveys are about, but this overview should give you a good enough idea.

The Inner Ring

Now we get into the stuff that I take issue with. There is no way for someone not in the loop to know. If you contact someone in the accessibility team at Google, you can ask to be placed in the TalkBack and/or Lookout testing programs. Depending on who you ask, you may or may not get any response at all. Afterwards, the process may get stuck in a few places, either in searching for you in the program, calling out to another person, and so on. And no, I’m not in either private beta program. The last time I’ve heard from them is two months ago now.

The things I have issues with are many, and I’ll go over them. First, when someone signs up for these trusted tester programs, they think that, because it’s a “tester” program, you’ll gain access to beta versions of TalkBack and so on. You don’t.

Second, some of these sessions require you to travel to Google’s offices. There are blind people scattered across states and countries and provinces, and few Google offices. So, if a blind person wants to attend a session, they’ll have to travel to California to do so. And that means that only Californian blind people, who are in the program, will even know about the study and attend.

And third, the biggest, is this. When the program opened up after the demolition of the eyes-free group, the people using Android for the longest flooded in. So, throughout all these years, it’s been them, the people used to use Android, providing the feedback. People who haven’t used iOS in years, people who don’t care about images and who have found their preferred apps and stick with that. So, when new people come to Android, the older users have a bunch of third-party apps, for email, messaging, launchers, and so on. Sure, the new users can talk about how the first-party experience is on the Blind Android Users mailing list and Telegram group, but the older users always have some third-party way of doing things, or a workaround of “use headphones” or “mute TalkBack” or “use another screen reader” or “Go back to the iPhone”. And I’ve nearly had enough of that. Sighted people don’t have to download a whole other mail client, or mute TalkBack while talking to Google Assistant, or use a third-party Braille driver like BRLTTY, or use and iPhone to read Kindle books well in Braille or talk to the voice assistant without being talked over.

Also, the Trusted Testers program only covers the US and maybe Canada. Most blind Android users are from many other countries. So, their voices are, for all intents and purposes, muted. All those devices that they use, the TalkBack beta program will not catch. A great example of this is spell checking released in TalkBack 13.1. On Pixels, when you choose a correction, that word is spelled out. On Samsung and other phones, it’s not. It makes me wonder what else I’m missing by using a non-Google phone. And that’s not how Android is supposed to work. If we, now, have to buy Google phones to get the best accessibility, how is that better than Apple, where we have to buy Pro iPhones to get the most and best features?

How this can be Fixed

Google has a method by which, in the Play Store, one can get the beta version of an app. Google can use this for TalkBack and Lookout. There is absolutely nothing stopping them from doing this. Google could also release source code for the latest TalkBack builds, including beta and alpha builds, and just have users build at their own risk. Google could open the beta programs to everyone who wants to leave feedback and help. After all, it’s not just Google phones that people use. And the majority of blind people don’t use Pixel phones. blind people also have spaces for talking about Android accessibility, primarily the Blind Android users list and Telegram group. I’d love to see Google employees hanging out there, from the TalkBack team to the Assistant team, the Bard team, and the Gmail and YouTube teams. Then we could all collaborate together on things like using TalkBack actions in YouTube, moving throughout a thread of messages in Gmail, and having TalkBack not speak over someone talking to the assistant, with or without headphones in.

How can I help

If you’re working at Google, talk to people about this. Talk to your team, your manager, and so on. If you know people working at Google, talk to them. Ask them why all this is. Ask them to open up a little, for the benefit of users and their products, especially accessibility tools. If you’re an Android user, talk to the accessibility folks about it. If you’re at a convention where they are, ask them about this. If you’re not, they’ve listed their email addresses. I want anyone who wants to be able to make Android accessibility, and TalkBack, the best that it can be, to be able to use the latest software, use beta software, provide feedback directly to the people making it. Google doesn’t need to be another Apple. Even Apple provides beta access, through iOS betas, to any eligible iPhone. Since Samsung barely does any TalkBack updates until half a year or more later, it’s seriously up to Google to move this forward. I’ve known people who plug their phone into a docking station, and use it as a computer. I want blind people to be able to do that.

In order to move this forward, though, we need to push for it. We need to let Google know that a few people who have been using Android for the past 10 years isn’t enough. We need to let them know that there are more countries than the United States and Canada. We need to let them know that we want to work with them, to collaborate with them, not for them to tell us what we want through a loud minority.

TalkBack doesn’t have as many options and features as Voiceover, but it’s started out on solid ground. ChromeVox doesn’t have as many options and features as JAWS but has started out on a solid foundation. Together, though, the community and Google can make both of these platforms, with the openness of Android, on both phones and ChromeBooks, and Linux containers on chromeBooks, the best platforms they can be! All it takes is communication!

So this is in response to This blog post regarding Mr. Beast’s Blindness video, which shows the perspective of a person that still has some remaining vision. I, however, have none. I am completely blind. I wanted to write a response that shows my perspective on the video about the possibility of regaining sight. I speak for myself, not for anyone else in the blind community or culture. I’ll also talk about the need of a Blind culture, and the cheapening of such culture by these types of videos.

The video, titled 1000 Blind people See for the First Time was hard for me to watch, in several ways. Firstly, the title is a lie. I’ll go through that later. Second, a lot of it is visual in nature, with very little description. Third, it was not described, using any kind of audio description. Audio description is where a video has another audio track that plays alongside the original, where a person is describing the events that happen during the video. Not just the text, or the main idea as in this video, but the people, places, actions in the video. Sometimes, Youtube videos have “separate but equal” versions with descriptions, but I tried searching for it, but could not find it, using my admittedly slower Mac with Safari and VoiceOver. Still, if this video was about blind people, it should be suitable for blind people as well. It reminds me of the accessibility overlay companies, which will gladly post on social media images without descriptions.

The Big Lies

Let’s pick apart the title of the video. I’m not going to concern myself with 1000. That seems cruel to me, just picking an arbitrary number like that, but let’s move on. “Blind people.” Were these people blind? No, they weren’t. In the culture I live in, they would be called “low vision” or “visually impaired.” Mr. Beast cured people with cataracts. In the worst circumstance, maybe that could mean blind. But in the video, there were people that had been blind for four months. Imagine having a disability for four months. Comparing that to my life of absolutely no vision is very harmful, and cheapens the lives of those who are actually blind, and makes me feel as if I’m not even worthy to be called blind, or that my experiences are absolutely worthless, that my work is worthless, and that my life is meaningless. Let’s move on to the next part. “For the First Time.” Again, a lot of these people could see before. Maybe they couldn’t see perfectly, but their eyes could perceive enough to live mostly normal lives. They could see people’s faces, with glasses. In fact, one of the people in the video said something like “Well I don’t need these anymore.” I don’t know for sure, because again the video wasn’t described, but I’m pretty sure she was referring to glasses. You know what? If I could see well, even enough to not need a screen reader, I’d happily, happily take glasses over what I have now. If I needed glasses and a screen magnifier to see a computer or television screen, I’d take that in a heartbeat.

The cheapening of Blind Culture

The next time you meet a Deaf person, I want you to ask them how they would respond if a person with some hearing loss approached the Deaf person, and told them that they, the person with hearing loss, was also Deaf. Now, I don’t know any Deaf people personally, and am not Deaf myself. But I’m pretty sure it wouldn’t go over well, to say the least. The reason I think this is that I never hear any hard of hearing people call themselves Deaf. Why? Because their experience is not the same as a Deaf person. The same applies to Blind people, if indeed we want to be a stronger culture. We must be allowed to have our own words, our own experiences, our own culture. To do otherwise is to weaken and cheapen the bond shared by all totally blind people.

If, instead, we allow videos like this to claim our words, our terms, and our experiences, we’ll need to retreat to where Autistic people are now, having to call themselves “Actually Autistic.” Why? Because the broader culture claimed their word and their way of finding and talking about one another, and explaining themselves. So now they have to use another hashtag to show who they actually are. And honestly, we have so little power as it is. If we allow the term “blind” to be used for those who have usable vision, the general population will then think that there are no people that can’t see at all, and when we tell them that we cannot see, they’ll think we’re lying. This already happens sometimes to me. And it’s yet another slap in the face.

And here we get to the biggest problem with this video: its effect on the general population. Now, if people don’t look any further, which many conservatives have proven that they will not, people will think that blindness is curable in 10 minutes, which it’s not. There are so many causes of blindness, and so many do not have cures. A lot of blind or low vision people do not want to be cured, fine with the life they live or the vision that they do have. And now, sighted people have a video to point to. “Dude it’s just ten minutes,” they’ll say. “Are you so anti-vaxxxxx that you won’t even stop being a burden on society?” Parents will guilt-trip their kids. Husbands will guilt-trip their wives. And for what? A cure that will more than likely not apply to them.

And what of people, like me, who want to even see as low vision people do? What of people who would give much for a cure, are shown this video and asked “Hey dude, check your mail! Maybe you were one of the 1000! Maybe you won!” Just another slap in the face. An undescribed video, an arbitrary number, a single cure, for those who are not actually blind.

Another aspect of this is that we do want to experience the world. Why else would we want pictures described, or to be able to watch videos or television, or play video games? Yes, we have our own culture. We have our audio books, text to speech voices, audio games, and screen readers. But we want to know the sighted culture too. Sure, some may not want to see, enjoying who they are. Others beg their god or science to be able to see . But whatever way we experience the world, either through sight, visual interpretation, or reading books about the world, we love experiencing it. Even those who do not want to see the world still live in it. But this video, with its outright lies and false hope and capitalistic choosing of just 1000 people, doesn’t help anyone. From the low vision people that were “left behind,” to the blind people for whom there is no cure, to the general public who will now have another excuse to shun us, it does more harm, I think, than good.

Over the past few years, I’ve seen something that kind of troubles me. While people on iPhones Write books on using the iPhone on their iPhones, clear out their Email on their Apple Watch and manage the rest on their iPhones, and use their iPhones as their primary computing devices, Android users feel like one cannot be productive on any mobile system. So, here’s the thing. When you are around sighted people, even at a job sometimes, what are they using? Their computer? No. They’re on their phone. Maybe it’s an iPhone, or perhaps it’s an Android; it doesn’t matter. Either way, people are doing all kinds of things on their phones. When you go to a center of blind people, what do you see? People on their computers? Sometimes, but for younger people, they’re on their iPhones.

I’ll talk about the differences between iPhone or Android later. But this cannot be understated. The phone is now, for the majority of sighted, and even blind, people, their main computing device. And even a few older blind people I’ve talked to, they would rather not use a computer now. They’re all over their iPhone. So, what does this kind of productivity look like?

Quick flicks are best

Fast access to information is important. But being able to act on that information is even more significant. If I can’t quickly archive an email, I may not mess with using a Mail app that much. I want to get through my inbox, quickly, able to read through threads of info. The iPhone does this well, allowing me to flick up or down, double tap, and the email is out of sight. Within a conversation, I can move to the previous or next message, and archive, reply, or flag an individual message in that conversation. On Android, in Gmail, I can act upon a conversation, but inside a conversation, there are no quick actions. One must navigate through the message, along with any quoted or signature text, find a button, and double tap. Yes, there are other mail clients. Aqua mail comes close to being like the iPhone mail app. But it has no actions, and if one can get an honestly great mail client out of an iPhone without needing to buy another app, why should someone consider Aqua mail and Android?

A Book on a phone on a phone

I can’t get over how good Ulysses for iOS and macOS is. While I’m using Ulysses for Mac right now, I still consider what a person was able to make with just an iPhone, an app, and a Bluetooth keyboard. You may then say, “Well, if you’ve got a keyboard, you might as well have a laptop.” To which I would show a marvelous invention, called the pocket. A phone in your pocket, headphones in your ears, a keyboard in your lap (particularly one of those slim Logitech keyboards), and you’ve got a nice writing environment that is much less bulky than a laptop. A laptop with its trackpad and screen adding weight and thickness, along with the CPU and hard drive.

Next is the app. I’ve tried a lot of writing apps on Android. From iA Writer to a lot of Markdown note apps, I looked for a replacement for Ulysses that would give me the power that allowed a blind person to write an entire, large book on his iPhone. And I couldn’t find it. From unlabeled buttons, to no way to navigate by heading or link inside the document, to no way to link chapters together and export as a book, none of the apps were viable. This is not to imply that no app will exist in the future. And this does not imply that Android will not have a good enough accessibility framework to allow the creation of such apps later on. But right now, the iPhone, the most locked down operating system in the mobile space, has allowed a level of creativity from a writer which was before only seen on Windows beforehand. Furthermore, it allows a far more accessible writing environment, enabled by Markdown.

Android, meanwhile, is still trying to get dictation without TalkBack speaking over the person dictating, or Google Assistant without TalkBack loudly talking over it, phone calls where you don’t hear “keypad button” at the start of each call, image descriptions, a pronunciation dictionary, and so on. This isn’t to imply that the iPhone and VoiceOver are perfect. They are not, and amass bug after bug with every release. But, as of now, the iPhone is still the most productive platform. Android is coming around, quickly speeding up over the last year or so. I really hope it gets to the point where we can not only write books on our phone, but can also create apps, music, edit audio and video efficiently and effectively. At least, I’d love to be able to do any office work a job may require, with our phones hooked up to USB-C docking stations and keyboards and external displays.

More than likely, though, VoiceOver on the iPhone will continue to decline. TalkBack will reach where VoiceOver is right now, and stop because they ran out of ideas. The blind community will continue having to come up with workarounds, like not using the Notification Center when a Braille display is connected, or using Speak Screen on older iPhones from 2020 because VoiceOver is so badly optimized that it runs out of memory while reading an online article. Meanwhile, TalkBack will gain image descriptions, and it’ll be more than “gift card,” “blue sky,” on an app where you clock in and out of work, which is what VoiceOver does. TalkBack already speaks the text of the button, rather than describing the button. Yes, the button is unlabeled.

But the thing that really holds the iPhone up is the apps. Lire for RSS, Overcast for podcasts, Ulysses for writing, Seeing AI for recognition, and so on. And there’s an actual website with lists of apps for iOS. Android has podcast apps, RSS apps, writing apps, and recognition apps. And some, like Podcast Addict and Feeder, are great apps. But they don’t approach the accessibility of their iOS counterparts. Podcast Addict, for example, has the following layout when viewing episodes of a podcast: “Episode name, episode name button, and contextual menu Botton. Overcast, on the other hand, simple has a list of episodes. Android pros get around this by saying one should just feel one’s way down the screen, and scroll forward. What if one is using a Braille display or Bluetooth keyboard? What if one is both blind and lacks dexterity in the hands, so they need to use switch access? This is the kind of thing that iOS already has: a good, clean user interface. Sure, right now, it’s fallen into disrepair. Sure, you’ve got bugs crawling out from the walls. Sure, it feels sluggish on iPhones from just two years ago. But it’s still the best we have.

And this is where a sighted person cannot understand. To them, an iPhone X R is as good as the latest Galaxy phone, or even the latest iPhone, not mentioning the camera. Developers plan for sighted use. They make sure things look good, and flow smoothly, from the CPU on up to the touch screen. And yet, things work so differently to blind people. Adding a podcast episode to the queue may take a simple swipe on Android, but takes several swipes and taps for a blind Android user. And that’s why productivity, a good accessibility framework, apps development tools that automatically make a view as accessible as possible, and a good, high-quality screen reader are so important. And it takes all of that for a blind person to be productive, and that’s why most blind people in developed countries choose iPhone, every time.

To me, the core of accessibility is the operating system. What it allows, how easy the accessibility APIs are to both be used by developers, and upgraded by the operating system development team or community. At the same time, the support system of accessibility is the community. Without a community of users and developers, the accessibility of an operating system will not flourish.

In this post, I’ll discuss the different approaches I’ve seen in operating systems, and how users and developers in the community, primarily the blind community, have improved it. These are my opinions and thoughts, and others in the blind community, like fans of Linux, Android, and Windows, will feel differently.

MacOS and Android

These two operating systems are somewhat similar, in that they’re just now really getting support from their company on accessibility. MacOS had a good base, but is just now getting huge performance improvements and features that have been requested for years. Android had a stable base, if nothing else, and is also getting features that are making it more worthwhile to be used.

MacOS has had a good-sized community of blind users since the release of the iPhone 3GS and VoiceOver, maybe even earlier, to macOS Leopard. The community isn’t anywhere as large as the Windows community we’ll discuss later, but is slightly beginning to pick up steam, I’d say, as Windows falls into disrepair and macOS improves.

The community on Android primarily improves access by writing apps that work as accessibility services, like the Commentary screen reader, or the Advanced Braille Keyboard. Developers on macOS can script VoiceOver to a limited extent, allowing them to get information on, for example, what song is currently playing in Music, or how much free space is on their system. Using shell scripting with VoiceOver Applescripts could give powerful options for controlling a Mac computer with VoiceOver. Other apps have also been created, like VOCR for OCR and image recognition. An app called HammerSpoon is also used to add user interface sounds to macOS, like when a device is connected or disconnected.

Windows and iOS

Windows is the main operating system, besides iOS, that blind people use. It’s very open, but accessibility has markedly devolved since even Windows 10 a few years ago. From focus issues to keyboard commands being taken up by something blind people will not use, and when that feature is turned off, the keyboard shortcut is just mapped to nothing, Windows is declining. The community, however, is keeping it alive with addons and scripts for screen readers, apps for blind people, and the plentiful voices that have been created for Windows over the years.

Addons for NVDA include helpful tools like better handling of tables and the Windows console. There are also super-power tools like an automatic translation tool, a note-taker that can transform Markdown to Word format, and a talking clock that speaks the time every 30 minutes. Apps for the blind include a ton of games, MUD client packages with ready-to-go sound packs and scripts. Braille translation, YouTube audio downloaders, and in the past, even a full social network for the blind with a custom audio interface have also been created. Windows also allows for third-party screen readers, like NVDA and JAWS, alongside their Narrator offering.

iOS, on the other hand, is closed to addons and system-level extensions. This means that Apple’s small accessibility team has to offer all of VoiceOver’s features, and fix all the bugs. However, many apps exist to make things a lot better on iOS, from numerous games, to navigation apps, to text recognition and identification apps, and so on. Android has a good bit of these, but iOS has them all. Sure, Android has some that are smaller apps, but they just use either Microsoft or Google’s vision frameworks to do what the other apps on iOS already do. iOS also has been the first platform to do many things, like offer comprehensive Braille support, audible graphs, image recognition, accessibility actions, and screen recognition. On and smaller things like using actual pronounced audio as the substitute pronunciation, allowing someone to just speak how they want a word to be pronounced. Android doesn’t even have a pronunciation dictionary system-wide. No, pronunciation dictionaries for voices like Eloquence and Vocalizer don’t count. Oh, speaking of Eloquence, Apple was the first mainstream company to give many blind people what they want, Eloquence on their computers and phones. Now, regardless of what architecture iOS or macOS goes to, they’ll always have Eloquence. Compare that to Android where once phones go 64-bit, Eloquence is gone.

My thoughts

So, this is what’s wrong with Linux; it has very few blind people using it, and very few sighted people working on the accessibility frameworks. Windows just has such a history behind it that it cannot make itself more appealing to blind people. Apple I think need many more accessibility staff, and many more testers, especially in Braille, and management that will listen when they say a bug needs to hold back the release of an iOS version. Otherwise, bugs will keep piling up. Android is coming along, but it requires developers in the community behind it. Developers of apps will need to learn about accessibility actions, Braille support, and so on. As long as iOS languishes like this, Android can and will catch up. I’m somewhat excited about macOS, the most. It has a solid base, great features already built into VoiceOver and the system, and has iOS to lean on for things like a shared image description library. That talking clock add-on for NVDA? MacOS has that built in. Not even Windows has that. VoiceOver can also resize and move items, mostly useful in apps like GarageBand, but once tactile displays hit the market, who knows what will be possible with just that kind of forward-thinking support. Oh, not to mention the Actions' rotor on macOS, moving through linked items, heading navigation in documents, just little things like that that make macOS a joy to use.

I’d love to see that kind of attention to detail in other operating systems. I’d even more so love to see that attention to good design and a kind of understanding of how to make an interface where even a blind person feels like they’re using something beautiful. An interface that makes one want to continue looking at it because it’s so good, so helpful, and at the same time, friendly and inviting. Not the cold, sterile, and rundown feel of Windows, or the somewhat empty feeling of Android.

For years now, Google has been seen, for good reasons I’d say, as moving very slowly with accessibility. TalkBack would get updates in fits and starts, but otherwise didn’t seem to have people that could devote much time to it. Starting a few years ago with multi-finger gestures, TalkBack development began picking up steam, and to my surprise and delight and relief, it has not slowed down. They seem to spend as much time resolving issues as they spend creating new features and experiences. This was highlighted in the new TalkBack update that began rollout on January 9.

On that day, there was a TalkBack update from Google (not Samsung) which bumped the version to TalkBack 13.1. New in this version is the ability to use your HID Braille display over USB. Support for Bluetooth will come when Android has Bluetooth drivers for them. That alone is worth an update. But there’s more! New in TalkBack is the ability to spell check messages, notes, and documents. That alone was worth two major iOS updates to complete. But there’s more! Now, we can use actions the same way iOS does. That alone would have been worth several updates. Now, we have many more languages available for Braille users. We can now switch the direction of panning buttons. On the Focus braille display, the right whiz-wheel type buttons now pan, giving two ways to pan text. We can now move from one container to another, just like in iOS.

Now, I know that was a lot of info, in just a minor version bump. So let’s unpack things a bit. I’ll describe the new features, and why they impress me a lot more than Apple’s latest offerings.

HID Braille over USB

When TalkBack’s Braille support was shown off last year, there was a lot of talk about the displays that were left out. Displays from Humanware, which use the Braille HID standard, were not included on the list. That was mainly because there are no Android Bluetooth drivers for the displays, meaning TalkBack can’t do anything with them, over Bluetooth. However, with this update, people who have these displays, like the NLS EReader from Humanware, can plug their displays into their phone through a USB-C cable. This is made much easier because the displays work through USB-C anyway, and use them with TalkBack. This is made even simpler because Android phones already use USB-C, so you don’t need an adaptor to plug your display into your phone.

This demonstrates two things, to me. First, the TalkBack team is willing to do as much as they can to support these new displays and the new standard. I’m sure they’re doing all they can to work with the Bluetooth team to get a driver made into Android 14 or 15. Second, even if the wider Android team doesn’t have something ready, the accessibility team will do whatever they can to get something to work. Since Braille is important, they released USB support for these displays now, rather than waiting for Bluetooth support later. But when they get Bluetooth support, adding that support for these displays should be easier and quicker.

Now, TalkBack’s Braille support isn’t perfect, as we’ll see soon, but when you’re walking down a path, steps are what matters. And walking forward slowly is so much better than running and falling several times and getting bugs and dirt all over you.

Spellchecking is finally here!

One day, I want to be able to use my phone as my only computing device. I would like to use it for playing games, writing blog posts like this one, web browsing, email, note-taking, everything at work, coding, learning to code, and Linux stuff. While iOS’ VoiceOver has better app support from the likes of Ulysses and such, Android is building what could ultimately provide many developers a reason to support accessibility. Another brick was just put into place, the ability to spell check.

This uses two new areas of TalkBack’s “reading controls”, a new control from which to check for spelling errors, and the new Actions control to correct the misspelling. It works best if you start from the top of a file or text field. You switch the reading control to the “Spell check” option, swipe up or down to find a misspelled word, then change the control to “actions” and choose a correction. iOS users may then say “Well yeah I can do that too”. But that’s the point. We can now even more clearly make the choice of iPhone or Android, not based on “Can I get stuff done?” but on “How much do I want to do with my phone?” and “How much control do I want over the experience?” This is all about leveling the field between the two systems, and letting blind people decide what they like, more than what they need.

Actions become instant

From what I have seen, the iPhone has always had actions. VoiceOver users could always delete an email, dismiss notifications, and reschedule reminders with the Actions rotor, where a user can swipe up or down with one finger to select an option, then double tap to activate that option. This allows blind people to perform swipe actions, like deleting a message, liking a post, boosting a toot, or going to a video’s channel. Android had them too, they were just in an Actions menu. Unless you assigned a command to it, you had to open the TalkBack menu, double tap on Actions, find the action you wanted, and then double tap. Here are the steps for a new Android user, who has not customized the commands, to dismiss a notification through the Actions menu:

• Find the notification to be dismissed
• Tap once with three fingers to open the TalkBack menu.
• Double tap with one finger to open the Actions menu.
• Swipe right with one finger to the “Dismiss” option.
• Double tap with one finger.

Now, with the new Actions reading control, here’s how the same user will dismiss a notification:

• Find the notification.
• Swipe up with one finger to the “dismiss” option.
• Double tap with one finger.

This action is one that users perform hundreds of times per day. This essential task has been taken down from five steps, to three. And, with TalkBack’s excellent focus management, once you dismiss a notification, TalkBack immediately begins speaking the next one. So to dismiss the next one, you just swipe up with one finger, then double tap again. It’s effortless, quick, and is delightfully responsive.

On Android, since actions have been rather hidden for users, developers haven’t always put them into their app. Of course, not every app needs them, but it would help apps like YouTube, YouTube Music, Facebook, GoodReads, PocketCasts, Google Messages, WhatsApp, Walmart, and Podcast Addict, to name a few. It will take some time for word of this new ability to spread around the Android developer space. For Android developers who may be reading this, please refer to this section on adding accessibility actions. That entire page is a great resource for creating accessible apps. It describes things clearly and gives examples of using those sections in code.

Interestingly, the other method of accessing actions is still around. If you have an app, like Tusky, which has many actions, and you want to access one at the end of the list, you can still open the Actions menu, find the action you want, and double tap. In Android, we have options.

New Languages and Braille features

One of the critical feedback from users of Braille support is that there were only about four languages supported. Now, besides a few like Japanese and Esperanto, we have many languages supported. One can add new Braille languages or remove them, like Braille tables in iOS, except everyone knows what a language, in this instance, means, but very few know what a Braille table is. That goes into the sometimes very technical language that blindness companies use in their products, from “radio button” to “verbosity” which I should write about in the future. For now, though, Google named its stuff right, in my opinion.

In the advanced screen of Braille settings, you can now reverse the direction of panning buttons. I never liked this, but if someone else does, it’s there. You can also have Braille shown on the screen, for sighted users or developers.

For now, though, if you choose American English Braille, instead of Unified English Braille, you can only use Grade one Braille, and not Grade two. However, computer Braille is now an option, so you can finally read NLS BARD Braille books, or code in Braille, on your phone. This brings textual reading a step closer on Android!

Faster and cleaner

Speed matters. Bug fixes matter. In TalkBack 13.1, Google gave us both. TalkBack, especially while writing in the Braille onscreen keyboard, is somehow even more snappy than before. That bug where if you paused speech, TalkBack from then on couldn’t read passed one line of a multi-line item, is gone. TalkBack now reads the time, all the time, when you wake up your phone as the first thing it says.

Meanwhile, if I have VoiceOver start reading a page down from the current position, it stops speaking for no reason. iOS feels old and sluggish, and I don’t feel like I can trust it to keep up with me. And I just want Apple to focus on fixing its bugs rather than working on new features. They spent resources on technology like that DotPad they were so excited about, but no blind people have this device, while their tried and true Braille display support suffers. Yeah, I’m still a bit mad about that.

The key takeaway from this section is that perhaps real innovation is when you can push out features without breaking as much stuff as you add. For blind people, a screen reader isn’t just a cool feature, or a way to look kind in the media, or a way to help out a small business with cool new tech. It’s a tool that had better be ready to do its job. Blind people rely on this technology. It’s not a fun side project, it’s not a brain experiment. It’s very practical work, that requires care for, often, people who are not like you.

Luckily, Google has blind people that work for them. And, if the past year has shown an example, they’re finally getting the resources, or attention, they need to really address customer feedback and provide blind Android users with what will make Android a great system to use.

So, boiling my feelings on iOS versus Android down into a simpler post, as of now, iOS = features, Android = stable and seemingly more supportive of all the PWA apps that are zipped up and put on the app stores. Apple makes me feel like Squidward when I’m typing in Braille, pressing Space with dots 4-5 to translate, one… word… at… a… time! All that just to clear the translation queue or whatever when it gets stuck or whatever. And that’s where the crap comes in. On iOS, I have no idea what’s causing these types of anger-inducing issues. Oh and the bug where if you press Enter in, say, iMessage to send a message, except a menu pops up, is still there. That bug was supposed to be fixed in the latest iOS 16.2 update. But nope. I guess VoiceOver has lived long enough to be a mess. A sluggish, frustrating mess that no amount of image and screen recognition can fix.

Meanwhile, on Android, while Braille doesn’t have nearly the amount of features, it at least doesn’t have the bugs that exist on iOS. The translation system is about as good as JAWS. It doesn’t slow down, it doesn’t get stuck needing to be practically plunged like iOS, and the only issue is that when typing a colon then a right parenthesis, it doesn’t make the smiley face, but does something like conar or con) instead. So much for UEB making Braille better for computers to prosses. I think that will get much better with a Liblouis update, though.

Now, for the part about web apps, or something similar to Electron. With the Evidation app, on iOS, you get a lot of tasks, like how you’re feeling today, or health questions, out of order. So you hear one thing, then the second, then actions for the first then, and so on. I don’t doubt that this is an accessibility issue on Evidation’s part. But if Android can get this right, even when using a Braille display, Apple can get this right as well. Besides, TalkBack is the open source app, right? Apple can even learn from it. Imagine that. I mean, I know most blind people don’t care too much about all this. Most people love their iPhones and Apple Watches and AirPods. And I respect that. They are, after all, great devices with much vendor lock-in. But as bugs pile up, as garbage begins to stink, as dishes bring some flies around, more and more people are going to Android. Like, it’s already happening. Sure, it’s not a lot, but it’s growing, 1% a year I’d guess, at the least. And then they see that TalkBack has a tutorial, for getting started, and it talks about this Braille onscreen Keyboard, using a Braille display, icon descriptions, which I might add, are quite a bit more helpful than VoiceOver’s because VoiceOver is focused on the image, and has so much data and can’t really seem to zoom in and tell that that’s just an icon.

And Google isn’t slowing down either. I read a week or so ago that Google is opening an accessibility office in London I think. Somewhere in the UK I know. I’m not sure if that’s just going to be a place where Trusted Testers can go and test things, or if there will be more to it, but that, to me, shows that they’re done napping like they were since Android 5 to 10. And I’m here for it. Yes, Google has a ton of catching up to do. But I think we’ll see them put their own spin on catching up, like describing icons first, having tools that do one thing well, but linking them all together, like Linux, rather than having VoiceOver do everything as Apple does. So, during this Christmas, I’ve gone to live with family for a while, leaving my iPhone. I don’t feel like I’ll need it for a while. And maybe, with SoundScape being slated for decommitioning, I won’t have much more of a reason to go back to the iPhone. I just have to find good headphones and a good watch for Android and I’m good. It already works with my PC and ChromeBook, much better than the iPhone works with the Mac, so I just have to get good accessories.

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.

Discuss...

You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!

This post is to reflect on what can be gained by using Android, as opposed to iOS. My previous post, My Dear Android talked a little about this, but I wanted to go into further detail here.

USB-C has won

I have a lot of accessories, for computers and phones. I have a game controller, which uses Micro USB, but if you buy it now, it'll likely come with USB-C. I have a game controller for a phone, which uses USB-C. I have a Braille display, which uses USB-C. In fact, I'd say just about every modern Braille display uses USB-C. I have USB-C earbuds. All of these technologies use USB-C or can be made to use it with a dongle.

When I use an iPhone, any iPhone today, I have to put all these accessories through a dongle. I don't have a USB-C to Lightning dongle yet, but I do have a Lightning to USB A one. So, whenever I want to plug in, say, a USB-C Flash drive, I can't. I can't plug in my USB-C earbuds into the iPhone. Now, are their dongles for this? Sure. But why deal with that. USB-C has won, soundly, over Lightning. Lightning was always going to be a closed, Apple-only system. No one likes non-standard junk.

Audio and standards

As mentioned in another article, I have a pair of Sony LinkBuds S. These are a pair of truly wireless earbuds that have noise-canceling, transparency mode, integration with Google Assistant and Alexa, integrate with Spotify and Endel, and sound fantastic. When I used them with my iPhone, which has Bluetooth 5.0 (which the newest iPhone SE 2022 also has), the lag was just too much to deal with. When I use them with Android, the lag is noticeable, yes, but much less, and much easier to deal with. This really pushed me back to Android. With iPhone, I would have to get all Apple products to have the best experience. I would need to get the new AirPods or AirPods Pro. I would need an Apple Watch. I would need a Mac. With Android, interoperability means I can get any Android-supported accessories, and they would work just fine.

Another difference between the two ecosystems is that Google Assistant readily works with the LinkBuds S. Assistant reads incoming messages, reads notifications, and does just about everything one can do with the Pixel Buds pro. On iPhone, there is no way to get Siri to automatically read new notification unless you have a pair of AirPods. Seeing this, Android works with many more accessory types, not just in a basic way, but supporting them to their fullest potential.

Also, did I mention the Bluetooth codecs? In Android, several phones have 3 or more different codecs, to support the widest range of audio types. On iPhone, there's just SBC, the lowest quality codec that must be supported, and AAC, Apple's own codec. No APTX, no LDAC, no LC3. So, even if you get an expensive pair of headphones that supports APTX low latency audio, you won't get that support on an iPhone. To be fair, some Android phones don't support APTX either, but on Android, you have that choice of phones. On iPhone, you don't.

Works with Windows and Chromebooks

If you use your computer a lot, you may want to text with it. If you're blind, chances are that you have a Windows PC. Well, iPhone works exclusively with Mac computers, so you can't text from your PC, or make calls from your PC, or control your phone from your PC. Oh yeah, you can't control your iPhone from your Mac either. Anyway, you can do all this from a Windows computer. If you use Google Messages, you can even read and send texts from the web, using your phone and phone number. As an added bonus, the Messages for Web page is very accessible, and has keyboard commands for navigating to the conversations list or messages list.

This gives me the freedom to do what I want, from whatever device I'm on. I don't have to switch contexts from my computer, to my phone, just to send a text, or read a text. I can just open Messages for Web, and do everything there.

Are you a Developer?

How much do you think you'll save if you didn't have to pay $100 per year? That's how much it costs to have an app on the Apple App Store. If you're a blind developer, you may be paying for JAWS every year too, so that's $200 a year, just to make great apps for iPhone. Along with all that, you have to deal with the sometimes frustrating experience of not only using a Mac, but developing on it, in Xcode. Now, you may be using a framework like React Native, or Beeware for Python, where you don't have to code in Swift, or touch Xcode all that much. If so, that probably cuts down on a lot of stress. But you still have to spend money just to keep your app on the App Store.

On Android, all a developer needs to do is pay $25, once. That's it. There is the 15% service fee on in-app purchases, but if your app is free, you don't have to worry about any of that. Also, you aren't limited to one language. You can use Java, Kotlin, some C++, C#, Python, JavaScript, Dart, and Corona (Lua). Of course, a few of these, like JavaScript (React Native and such) can be used to create iPhone apps too. But with Android, you can use your superior Windows platform, VS Code, and NVDA or JAWS to develop Android apps easily. Also, Android Studio is accessible on Windows too.

Accessibility, the mixed bag

Now we get into the thing I'm all about, accessibility. If you use apps like Telegram, DoorDash, Messenger, YouTube, and others, you may find that they don't work as well as they should on iPhones. YouTube, just recently, gained a bug where you can't go passed the third or so item in the home tab. Android doesn't have that problem. DoorDash has reviews in the middle of their menus, and tells you the time the delivery will reach you, not the estimated time in minutes as it does on Android. In Telegram on the iPhone, if you have a message that covers more than the screen height, VoiceOver will not navigate to the next message until you scroll forward. On Android, TalkBack will eventually reach the next message, and will not get stuck.

This shows, to me at least, a slice of something strange. Android seems to have more of a flexible accessibility framework, allowing for code to tell more of the story than visuals. On iPhone, VoiceOver doesn't look passed the current screen of content, or the cross-platform framework doesn't tell VoiceOver about it, but does tell Android and lets TalkBack navigate to it. However the code works, it results in a worse experience on iPhone, and a better one on Android. I can't argue with results.

Now, for image descriptions. I do miss them, being on Android. But, I'm sure Google is working on them, with its testers. After all, TalkBack can describe text, and icons now. And it does that very well. So, I'm sure they'll get image descriptions down in maybe a year. In the meantime, I still have an iPhone, Lookout, Bixby Vision, and Envision to hold me over until then.

I'm also hoping Google works on audible graphs, as that's pretty helpful. I could see them integrating that with image descriptions to describe graphical graphs, which iOS doesn't do yet.

Now, for Braille, things have improved. I grabbed a Focus 14 to work with, and find that I can use my phone with Braille support for about 30 minutes, without growing tired of it. One really nice thing that TalkBack does is focus management. So, if you leave an app, then come back to it, focus will remain at the spot that you left it. So, if you're reading a Reddit thread in RedReader, and you go to Messenger to read and reply to a message, when you come back to Redreader, your focus will be on the exact comment you left it on. I don't recall that ever happening on the iPhone.

Mostly, it's a very good start of Android's new Braille implementation. One that, even though it's new, is very stable, and all commands work fine. There isn't the issue of HID-based displays on iOS, where you cannot assign the “enable autoscroll” command and such. Input works great, and there is no time when the input process gets stuck, and you have to press the “translate” command several times to plunge it out.

Conclusion

After spending a week with iPhone, I'm back on Android. Yes, I'm looking forward to greater accessibility, like image descriptions, Braille improvements, and audible graphs and charts, but I also love what Android is right now. Android is open, allows for greater innovation by developers, allows accessory manufacturers to create great, integrated experiences, and in quite a few cases, is even more accessible than the iPhone.

Android also allows one to use many of its services from a Windows computer, which is more popular in the blind community than Macs. This allows the user to stay in the same context, without needing to pull out a phone just to check a text. One can also make calls and control their Android phone from a PC.

In closing, thanks for reading this article, in my journey with Android and iPhone. I know I'm not done with this, and as the two operating systems grow and age, things will change, on either Android or iOS' side. Feel free to subscribe to my blog, or leave comments.

Discuss...

You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!

Last night, I turned on my Galaxy S20 FE (5G) again. To update apps, and compare a week away with the iPhone to how Android feels now. And, I must say, Android is still charming to me.

Telegram works better than on iOS. On iOS, VoiceOver gets stuck on a long message, not moving to the next message at all until you scroll forward. I've not tried Whatsapp yet, but I wouldn't be surprised if it worked better there too. Also, Doordash is a lot easier to use on Android, without all the reviews and junk getting in my way like on iOS.

But the big thing was my earbuds. I have a pair of Sony LinkBuds S, which sound great, work with either Google Assistant or Alexa directly, and not through the framework where you hold down the home button and use that sort of voice control interface, and has all the good stuff like noise canceling and transparency mode. That can also be changed through Google Assistant.

So, I can use it with my iPhone X R. It works pretty well, and I can use Alexa through it. But, the latency is awful, and it took a few tries before I could get it set up. On Android, though, the latency is mild enough to where I can deal with it, and setup was quick and easy. This is a symptom of Apple's issue of wanting control. I don't have the Airpods. I don't have the AirPods Pro. I do have the Sony LinkBuds S, which probably blow all AirPods out of the water with it's pretty literally chest-thumping base (at least for me and my hearing). The AirPods Pro, first generation, didn't have that. I have little hope that the second generation, or the regular AirPods third generation (that can get confusing really fast), would have that. Plus, there's one chord to rule them all.

That's right, USB C. I love it! It's everywhere, used on just about everything, and I can connect my phone to my dock at work and use it with a keyboard and wired headphones at work. Speaking of wired headphones, there are actually USB C headphones. There aren't many Lightning headphones. Yes, I can get Apple's wired headphones. But that's $30. What if I want a pair of $250 cans I can rock out to?

Lastly, TalkBack is on a good path. They've added basic Braille support, which they'll hopefully be improving throughout the coming year, Android 13 has Audio Description API's, and hopefully in the next update to TalkBack, image descriptions so I can see my cat that I had to give up recently. Poor little Ollie. On the iPhone, while image descriptions are bright and vibrant, Braille is starting to suffer a good many pesky bugs that make me not even want to use it. Maybe one or two will be fixed when iOS 16 is released, but they've got a week to do it, and I don't see them spending that much time on a minority of a minority. However, TalkBack's Braille support, while new, is pretty solid, a good base to work upon.

So, I wanted to post this to balance things out from my other post when I went from Android to Apple. My journey is definitely not over, and neither are the two operating systems in question. While we know what iOS 16 brings, new voices, door detection, and probably other stuff, the TalkBack team has been pretty tight-lipped on what they've been working on. I miss the days when we had more open dialog with them. But at least they have a blind person on the team that does interact with the community some.

Discuss...

You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!

During the last six months, I’ve used Android exclusively as my primary device. I made calls with it, texted with it, read emails with it, browsed the web, Reddit, Twitter, and Facebook with it, and played games on it. Now, I’m going to express my thoughts on it, its advancements, and its issues.

This will contain mostly opinions, or entirely opinions, depending on whether you really love Android or not. But whatever your stance, these are my experiences with the operating system. My issues may not be your issues, and so on.

Daily Usage

To put things into perspective, I’ve used my phone, the Samsung Galaxy S20 FE 5G, for the following, with the apps I’ve used:

• Email: Gmail, Aquamail, DeltaChat
• Messaging: Google Messages
• RSS: Feeder
• Podcasts: Podcast Addict, PocketCasts
• Terminal: Termux
• HomeScreen: 1UI
• Screen reader: Google TalkBack
• Speech Engine: Samsung TTS and Speech Services by Google
• Text Recognition/object detection: Google Lookout and Envision AI
• Gaming: PPSSPP, Dolphin, EtherSX2
• Reddit: Redreader

I’m sure I’m forgetting a few apps, but that’s basically what I used most often. For Facebook, Twitter, YouTube and other popular services, I used their default apps, with no modifications. I used all the Google services that I could, and rarely used Samsung’s apps. So, this is to show that I was deep into the Android ecosystem, with Galaxy Buds Pro, a ChromeBook, and a TickWatch E3.

The good

I want to start off the comparison with what worked well. First, Samsung TTS voices are really nice, sounding even more smooth, sometimes, than Alex on iOS, and much more so than the Siri voices. I still love the Lisa voice, which, to me, sounds as close to Alex as possible with her cadence and professional-sounding tone. Yes, the voices could be sluggish if fed lots of text at once, but I rarely ran into that.

I also love the wide variety of choice. Apple includes the AAC Bluetooth codec on their iPhones. So, if you get APTX, or Samsung’s Variable codec, or other headphones with other codecs, it won’t matter, and you’ll go back to SBC, which sounds the worst out of all of them. If your headphones have AAC, of course, it’ll get used on the iPhone. But if not, you’re stuck with SBC. Android phones, though, usually come with a few different codecs for headphones to choose from, and in the developer settings, you can choose the codec to use.

Another great feature of all modern Android phones is USB-C. Everything else uses USB-C now, including Braille displays, computers, watches, and even iPads. With Android, you can plug all these things into your phone with the same cable. If your flash drive has USB-C, you can even plug that in! With iPhone, though, you have to deal with Lightning, which is just another cable, and one you’ll likely have less of, since less stuff uses it.

The last thing is that Android phone makers typically try out new technology before Apple does, leading to bigger cameras, folding phones, or faster Wi-fi or cellular data. Now that the new iPhone SE has 5G, and probably the latest Wi-fi, though, that’s most likely less of an issue. Still, if you like folding phones, Android is your only choice right now.

Starting on the software, it’s pretty close to Linux, so if you plug in a game controller, keyboard, or other accessory, it’ll probably work with it. If you have an app for playing music using a Midi keyboard, and you plug one in, it’ll likely work. On iPhone, though, you need apps for more things, like headphones and such.

Another nice thing, beginning in the accessibility arena, is that the interface is simple. Buttons are on the screen at all times, not hidden behind menus or long-press options like they are a lot of the time on iOS. If you can feel around the screen with one finger, or swipe, you’ll find everything there is to find. This is really useful for beginners.

Another pleasant feature is the tutorial. The TalkBack tutorial guides Android users through just about every feature they’ll need, and then shows them where they can learn more. VoiceOver has nothing like that.

On Android, things are a lot more open. Thanks to that, we have the ability for multiple screen readers, or entirely new accessibility tools, to be made for Android. This allows BRLTTY to add, at least, USB support for HID Braille displays, and Commentary to OCR the screen and display it in a window. This is one of the things that really shines on Android.

The bad

Those Bluetooth headphones I was talking about? The Galaxy Buds Pro are very unresponsive with TalkBack, making them almost useless for daily use. The TickWatch has its own health apps, so it doesn’t always sync with Google Fit, and doesn’t sync at all with Samsung Health. Otherwise, the watch is a nice one for Android users. On iPhone though, it doesn’t even share the health data with the health app, just Google Fit, which doesn’t sync with the health app either.

A few days ago, a few things happened that brought the entire Android experience into focus for me. I was using the new Braille support built into TalkBack, with an older Orbit Reader Braille display, since my NLS EReader doesn’t work with TalkBack, since there is no Bluetooth Braille HID support. I found that reading using the Google Play Books app is really not a great experience when reading in Braille. Then, I found a workaround, which I’ll talk about soon, but the fact is that it’s not a great experience on Google Play Books.

So, I got confirmation that someone else can reproduce the issue. The issue is that the display is put back at the beginning of the page before even reading the next page button, and that one then cannot easily move to the next page. I then contacted Google Disability support. Since their email address was no longer their preferred means of contact, I used their form. On Twitter, they always just refer you to the form.

The form was messy. With every letter typed into the form, my screen reader, NVDA on Windows, repeated the character count, and other information. It’s like no blind person has ever tested the form that blind people are going to use to submit issues. “No matter,” I thought. I just turned my speech off and continued typing, in silence.

When the support person emailed me back, I was asked some general info, and to take a video of the issue. This would require, for me, a good bit of setup. I’d need three devices: the phone, the Braille display, and something to take the video with, probably a laptop. Then I’d need to get everything in the frame, show the bug, and hope the support person can read Braille enough to verify it.

This was a bit much for me. I have a hard job, and I have little energy afterwards. I can’t just pop open a camera app and go. So, I asked around, and found a workaround. If you use the Speech Central app, you can stop the speech, touch the middle of the screen, and then read continuously. But why?

This really brought home to me the issues of Android. It’s not a very well put together system. The Google Play Books team still uses the system speech engine, not TalkBack, to read books. The Kindle app does the same thing. There is barely a choice, since TalkBack reads the books so poorly. This is Google’s operating system, Google’s screen reader, and Google’s book-reading app. There is little excuse for them to not work well together.

Then, either that night or the night after that, I got a message on Messenger. It was a photo message. So, naturally, I shared it with Lookout, by Pressing Share, then finding Lookout in the long list of apps, double tapping, waiting for the image recognition, and reading the results. And then I grabbed the iPhone, opened Messenger, opened the conversation, double-tapped the photo, put focus on the photo, and heard a good description. And I thought, “Why am I depriving myself of better accessibility?”

And there’s the big issue. On iOS, Braille works well, supports the NLS EReader, and even allows you to customize commands, on touch, Braille, and keyboard. Well, there are still bugs in the HID Braille implementation that I’ve reported, but at least the defaults work. That’s more than I can say for TalkBack and Android.

And then the big thing, image descriptions, and by extension, screen recognition. TalkBack finally has text detection, and icon detection. That’s pretty nice. But why has it taken this long? Why has it taken this long to add Braille support? Why do we still have robotic Google TTS voices when we use TalkBack? After all these years, with Google’s AI and knowledge, Android should be high above iOS on that front. And maybe, one day, it will be. But right now, Android’s accessibility team is reacting to what Apple has done. Braille, image descriptions, all that. And if there’s a central point to what I’ve learned, it’s this: do not buy a product based on what it could be, but what it currently is.

Then, I started using the iPhone more, noticing the really enjoyable, little things. The different vibration effects for different VoiceOver actions. Not just one for the “gesture begin”, “gesture end,” “interactable object reached”, and “text object reached”. No, there are haptics for alerts, reaching the boundary of the screen or text field, moving in a text field, using Face ID, and even turning the rotor. And you can turn each of these on or off. What’s that about Android being so customizable?

Then there’s the onscreen Braille keyboard. On Android, to calibrate the dots, you hold down all six fingers, hold it a little longer, just a bit longer… Ah, good, it detected it this time. Okay, now hold down for two more seconds. Now you’re ready to type! Yes, it takes just about that long.

On iOS, you quickly tap the three fingers of your left hand, then the fingers of your right hand, and you’re ready! Fast, isn’t it? These kinds of things were jarring with their simplicity, coming from Android, where I wasn’t even sure if calibration would work this time. I do miss the way typing on the Android Braille keyboard would vibrate the phone, letting you know that you’d actually entered that character. However, the iPhone’s version is good enough that I usually don’t have to worry about that.

I want to talk a bit more about image descriptions. While I was on Android, I learned to ignore images. Sure, I wanted to know what they were, but I couldn’t easily get that info, not in like a few seconds, so I left them alone. On iOS, it’s like a window was opened to me. Sure, it’s not as clear as actually having sight, and yes, it gets things wrong occasionally. But it’s there, and it works enough that I love using it. Now, I go on Reddit just to find more pictures!

And for the last thing, audio charts. Google has nothing like this. They try to narrate the charts, but it’s nothing like hearing the chart, and realizing things about it yourself. Hearing the chart is also much faster than hearing your phone reading out numbers and labels and such.

The ugly

Here, I’ll detail some ugly accessibility issues on Android, that really make iOS look as smooth as glass in comparison. Some people may not deal with this, but I did. Maybe, by the time you read this article, they’ll be fixed in Android 13, or a TalkBack update or something.

First, text objects can’t be too long, or TalkBack struggles to move on to the next one. This can be seen best in the Feeder app, which, for accessibility reasons, uses the Android native text view for articles. This is nice, unless a section of an article spans one screen of text. Take the Rhythm of War rereads on Tor. Some of those sections are pretty long, and it’s all in one text element. So TalkBack will speak that element as you swipe to the next element, until it finally reaches the next one. This can take one swipe, or three, or five. This happens a lot in Telegram too, where messages can be quite long.

Another issue is clutter. A lot of the time, every button a user needs is on the screen. For example, the YouTube app has the “Go to channel” and “actions” buttons beside every video. This means you have to swipe three times per video. On iOS, each video is on one item, and the actions are in the actions rotor. TalkBack has an actions menu, but apps rarely use it. Gmail does, for example, but YouTube doesn’t. This makes it even more tricky for beginners, who would then have to remember which app uses it and which app doesn’t, and how to get to it and such.

When an Android phone wakes up, it reads the lock status, which usually is something like “Swipe with two fingers or use your fingerprint to unlock.” Then, it may read the time. That’s a lot of words just to check what time it is. Usually dependably, an iPhone reads the time, and then the number of notifications. Apple’s approach is a breath of fresh air, laced with the scent of common sense and testing by actual blind people. This may seem like a small thing, but those seconds listening to something you’ve heard a hundred times before add up.

If you buy a Pixel, you get Google TTS as your speech engine. It sucks pretty badly. They’re improving it, but TalkBack can’t use the improvements yet, even if other screen readers and TTS apps can. Crazy, right? However, with the Pixel, you get Google’s Android, software updates right at launch, and the new tensor processor, voice typing, and so on. If you get Samsung, you get a good TTS engine, for English and Korean at least. You also get a pretty good set of addons to Android, but a six-month-old screen reader and an OS that won’t be updated in about six months either. This is pretty bad mostly because of TalkBack. You see, there are two main versions of TalkBack. There is Google’s version, and Samsung’s version. Samsung’s TalkBack is practically the same as Google’s, but at least one major version behind, all the time. With iPhone, you get voices aplenty, from Eloquence—starting next month—Alex, Siri voices, and Vocalizer voices, with rumors that third-party TTS engines can be put on the store soon. You get a phone that, with phones as old as the 8, can get the latest version of iOS, and get them on the day they’re released. And there is no older version of VoiceOver just floating around out there.

Further thoughts

I still love Android. I love what it stands for in mobile computing. A nice, open source, flexible operating system that can be customized by phone makers, carriers, and users to be whatever is needed. But there really isn’t that kind of drive for accessibility. TalkBack languished for years and years, and is only just now trying to hurry to catch up to VoiceOver. Will they succeed? Maybe. However, VoiceOver isn’t going to sit still either. They now have the voice that many in the blind community can’t do without. On Android, that voice, Eloquence, is now abandoned, and can’t be bought by new users. And when Android goes 64-bit only, who knows whether Eloquence will work or not. iOS, on the other hand, officially supports Eloquence, and the vocalizer voices, and even the novelty voices for the Mac. They won’t be abandoned just because a company can’t find it within themselves to maintain such a niche product. Furthermore, all these voices are free. Of course, when a blind person buys an $800 phone, they’d better be free.

I’m also not saying iOS is perfect. There are bugs in VoiceOver, iOS, and the accessibility stack. Braille in particular suffers from some bugs. But nothing is bug-free. And no accessibility department will be big, well-staffed, well-funded, or well-appreciated. That’s how it is everywhere. The CEO or president or whoever is up top will thank you for such a great job, but when you need more staff, better tools, or just want appreciation, you’ll often be gently, but firmly, declined. Of course, the smaller the company, the less that may happen, but the disability community can never yell louder than everyone else. Suddenly, the money, the trillions, or billions of dollars, just isn’t there anymore when people with disabilities kindly ask.

But, the difference I see is what the two accessibility teams focus on. Apple focuses on an overall experience. When they added haptics to VoiceOver, they didn’t just make a few for extra feedback, they added plenty, for a feedback experience that can even be used in place of VoiceOver’s sounds. When they added them, they used the full force of the iPhone’s impressive haptic motor. Just feel that thump when you reach the boundary of the screen, or the playful tip tick of an alert popping up, or the short bumps as you feel around an empty screen. All that gives the iPhone more life, more expression in a world of boring speech and even more boring plain Braille.

The iPhone has also been tested in the field, for even professional work like writing a book. One person wrote an entire book on his iPhone, about how a blind person can use the iPhone. That is what I look for in a product, that level of possibility and productivity. As far as I know, a blind person has never written a book using Android, preferring the “much more powerful” computer. I must say that the chips powering today's phones are sometimes even more powerful than laptop chips, especially from older laptops. No, it’s the interface, and how TalkBack presents it, that gets in the way of productivity.

Lastly, I’m not saying that a blind person cannot use Android. There are hundreds of blind people that use Android, and love it. But if you rely on Braille, or love image descriptions, or the nice, integrated system of iOS, you may find Android less productive. If you don’t rely on these things, and don’t use your phone for too much, then Android may be a cheaper, and easier, option for you. I encourage everyone to try both operating systems out, on a well-supported phone, for themselves. I’ll probably keep my Android phone, since I never know when a student will come in with one. But I most likely won’t be using it that much. After all, iOS and VoiceOver, offer so much more.

Discuss...

You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!

This is going to be a more emotional post, which mirrors my mental state as of now. I just have to write this down somewhere, and my blog should be a good place to put it. It may also be helpful for others who struggle with this.

I've used just about every operating system out there, from Windows to Mac to Linux, ChromeOS, and Android and iOS. I've still not found one I can be completely happy with. I know, I may never find an OS that fits me perfectly, but so many others have found Linux to be all they ever need. I wish I could find that. Feel that feeling of not needing to switch to another laptop just to use a good Terminal with a screen reader that will always read output, or the ability to use Linux GUI apps, like GPodder or Emacs with Emacspeak.

There are times when Windows is great. Reading on the web, games, and programs that were made by blind people to help with Twitter, telegram, Braille embossing, and countless screen reader scripts. Other times, I want a power-user setting. I want GPodder for podcasts, or to explore Linux command-line apps. I asked the Microsoft accessibility folks about Linux GUI accessibility, and they just said to use Orca. I've never gotten Orca to run reliably on WSL2. It's always been reliable on ChromeOS with Crostini.

Whenever I get enough money, I'll get 16 GB RAM, so maybe I can run a Linux VM. But still, that's not bare metal. And if I switch to Linux, I would have to run a Windows VM, for the few things that run better on Windows, like some games, and probably the Telegram and Twitter support. It's all just kind of hard to have both. Dual booting may work, but I've also heard that Windows gets greedy and messes with the bootloader.

But, with there being a blind person working on Linux accessibility at Red hat, I hope that, soon, I won't need Windows anymore. I can hope, at least. But with there still being a few who have the mindset that I must fix everything myself, I must still remain cautious, and unexcited about this development among the hardcore Linux community, lest the little amount of joy a full-time Linux accessibility person being hired gives me, is taken away by their inflexibility and cold, overly-logical mindset.

But, I'm not done yet. With the little energy taking vitamins has given me, I've made a community for FOSS accessibility people on Matrix, bridged to IRC. I continue to study books on Linux, although I've not gotten up the energy to continue learning to program and practice. Maybe I'll try that today.

Mostly, I don't want newcomers to Linux to feel as alone in their wrestling with all this as I do. All other blind people are already so far ahead. Running Arch Linux, able to code, or at least happy with what they have and use. I don't want future technically inclined blind people to feel so alone. Kids who are just learning to code, who are just getting into GitHub, who are just now learning about open source. And they're like “so what about a whole open source operating system?”

And then they look, find Linux, and find so few resources for it for them. Nothing that they can identify with. Well shoot, there it is. Documentation I guess. I do want to wait until Linux, and Gnome or whatever we ultimately land on, is better. Marco (in Mate), shouldn't be confused whenever a QT or Elektron-based app closes and focus is left out in space somewhere. An update shouldn't break Elektron apps' ability to show a web view to Orca. And we definitely shouldn't be teaching kids a programming language, Quorum, made pretty much specifically for blind people. But I'm glad we're progressing. Slowly, yes, but it's happening at least.

Discuss...

You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!

Why tools made by the blind, are the best for the blind.

Introduction

For the past few hundred years, blind people have been creating amazing technology and ways of dealing with the primarily sighted world. From Braille to screen readers to canes and training guide dogs, we've often shown that if we work together as a community, as a culture, we can create things that work better than what sighted people alone give to us.

In this post, I aim to celebrate what we've made, primarily through a free and open source filter. This is because, firstly, that part of what we've made is almost always overlooked and undervalued, even by us. And secondly, it fits with what I'll talk about at the end of the article.

Braille is Vital

In the 1800's, Louis Braille created a system of writing that was made up of six dots configured in two columns of three dots, which made letters. This followed the languages of print, but in a different writing form. This system, called Braille after its inventor, became the writing and reading system of the blind. Most countries, even today, use the same configurations created by Louis, but with some new symbols for each language's needs. Even Japanese Braille uses something resembling that system.

Now, Braille displays are becoming something that the 20 or 30 percent of employed blind people can afford, and something that the US government is creating a program to give to those who cannot afford one. Thus, digital Braille is becoming something that all screen reader creators, yes even Microsoft, Apple, and Google, should be heavily working with. Yet, Microsoft doesn't even support the new HID Braille standard, and neither does Google. Apple supports much of it, but not all of it. As an aside, I've not even been able to find the standards document, besides This technical notes document from the NVDA developers.

However, there is a group of people who has taken Braille seriously since 1995. That is the developers of BRLTTY, of which you can read some history. This program basically makes Braille a first-class citizen in the Linux console. It can also be controlled by other programs, like Orca, the Linux graphical interface screen reader.

BRLTTY has gone through the hands of a few amazing blind hackers (as in increddibly competent programmers)), to land at https://brltty.app, where you can download it not only for Linux, where it's original home is at, but for Windows, and even Android. BRLTTY not only supports the Braille HID standard, but is the only screen reader that supports the Canute 360, a multi-line Braille display.

BRLTTY, and its spin-off project of many Braille tables (called LibLouis), have proven so reliable and effective that they've been adopted by proprietary screen readers, like JAWS, Narrator, and VoiceOver. VoiceOver and JAWS use LibLouis, while Narrator uses them both. This proves that the open source tools that blind people create are undeniably good.

But what about printing to Braille embossers? That is important too. Digital Braille may fail to work for whatever reason, and we should never forget hardcopy Braille. Oh hey lookie! Here's a driver for the Index line of Braille embossers. The CUPS (Common Unix Printing System) program has support, through the cups-filters package, for embossers! This means that Linux, that impennitrable, unknowable system for geeks and computer experts, contains, even out of the box on some systems, support for printing directly to a Braille embosser. To be clear, not even Windows, or MacOS, or iOS, has this. Yes, Apple created CUPS, but they've not added the drivers for Braille embossers.

Let that sink in for a moment. All you have to do is set up your embosser, set the Braille code you want to emboss from, the paper size, and you're good. If you have a network printer, just put in the IP address, just like you'd do in Windows. Once that's sunk in, I have another surprise for you.

You ready? You sure? Okay then. With CUPS, you can emboss graphics on your embosser! Granted, I only have an Index D V5 to test with, but I was able to print an image of a cat, and at least recognize its cute little feet. I looked hard for a way to do this on Windows, and only found an expensive tactile graphics program. With CUPS, through the usage of connecting to other Linux programs like ImageMagick, you can get embossed images, for free. You don't even have to buy extra hardware, like embossers especially made for embossing graphics!

Through both of these examples, we see that Braille is vital. Braille isn't an afterthought. Braille isn't just a mere echo of what a screen reader speaks aloud. Braille isn't a drab, text-only deluge of whatever a sighted person thinks is not enough or too much verbiage. Braille is a finely crafted, versitile, and customizable system which the blind create, so that other blind people can be productive and happy with their tools, and thus lessen the already immense burden of living without sight in a sighted world. And if electronic Braille fails, or if one just wants to use printed material like everyone else can, that is available, and ready for use, both to print text and pictures.

Speech matters too

If a blind person isn't a fast Braille reader, was never taught Braille, or just prefers speech, then that option should not just be available for them, but be as reliable, enjoyable, and productive an experience as possible. After all, wouldn't a sighted person get the best experience possible? Free and open source tools may not sound the best, but work is being done to make screen readers as good as possible.

In the Linux console, there are three options. One can use Speakup, Fenrir, and TDSR. On the desktop, the screen reader has been Orca, but another is being written, called Odilia. Odilia is being written by two blind people, in the Rust programming language.

If one uses the Emacs text editor, one can also take advantage of Emacspeak. This takes information not from accessibility interfaces, but Emacs itself, so it can provide things like aural syntax highlighting, or showing bold and italics through changes in speech.

Community

There are several communities for blind Linux and open source users. There is the Blinux, the Orca mailing list, the LibreOffice Accessibility mailing list, and the Debian Accessibility mailing list.

Recently, however, there is a new way for all these groups, and sighted developers, to join together with, hopefully, more blind people, more people with other disabilities, and other supporters. This is the Fossability group. This is, for now, a Git repository, mailing list, and Matrix space. It's where we can all make free and open source software, like Linux, LibreOffice, Orca, Odilia, desktop environments, and countless other projects, as useful and accessible as possible.

Blind people should own the technology they use. We should not have to grovel at the feet of sighted people, who have little to know idea what it's like to be blind, for the changes, fixes, and support we need. We should not have to wait months for big corporations (corpses), to gather their few accessibility programmers to add HID Braille support to a screen reader. We should not have to wait years for our file manager to be as responsive as the rest of the system. We should not have to wait a decade for our screen reader to get a basic tutorial, so that new users can learn how to use it. We should not have to beg for our text editor to not just support accessibility, but support choices as to how we want information conveyed. This kind of radical community support requires that blind people are able to contribute up the entire stack, from the kernel to the screen reader. And with Linux, this is entirely possible.

Now, I'm not saying that sighted people cannot be helpful, it's the exact opposite. Sighted people have designed the GUI that we all use today. Sighted people practically designed all forms of computing. Sighted developers can help because they know graphical toolkits, so can help us fix any accessibility with that. And I'm not trying to demean the ongoing, hard, thankless job of maintaining the Orca screen reader. Again, that's not even the maintainer's job that she gets paid for. However, I do think that if more blind people start using and contributing to Linux and other FOSS projects, even with just support or bug reports, a lot of work will be lifted from sighted people's shoulders.

So, let's own our technologies. Let's take back our digital sovereignty! We should be building our own futures, not huge companies with overworked, underpaid and underappreciated, burnt-out and understaffed accessibility engineers. Because while they work on proprietary, closed-off, non-standard solutions, we can build on the shoulders of the giants that have gone before us, like BRLTTY, the CUPS embosser drivers, and so many other projects by the blind, for the blind. And with that, we can make the future of Assistive Technology open, inviting, welcoming, and free!

Discuss...

You can always subscribe to my posts through Email or Mastodon. Have a great day, and thanks for reading!