VoiceOver

The Unity Accessibility Plugin has been on the Asset Store for 10 months now – time to take a look at the numbers.

Sales and Updates

The plugin is performing well for what it is: A small niche product.
On average, about 4 people pick it up each month. Not all of these are paid, since I occasionally give out a free key, and the plugin was on sale at a reduced price for a while.

Do you really think this is what’s happening?

If you do the math you’ll see that no one is getting rich from it.
Of course that’s not stopping the occasional side remark:
“Why isn’t this free!?” (to which I quietly sigh and then move on)

I always had very realistic expectations about sales (remember my post: Is It Worth Doing?). In fact, I had only anticipated about 1 or 2 per month. So by my standards, the plugin is actually outperforming! And the sales I get allow me to spend some time each month on email support and on updating the plugin. Since release, I’ve updated the plugin three times and I’m about to release a fourth update.

This is exactly what I was hoping for and I’m really happy the plugin is doing this well!

Mac Support (and JAWS)

One of the biggest features I’ve added was support for voice out on a Mac. I am not a Mac user and feel uncomfortable using one, so I kept putting it off. It wasn’t until a friend needed it that I finally took a deep breath and jumped in. The code for it turned out to be surprisingly trivial. My friend also helped me test it, which made it a lot easier.

I know that JAWS support is still sorely missing from the plugin, and it’s in the works. But that is a whole other can of worms, for another day.
Here’s the link to my Road Map on Trello if you’re interested in what else is coming:UAP Road Map

Imagine the following scenario:
You want to delete a file from your computer. A dialog pops up on your screen and a text message asks: “Are you sure?”. Below the text are two rectangular shaped gray areas. One reads “OK” and the other “Cancel”.

Raise your hand if you know how to click the OK button.

Did you know that you need to move your mouse cursor over the rectangle that reads “OK”, – and then, while hovering over it, click the left button on your mouse exactly one time?

Yes? You did?

Well of course you did!

We all know the basics of navigating user interfaces. We know to left-click on buttons, and to right-click for context menus. We use the mouse wheel and expect a page to scroll. We instinctively search for the close button in the upper corner of a window.

Those are established user interface conventions – and they are a good thing.

As a developer, it means not having to explain the interface basics to your users. You can safely assume that players know how to activate the button labeled “Play” in your main menu. You can just focus on teaching your players the rules of your actual gameplay.

Surprise: Blind users have interface conventions, too!

It shouldn’t come as a big surprise that such interface navigation conventions exist for blind users as well.It shouldn’t – but it seems that it does.

Often enough, when developers do go the extra mile to add blind accessibility to their games, they create their own interface navigation rules. One of their sighted programmers will spend an afternoon thinking about how it could work and then implement it. If he’s pressed for time he might not even look at how other games did it before. As a result, these games start out by reading a page of instructions to their users at the beginning. And that is about as exciting as reading a phone book.

Why break established conventions?

Not only is it boring to listen to instructions. Breaking conventions can also lead to losing users and turning them away from your app. Consider this: Every app that does this has their own navigation scheme. A blind user has to learn the quirks of each one and then try not to forget as they switch apps. Maybe they will remember the important basics, but if a game implements special gestures for things not used very often, let’s say for Pause for example, it will quickly be forgotten.

You don’t ask your sighted users to press Ctrl-K to click buttons, or right-click to scroll text, do you?
The same should be true for making your menus accessible. Don’t reinvent the wheel, don’t invent your own navigation scheme. Go with what’s already established.

Remember – in order to even start your app, the blind user will have to navigate to it and activate somehow. They know how to do that. They are already using an interface. If your app could be navigated the same way that the user navigated their operating system, you wouldn’t need instructions at all.

Not building on what users already know is creating an unnecessary entry barrier. And for blind users especially, more barriers is the last thing they need.

Made by Apple.

For mobile accessibility, the conventions have pretty much been established by Apple, because their VoiceOver screen reader is the gold standard. The majority of blind smart phone and tablet users are using Apple devices, and these devices are running VoiceOver.

The folks at Apple have done a great job with VoiceOver. Apple received an Access Award from the American Foundation for the Blind in 2009 and a Helen Keller Achievement Award in 2015, and the Bray Award for Accessibility Innovation in 2016 from the American Council of the Blind.
Whether you are an Apple fan or hater, following the really simple interface conventions from VoiceOver is a good place to start.

The freedom to be impatient

Whether you implement your own system or go with established conventions is ultimately up to you, of course. If there is one thing to be said about blind mobile users, it’s that they are incredibly patient and resilient. If your game is good, heck, even if it is just OK, they will probably be willing to jump through the hoops of learning how to navigate your menus either way.For now.

A sighted user will uninstall a game within seconds if he finds the controls frustrating. There are enough other games out there – the Google Play store counted 2 million apps in February 2016 (Source: Statista.com). Blind users don’t have that option. It won’t surprise you to hear that the number of accessible games is extremely limited.

But that number is growing.
And here’s why:

There around 21 million blind or visually impaired people over the age of 18 in the US alone (Source: AFB). In my opinion it’s one of the few customer groups still left in the mobile market that aren’t yet over-saturated with games. In other words, there is money to be made. The challenge to create games specifically for the blind is also attractive to game designers. If it’s financially viable and artistically interesting… all that’s left is the technical barrier.

And the easier it gets to create accessible apps and games, the more developers will happily take up the task. I hope that my plugin will help with that as well. This is a good thing, because everybody wins. Blind people get more software and more developers can make a living doing what they love.

There will come a time when blind users have a choice. They will have the freedom that we sighted users already have: The freedom to be impatient.

And unless a game has outstanding gameplay – those apps with unusual and tricky interfaces will be the first to be ignored.

I’m guilty

Remember that time pressed programmer I mentioned, who implemented her own accessible menus without regards to existing conventions? Yeah, that was me. I created an elaborate interface system, based on long taps and circular menus. But I’ve learned my lesson earlier this year and deleted all that code. I found a forum with lots of blind gamers and asked them for their help and feedback, and got plenty. It’s when my idea to write a plugin for Unity was born. If you would like to see just how helpful this huge community is, here is the link to the original forum thread.

All apps made accessible with my plugin will automatically be working similar to VoiceOver. Like I said, I am not a fan of reinventing the wheel. You can read more about the plugin and how to make games for sighted and blind users for Windows, iOS and Android in Unity here: Accessibility Plugin for Unity

If you prefer an overview over the gestures in table format, you can find it here: VoiceOver Gestures (Warning, some of the descriptions might not make sense if this is your first contact with VoiceOver – I recommend the above podcast instead.)

Explore By Touch is an accessibility feature on smartphones that let’s blind users run their finger over the screen – and the screen reader will read out what’s under their fingertip. The screen reader also makes sure that no buttons are accidentally pressed or an app is started unintentionally. This works on both Google TalkBack and iOS VoiceOver.

This was my original impression of Explore By Touch. Typical rookie mistake of a sighted person.

I originally thought that this is one feature that I wouldn’t need to re-create for the accessibility plugin, because I figured that no one would be using it much. I assumed no one wanted to blindly poke around on the screen to discover buttons. Why would anyone do that when swiping left and right navigates safely through the user interface?

Think again, you sighted fool!

As we all know, making blind assumptions is a bad thing. Pun intended.

Why would anyone use Explore By Touch?
The answer is simple. Because it is faster!

Navigating menus is a necessity, not fun. Doing it slowly by stepping through all elements on the screen one by one doesn’t make it any better.
If you already roughly know where a button is located, then using Explore By Touch is the next best thing to actually seeing where it is and clicking it directly.

Sure, the first time you get hit with a new menu, you might just trigger the Read From Top function and have the entire screen read out to you. But after that, you can poke around and find out where things are. And being blind doesn’t mean you cannot remember roughly where a button is located on the screen.

Thanks for the Feedback

I wouldn’t have come to this conclusion if I hadn’t received some very clear feedback from an actually blind person, who straight up told me the plugin would be pretty much useless without Explore By Touch. His opinion matched what I read in an article by Matt Gemmel in which he covers Myths about visually impaired users. After that I put my phone back in accessibility mode for a while and ultimately had to agree. It made me want that feature, too.

I am happy to announce that my plugin’s Explore By Touch is now fully functional.
Also: Thank you for your honest feedback, Scott!