The tools for making games accessible
In my open letter to game developers, which I published here two days ago, I deliberately chose not to go into any technical detail. My intent was to cover the why, not the how, of accessible games. Thus having set the stage, we should probably begin the play by assembling valuable technical resources to aid developers in providing the level of accessibility we would love to see.
But first, a high-level overview:
The good news is that text-based games, at least as long as they stick to using native user interface functionality directly, are usually quite accessible out of the box. Screen readers now exist for all major platforms including Linux, Windows, iOS and Android. As long as the user interface elements of these platforms are used the way they were designed to be used, and as long as alternative text is provided for graphical elements, you essentially get accessibility for free. Buttons will read as buttons, lists as lists, and editable text as editable text, with all the associated usage patterns fully implemented by the operating system. Iterative testing and finetuning are of course still required, but the necessary changes are usually easy to make.
Why, then, aren't all games relatively accessible out of the box? To find the answer, we must understand how the native ui frameworks of operating systems work. While they know about buttons, lists, menu bars and check boxes, you won't find racing cars, magic swords, potions or billard balls in them. So to implement the objects and mechanics typically encountered in game universes, developers don't talk to the operating system directly. Instead, they tend to put a layer between their game apps and the operating system. That intermediary layer, often provided by a third party and called a game engine, provides the typical game-related services such as realistic physics, binaural audio, highly optimized graphics, level editors, and support for popular game controllers. As an additional bonus, game engines are often developed for several different platforms, so a game developed with such an engine will run on all platforms provided by the engine.
The bad news is that game engines have traditionally been developed without taking accessibility into account, which brings us full circle to our initial question. This is why most games turn out not to be accessible even when running on platforms offering a great deal of accessibility features, such as iOS or Android.
Having covered the good and the bad news, I must resist the temptation to conclude with the ugly. Rather, I'd like to highlight what I consider to be the biggest game-changer in recent developments.
The developers of Unity, one of the more popular game engines, have recently become interested in accessibility and inclusion. On their website they are asking for accessibility-related feedback in a forum thread which you can find at the following location:
This thread is worth a detailed read. Among the more valuable nuggets is a talk on making Unity accessible, given by the amazing Michelle Martin of MetalPop Games. Her beautiful mind is behind the accessibility of Crafting Kingdom, and she is currently working on some complex accessibility patterns for Galactic Colonies. Michelle, we love you.
The forum thread also links to other interesting threads where additional nuggets are hidden amongst the usual white noise of heated opinion pieces. If you're a developer, they're all worth your time.
To set the spirit of this thread: Let's continue to populate it with resources devs and aspiring devs may find interesting and helpful in their quest to make their mainstream games accessible. We're talking tools here like the Unity Accessibility Plugin, but also examples of games using those tools, such as Crafting Kingdom or Feer.
Let the games begin!