Galactic Colonies – Accessibility Update

Since I announced that it will still be a little longer to get the accessible version of Galactic Colonies out, I thought I could at least keep everyone updated on the progress. 

First things first – no, I don’t have a release date for the accessibility yet. But the game is coming along great, and a lot of things have been done in the last two weeks. I wanted to give you a little update on what I’ve been working on, and share a short video.

Same UI, but different

I’m trying hard to make the accessible version of the game use the exact same UI as the game has when accessibility is turned off. That is not only consistent, but it makes it a lot easier to maintain the game, too.

But this doesn’t always provide the same game experience to sighted and non-sighted players. Sometimes a small change in how the UI works can make the game more enjoyable for players that rely on a screen reader.
Let me give you an example. 

To construct a building on a planet, a sighted player first selects the building from a list in the build menu. Then he can see the price and time it costs at the top of the menu. If he has enough money, he’ll hit the button labeled “Build” at the bottom of the menu to start construction. 

Sounds simple? Now do it blind!

Image doing the same task when you are navigating the construction menu with a screen reader, and traverse all buttons one by one.

Selecting a building is easy enough. But then you’d have to navigate back to the beginning of the page to read the price and the construction time. And this is assuming that you even know that you have to do that in the first place. Then, if you want to build it, you have to get to the very bottom of the page where the build button is, traversing through each and every building button on the way. The information and functionality that is instantly available for a sighted player is hard to get to for non-sighted players.

So instead, when accessibility mode is on, the price and construction time of a building is read out immediately along with the building name. And if the player wants to start construction, he can double tap while the building is selected, and that will automatically start the build process. No need to navigate to the build button at all. In fact, the button won’t even be shown if accessibility mode is turned on.

Side by side comparison of the construction menu in Galactic Colonies.

Left shows sighted mode menu, right shows the accessibility version

The code of the user interface had to be partially rewritten to support this change, but I think in return the construction menu is now really usable. You can see and hear this in action in the video at the end of this post as well.

Selling Stuff

To sell product from a warehouse, sighted player can use sliders. While they drag the sliders to the right to sell more and more of the product, other part of the UI will change to display how much product will remain and how much money will be earned if the player lets go of the slider at that point.

This is not practical for screen readers at all.

We took a lesson we learned from Crafting Kingdom and replaced the sliders with buttons. One button to sell all, one button to sell half, and one button to sell a single unit of the product in the warehouse.

Here’s screenshot of the warehouse menu for sighted and for accessibility mode next to each other.

Side by side comparison of the sell menu in Galactic Colonies.

Left side shows the slider based sighted version, and the right side the accessible version which uses buttons instead

In this instance, the UI had to be replaced by completely different UI which is only active when accessibility more is on. This change required both new code and a new user interface setup, so it took a little longer. 

Got something to show?

After the last post only included an audio demo I’ll include a short video in this one. Please keep in mind that this is still all extremely work in progress and by no means ready for release yet.

Thank you to everyone who’s commented and thank you for all the patience.

Galactic Colonies – Accessibility Sneak Preview

Galactic Colonies is on track to be fully accessible. Soon-ish.
Actually, it’s coming along quite nicely. I made a recording of the first 4 minutes of gameplay. If you’re interested in a sneak preview, here it is:

If your screen reader has issues with the sound cloud player, here’s a direct download link: Galactic Colonies Accessibility Audio Demo

Sounds like it’s almost done, when can I play?

In the demo, things sound a little further along than they actually are. In reality there is still a metric ton of work to be done.

I’m sorry to say, I have no release date for the accessibility patch yet. But it will more than likely be a few more weeks.

Different from all other games I’ve made accessible in the past, this game has a lot of 3D elements. Those are making things tricky, and there is need for many creative solutions.

Sounds a little… vague?

Fair enough. I’m going to describe an actual problem that I’m working on this week. That should demonstrate why it takes a lot of time to make this game accessible.

As part of the game, players have to build colonies on planets. This gameplay happens on the planet’s surface. Players can explore new regions, construct houses, farms and other production buildings and set up a flow of products between buildings. Everything is in 3D of course, and the camera can be moved and zoomed.

Screenshot showing a colony on a jungle planet, more than two dozen buildings, many lakes and part of the ocean

Colonies can get large

The difficulties start with selecting a free region to place your next building on. In the beginning only a handful of regions are explored, but there are a total of 2500 regions on each planets surface. Obviously I don’t expect players to swipe through them one by one, by one by one by one… I need to find a different method for players to navigate their colony.

The planet surface is flat, but it is a hex map, not squares. So a simple up, left, right, down navigation doesn’t cut it either. Each tile has six neighbors around it, not just four.

It is important to know which tiles are next to one another. Farms built next to a lake will produce more food. Houses next to an industrial building will have reduced capacity. Because which colonist wants to live next to a polluting, stinking factory? So the game can’t simply make the decision of where to build next for the player either.

The problems don’t end there. Some buildings need to be connected, so that one building can deliver products to another. You can produce food all day long, but you need a warehouse to store it in. And then you want the food to be distributed to your various houses, so your colonists don’t starve. Buildings that are too far apart cannot be connected. And one warehouse can only supply goods to a maximum of four other buildings.

Colony on an ice planet showing a warehouse receiving food from a farm and distributing it two connected houses

Warehouses are among the most important buildings in this game

Planning out what is delivered where is a core part of the game, so again, the game cannot make these decisions for the player automatically. These connections are set up visually by tapping on the buildings you want to connect. Difficult to do if vision isn’t an option.

But as you can hear in the audio demo, I haven’t been idle these past few weeks, and some parts of the game are already playable.

That was just a glimpse

I’m spending my days trying out a lot of different solutions to all of these problems, and then throwing away anything that doesn’t work.
This, obviously, takes time.

And keep in mind, everything I described above is just one of the mechanics in this game that I have to solve. It isn’t the only one. I haven’t even talked about space travel yet!

We made a good game with Galactic Colonies, and I’m determined to deliver a good experience on the accessibility part, too. I know as well as anyone how frustrating waiting can be, but I’m convinced it will be worth the wait.
Thank you for being so patient!

Stop punishing developers who are trying to make their games accessible

Heads up – I’ve written this post to vent a little bit.

The company I work for has just recently soft-launched a new mobile game called Galactic Colonies (Link). We are committed to making this game accessible for blind players as well eventually. We were actually hoping to have accessibility ready on release day, but we fell a little short of that.

A few weeks delay

To cut a long story short, we ‘re currently working on adding in the missing pieces, but estimate that we need a few more weeks until it is as playable as we want it to be.

an ingame screenshot of the game showing a desert planet surface with many houses, farms, storage and mining buildings.

Screenshot from Galactic Colonies

It is quite a complex game to make accessible. It contains lots of interactions with 3D elements, even including flying a colony ship around on a space map. All of these game mechanics need to be handled with custom new mechanics and love and care, which takes time.

We are completely aware that there are players with vision impairments who are waiting to finally be able to play. But nobody is going to enjoy the game if we release the accessibility mode of the game in a barely working state. A few weeks delay is worth it in our opinion.

Make your game accessible now, or else!

Ever since we started an open beta we’ve been regularly receiving eMails from blind players letting us know just how upset they are with us. Some of these are quite disheartening to me personally, considering I’m working hard on making this game accessible. We’ve also started to receive negative reviews on the store because the game is not yet accessible. In one case, a 1 star rating was accompanied by the comment that the reviewer would change their review only once accessibility is added.

Do a few bad reviews really matter? Yes. Our game just launched and overall review count is still low. So each 1 star review is quite relevant for our overall average score, and can cause some damage. The average rating will recover over time, but right now it’s there.

But really, the effect this has had beyond that is what matters.

Do bad reviews help?

The first comment of our production manager was this: “We should stop making any of our games accessible. That way we avoid these kind of reviews.”
This is probably not the reaction the people giving us bad ratings had hoped for.

The mood inside the company has shifted and taken a sharp turn away from accessibility being seen as something positive. Now it’s a topic that causes eye rolls and sighs of annoyance. Instead of working on accessibility, I now have to fight to justify all over again whether the time spent on accessibility is worth it. Every time the topic comes up, the review is slapped in my face. My job just got a lot harder.

It’s also highly doubtful that those reviewers will actually come back to change their ratings. By the time we’re done, they’ve most likely long forgotten about us. And knowing that is even more frustrating.

I feel punished for even trying

I want to explain how unfair this feels. Those players are most likely not going through every single inaccessible app on the store and giving it a 1 star rating. There are hundreds of thousands of apps that are inaccessible.

In other words, if we wouldn’t even try and just leave our game to be inaccessible, we wouldn’t have gotten those reviews.
Instead, we’re getting attacked exactly because we are trying to do better, trying to make our game accessible. Yes, we aren’t as fast as everybody wants us to be, but is this a reason to try and bring down our game’s rating?

See, leaving a bad review isn’t motivating us – or anybody – to work faster. It’s quite demotivating, to be honest.

Moving things forward

All things considered, the accessibility in Galactic Colonies is making good progress. We do not have a fixed release date yet, but it’s looking good. Most of the user interface is already accessible, and just last week we got space travel in the game working – but many things are still left to be done.

At the end of the day, we are a very small studio, self-funded, and don’t have the capabilities and resources that big studios have. So we’ll always be slower than the big guys.
That being said, thank you all for being so patient and sticking with us!

Unity Accessibility Plugin – Update 18 – WebGL Support

One of the features requested rather often for the Unity Accessibility Plugin is WebGL support. I’m happy to announce that it is almost ready to ship. In this post I’ll explain a bit about the problems WebGL presents – and their solutions.

Check out the UAP WebGL Demo

Woman sitting in front of her PC which displays the WebGL logo. She's looking exhausted, but happy.

Yes, the Unity Accessibility Plugin will have WebGL support!

WebGL and screen readers

My latest update to the UAP (v1.0.4) includes experimental support for WebGL. Experimental is my way of saying that the screen reader portion of the plugin works – aka UI navigation and interaction – but there is no speech synthesis. To use the plugin with WebGL, developers would have to write their own or purchase a third party text-to-speech plugin and connect it with the UAP.

This is because browsers do not have speech synthesis themselves. They rely on the user having a screen reader installed on their system instead. This works for text based content, but not for 2D and 3D content rendered in Unity via WebGL. Unity cannot access a user’s screen reader via the browser.

I’m currently working on the v1.0.5 release of the plugin to solve this issue.

All Text-to-Speech isn’t created equal

There are of course high quality speech synthesis plugins available on the asset store, which can be made to work with UAP with just a few lines of code. But I would like for the plugin to be as self-contained as possible and work as much out-of-the-box as I can get it. So I want something I can include with the plugin.

I could possibly get some low quality speech synthesis up and running based on some of the free and open source tech out there. But there’s no point in including a crappy text-to-speech engine with the plugin that produces barely intelligible audio.

Do you want your app to sound like this?

Keep reading – it gets better!

Google Cloud Text-to-Speech

Google offers a cloud based Text-to-Speech system. Cloud-based means that the Unity game would send the text it wants spoken to the Google server and Google sends it back a sound file with the generated speech.

I’m looking for a solution specifically for WebGL, meaning players will already be online. So an internet-based solution is a viable option.

And the quality is great.  Here’s the same sentence from the previous example, generated from Google:

Go ahead and listen to the first one again, to compare…


I was a little worried about the speed of the system. With this being a cloud based solution, the process is a little slower than a screen reader, which runs directly on the end-user’s system. Not only does the speech have to be synthesized, but it has to be send as an audio file via the internet to the end user.

But after I’ve tested the system both in the Unity Editor and in an actual WebGL app, I found that it’s not bad at all.
If you want to know how good or bad the latency is, here’s a demo:
UAP WebGL Demo

Some assembly required – but not much

The upcoming v1.0.5 release of the UAP plugin will include fully integrated support for the Google Text-to-Speech service. All a developer will have to do is to set their API key in the plugin settings and it will work. I will include a guide with lots of pictures on how to create the API key.

UAP plugin settings showing an input field asking to insert the Google API key.

The API key shown in this picture is bogus, by the way 🙂

Because the service is part of the Google Cloud, it isn’t entirely free and you need a Google account for it. You get a $300/12 months free trial period though, which is pretty awesome.

Here’s the link, if you want to test it out:
No, I’m not getting paid by Google, I just think a direct link is safe and convenient.

Other TTS Plugins

No solution is right for everyone. Developer’s might not want to use the Google Cloud API, or they might already own a different Text-to-Speech plugin.

With the new release, I reworked the way UAP handles Text-to-Speech, to make it very simple to connect to any other TTS plugin that the developer might want to use. Not that it was complicated before, but it’s just gotten a lot easier. I also added step-by-step instructions into the documentation.

Screen Reader Detection

I’ve written before about how important it is to detect whether your users are or (more importantly) are not using a screen reader.
Read the post here: Playing Hide-And-Seek with TalkBack

But it is near impossible to auto-detect whether a screen reader is installed or running on a user’s system when all you have is a WebGL app.

The reason is simple. The app could run in a myriad of different browsers and operating systems, and each system has a range of different screen readers that could or could not be installed. There is simply no way to get that kind of system information, especially not from within a browser.

In other words, on WebGL, UAP cannot detect whether it should turn on/off automatically. The only way to work around this is to pass a parameter to the game, for example via the URL. This is unfortunately still up to the developer.

Unity Accessibility Plugin – Update 17 – Hide and Seek with TalkBack

One thing that continues to keep me on my toes is screen reader detection. And when I say screen reader, of course what I really mean is Android TalkBack.

Screen Reader Detection – and why it’s Important for your Sighted Users

My plugin needs to know whether a screen reader is running, so it can spring into action and turn itself on.
And this needs to work flawlessly. 

We recently released a Crafting Kingdom update that turned on accessibility mode by accident on some devices – and we got swamped with feedback like this:
My phone started muttering to me and none of the buttons work!“.
(Note: I edited out the many colorful expletives that embellished these complaints.)

Man looking in horror at his cellphone, which is telling him to double tap a button to activate it.

“Help! What’s going on? It speaks!”

See, if you’re sighted, using a screen reader is not something that comes naturally. In fact, it is almost counter-intuitive. I’ve watched several friends and relatives stab at their screen helplessly, and after about 10 seconds they had enough. Our actual users will probably have less patience.

In a best case scenario they’ll will simply uninstall the game. They might also leave a bad review. If they spent money they’ll likely want a refund.
In a nutshell, better to err on the side of caution and only activate the plugin when a screen reader has been detected for sure.

I worked through the weekend to find a fix, because the only other option was to disable accessibility completely.

Detecting TalkBack on Android – the Pain Continues

Every major cellphone brand has their own version of Android. Samsung even has their own version of TalkBack, Samsung Voice Assistant. Code that works on one device is not guaranteed to work on another. And every update to Android can potentially cause more trouble. This happened with the Android Oreo release.

As it turns out, that update is incompatible with my TalkBack detection code. I had three different mechanisms implemented, just to be on the safe side. After the update, one of them would crash, and the other two would always report it was turned off.

Woman asks TalkBack whether it is running in the background. TalkBack hesitates and then replies 'Maybe'

Is it me, or is TalkBack dodging me…?

I rewrote my code and tried what I thought was a clever trick: I checked the device’s settings to see if accessibility was enabled. It worked great on my pure clean Android Nexus test devices. But when I tested it on an LG phone, the settings would always claim TalkBack was running, even when it was off. I was pulling my hair out at this point.

Not all devices were affected, but some of the popular ones were – most Samsung Galaxy S devices for example. Samsung has a market share of around 35% in the US. Not a user base you want to ignore. In fact, my company just bought yet another Samsung phone as a test device because of this.

Here’s the Solution – and the Source Code

In the end, I solved the problem by asking the phone for all accessibility services that are both currently enabled and provide spoken feedback. If there were any at all, it’s fairly safe to say that a screen reader is on – or that the user is familiar enough with them to not freak out if the phone started talking.

That worked on all test devices that I could find lying around in the office. It also worked on ten different devices in the Firebase test lab. That’s a Google service that runs your app on a plethora of different devices for you and provides error reports and video recordings. (Hint: If you haven’t yet taken a look at the Pre-Launch report in your Google Play developer console, don’t ignore it any longer.)

I want to spare other developers the pain, because Googleing the issue will lead to a lot of out-of-date code that won’t produce the correct result.
So here’s a code snippet for ya (works as of March 4th, 2017):

import android.accessibilityservice.AccessibilityServiceInfo;
import android.view.accessibility.AccessibilityManager;

private static boolean isScreenReaderActive(Context context) 
  AccessibilityManager am = (AccessibilityManager) context.getSystemService(ACCESSIBILITY_SERVICE);
  List<AccessibilityServiceInfo> enabledScreenReaderServices = am.getEnabledAccessibilityServiceList(AccessibilityServiceInfo.FEEDBACK_SPOKEN);

  return !enabledScreenReaderServices.isEmpty();


Whenever I complain about Android TalkBack I feel the urge to put a disclaimer at the end of my blog, to make sure I’m not mistaken for an Apple fan girl, who’s bashing on Android out of principle alone.
I’m not.

If you don’t believe me just come by the office on one of those days that I have to create new certificates and mobile provisioning profiles for our games on the Apple Store. See how much love I have for Apple then.

Unity Accessibility Plugin – Update 16 – Asset Store Sales (Am I Rich Yet?)

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.

Dark haired woman holding up two bags full of money with a satisfied smile

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


Unity Accessibility Plugin – Update 15 – Version 1.0 Released

Finally, a little more than a year after its inception, the Unity Accessibility Plugin is now live in the Unity Asset Store!

Three dark lower-case letters u, a and p. The a and p are shaped to resemble eyes or glasses.

The plugin now also has an official logo!

Check it out over here: UAP on the Asset Store

The last few weeks I mainly worked on finishing the documentation, cleaning up the code and creating a tutorial video.
I want to give a huge thanks to my beta testers who helped out a lot and found a few important bugs!

Initial Release: Android and iOS

UAP 1.0 officially supports iOS and Android. With that version out now, I want to focus on supporting Windows and Mac next. The released version actually already contains Windows support, but because it’s lacking in a few places I decided not to advertise that.

Development Roadmap

There are a number of things that didn’t make it into this initial release apart from Mac and Windows support. I have been using a Trello board for the past 5 months to track my work on the plugin, and to build a wishlist of nice-to-have features I want to put in eventually.
It’s a public board, so if you want to take a look at where things are going, here it is:
UAP Roadmap on Trello