Unity Accessibility Plugin – Update 13 – How fast can you make an existing app accessible?

With my plugin now in beta testing stage, I was wondering how long it actually takes to make an existing app accessible using the plugin.

So I did a little experiment.

How long does it take?

For this test, I used a game from our company that had just come out of beta testing and was about to be released. Aside from some final bug fixes, the game was done and just waiting for the localization to finish. Not a single thought had been given to accessibility during development.

Result:
It took me a little less than four days to make it totally accessible.

A forest backdrop with the words 'Crafting Kingdom' written in front. A hammer and a pickaxe hover on either side of the text.

If you want to skip the rest of this blog and just check out the game, you can download it here:
Crafting Kingdom on the iOS App Store
Crafting Kingdom on the Google Play Store

Some Perspective

Maybe you have a game in mind that you’d like to make accessible and wonder how much work it would be.
Allow me to give you some additional context, so that you can put my result into perspective and draw your own conclusions.

The game I used is neither small nor simple, and has a ton of UI. It has a scrolling world map, over a dozen different locations with custom UI screens and dialogs, and almost each of them has a custom help screen. There are tutorial windows and statistics screens. In comparison, the Match 3 game I made had only a main menu screen, the game screen and a pause menu.

A medieval world map. Several locations are highlighted, such as a castle and a city.

This map can scroll in two directions

And while this game has a lot of text, it also makes heavy use of icons instead of text labels. It uses 32 different resource icons, a coin image to indicate a price, an X on cancel buttons, a check mark on confirm buttons, an image of a left arrow to indicate a back button… The list goes on. 

Many games use icons in lieu of text. Using images is prettier, uses less screen space, it makes the app playable by people who can’t read, and it saves money on localization. It is a win-win-win-win for the developer. Really the only drawback is that it makes accessibility a little harder.

One of the game screen showing a production pipeline. Graphics show that a ladder can be crafted from two pieces of timber and two pieces of leather.

A screen full of information, but barely any written text.

But not that much harder. Adding accessibility text to an image is easy enough, it just means it isn’t a one-click deal to add an accessibility component to the UI element and be done. You have to type in a name into the appropriate field of the accessibility component. For the product icons I had to modify the code to write the correct text into the accessibility component dynamically.
However, this particular game is localized in 12 languages, and I didn’t want to break with that. So I had to generate localization keys in our database as well which slowed me down a little.

The optional Extra Mile

I also didn’t just slap on the accessibility components and call it a day. That would have worked, but I knew that with a little effort the playability could be much improved.
For example, when a help text was useless for a blind player in its original form – e.g. “Click on the white house” – I created an alternate version of the text and had that read out instead.

I added in additional sound effects for extra feedback which are played only when accessibility mode is active. When a treasure chest appears somewhere on the map, a jingle sound will play. When the player cannot afford to buy something, he will be informed verbally that he doesn’t have enough money. Similarly, the game will speak up and tell the player when the warehouse has run full. Sighted players are notified of this with an animated, bright red colored text at the top of the screen.

Game screen showing the farm. It has four work stations, which are busy producing grain, meat and wool.

When a product is finished, a sound effect will be played.

Because this game has so many buttons and labels on the screen all the time, I grouped the UI elements by context, to make navigation a little quicker. The plugin supports up and down swipes (instead of the normal left and right swipes) to skip directly between groups. This means blind players can get to where they want faster, instead of having to cycle through every single UI element on screen. In a few dialogs I also set up a custom manual traversal order for the individual elements, because the most important information wasn’t always at the top. For example, the game always displays the name of the location that you are in at the bottom of the screen.

In one screen I actually decided to change the interface a little. I added a new layer of UI which offered buttons where there was a slider for sighted people. In that particular context it was the better choice. An accessible slider wouldn’t have given the same fine control to blind players as it gave to sighted ones in that particular context.

Results

With all that extra work it stands to reason whether I could have been done sooner, had I just done the bare minimum. On the other hand, I know my plugin better than anyone else. The speed advantage I gained from that probably more than made up for the difference.

You know your games best, so you can judge whether my results are applicable to you. In any case, they are a good indicator of the general scope. It doesn’t take months or weeks to make an app accessible. The work is more in the realm of days.

Just to be on the safe side – I am definitely not promising that you can make your game completely accessible within four days using my plugin. So don’t sue me.
(Write to me for help instead!)

How fast you will actually be will probably strongly depend on my ability to write good documentation. That’s what I am currently working on.

Afterthought: Not everybody does accessibility from the start, and that’s OK

As a general rule of thumb, I’d say if accessibility is added in early in development, it will be a smoother ride for everyone.

If you do it from the beginning, you quickly get into the habit of attaching an accessibility component to every UI right when you create it. And you implement any additional feedback for blind players at the same time that you actually implement the features. At no time during development will you be more familiar with the feature’s code. Thus, you are less likely to forget any special cases and can make sure everything runs smoothly in accessibility mode as well.

But in reality accessibility is often added later – possibly only after the game is finished. I really want to avoid saying ‘accessibility as an afterthought’ here in this context, which I stumble on a lot when browsing. It just sounds so negative. That’s unfair to any small game developer who wants to put in the work to make their app accessible. They are trying to do something good and don’t deserve to be berated for not having thought about it sooner.

Also consider this – everybody who adds in accessibility late in their current game might add it in early in their next one.

Surprise: Blind users have established interface conventions, too!

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”.

An alert asking the user whether he really wants to delete the file. The options are "OK" and "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

Further Reading