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.