Prioritising Accessibility Considerations

A common question around accessibility is where to start. What to concentrate on if you're late in development, have limited resources, aren't familiar with the topic. I've often seen developers paralysed by this, wanting to do good work but overwhelmed by the possibilities and worry of getting it wrong. 

There are many ways to prioritise accessibility. How many people a given consideration benefits. How much difference it makes to the experience. How innovative it is. How difficult it is to implement. How well it fits with the unique set of kind of barriers that the game in question presents. 

This post summarises a short piece of work to look at a generalised set of priorities, commissioned for two purposes - use in teaching, and use in development of a set of indie games. The work was in two parts. First, a brief to examine available data on which features disabled gamers say they use, and identify any patterns from that which may indicate which are the most used / most useful. Second, some broader discussion of more general prioritisation issues and methods that sit outside that data. 

Surveys

The first piece of this work was to look at available data. Three sources were used - 

There isn't much else available beyond these three. Other survey-based research does exist, but it covers questions like types of impairment, types of games played and so on, rather than individual accessibility accommodations. 

Limitations

The data from all three sources must be taken with a huge grain of salt. 

In the paper the authors mention likely selection bias, as their survey is not a survey of the general population or representative of it; their sample is self-selecting, described as people who:

Similar applies to the two twitter threads. Small sample size, large selection bias. Someone replying to either twitter thread is someone engaged enough to have seen it in the first place, someone who identifies as having accessibility needs, and someone free enough from stigma to feel comfortable talking about it - people who will not publicly admit to having serious difficulty reading for example, are common.

The nature of the questioning also means that respondents are thinking in general terms about features that are applicable across all games, so there is little representation of game-specific considerations.

But these caveats aside, it is still some data. It just has to be looked at realistically, in the context of its limitations. The top considerations from these sources cannot be taken as a canonical prioritised list; but the considerations that are frequently mentioned can still be taken as considerations that matter to lots of people, and so are worth treating with some degree of priority. 

Breakdowns

https://docs.google.com/spreadsheets/d/1joV5_VbfssdTYD-HfZCABYbGiy3dY3a_kkR5OjmkqgI/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1ovgepgfj39vNsk0jFue9AIxY0Hywu-Z2FagurQDGrN4/edit?usp=sharing 

https://docs.google.com/spreadsheets/d/1-S6Pp0XJl0Ocndzsx3_Iyq-t3a5bAUCWpmKqEWutgcE/edit?usp=sharing 

Survey conclusions

Again while the ordering in those breakdowns can’t be taken as prioritised lists, here are ten considerations that crop up consistently across the three. 

I'm aware that I'm repeating myself here bit it's important to be as clear as possible that caveats apply to this data. They cannot be regarded as the ten most important considerations, they are likely neither the ten with the most reach or the ten with the most impact, either in general or for any specific game. However what they can be taken as is ten considerations that will usually make a significant difference to the experience of a significant number of people.

Some of these are backed up by other sources. Anecdotal social media observations of the most commonly complained about issues being text size followed by remapping, subtitling, and colourblindness. And a publisher’s analysis of the top three issues most commonly complained about through their feedback mechanisms - text size, remapping, and colorblindness. 

Anecdotally, simulation sickness and photosensitivity often result in people regarding the problem being with themselves rather than the design, so it likely under-reports in the data. But its impact is far greater than any other. It can cause discomfort, pain, serious injury or even worse, so it is critically important to consider too.

So for a top 5 it might be worth prioritising these -

Other angles

So if you want to go beyond just using a short generalised list like this as a way to get started with the basic fundamentals - where to from there? What else is useful to take into account?

Game-specific considerations

When progressing from getting the general basics right, again a significant gap from the surveys is considerations that are relevant to your specific mechanic, the kind of barriers that your specific game presents and the kind of solutions that fit with the experience you have in mind for your players. What’s sensible to prioritise for Civilisation is quite different to what’s sensible to prioritise for Doom.

The ideal way to identify where barriers might lie with your mechanic is a combination of user research, guidelines, and expert advice.

There’s never an point at which this is too early, all can start before a line of code is written, e.g. expert review on similar competitor products, co-creation workshop with gamers based on your early concepts and past games, familiarisation with guidelines before you even start thinking about ideas, etc. Speaking with the audience doesn’t have to be difficult or time consuming, even just a quick tweet can reap huge rewards. 

But realistically, making use of all of or even any of these three tools is not always possible for everyone, for all kinds of reasons. So the rest of this piece isn’t going to focus on those, and instead will look at what you can do by yourself.

So in lieu of (and in addition to!) those three, a good starting point is to set aside a little time in the early stages of development to think about the following high level groups, and what barriers your game might present to them. 

Even just a few minutes spent thinking about each will make a difference to how many people will be able to have an enjoyable experience with your game. 

Or if you have a bit more time to think in a bit more detail, here are some simple breakdowns of each. These are not complete breakdowns, but they should be enough to get some thoughts going without becoming too overwhelming.

Vision
Ability to see/distinguish things that are small, low contrast, differentiated by hue, or ability to see at all. 

Hearing
Partial or complete general level of hearing loss (in one or both ears) ability to hear specific frequencies, or distinguishing multiple different sounds at the same time.

Cognition
Ability to take in information (including recall from memory), figure out what it means and what action to take as a result, handle multiple and frequent sources of information, and manage intense sensory load.

Motor
Reach, strength, stamina, timing, and frequency and complexity of inputs.

Speech
This doesn’t often come up, the main scenario is partially or fully impaired ability to communicate vocally in multiplayer comms.

Sometimes these barriers can be avoided by design. When they can't, the solutions to barriers relating to all of these usually boil down to two core things:

Setting some time aside to think about these groups should allow you to identify some game-specific issues and game-specific solutions to them, either by design or through options. And while it’s important to recognise that your familiarity with the game will make certain barriers invisible to you (another reason why UR matters), knowing the game better than anyone else can still be useful - even without much accessibility experience you should still have some kind of a feel for which would be the most game breaking barriers. 

Quick wins

Amongst those solutions you should find some quick wins. Time & money needed for implementation is an entirely valid reason to prioritise. www.gameaccessibilityguidelines.com takes it into account, the categorisation there is based on an equal weighting of how many people a feature benefits, disabled or otherwise; how much of a difference it makes to the people who need it the most; and time/money to implement it.

Three other low effort ways to identify quick wins are to look at the individual variables that your difficulty presets affect, Look at the individual variables that you tweak while balancing, and look at the options that you implement for your own benefit while debugging. Consider exposing these existing variables to players. 

Every option you can present in a game has some accessibility benefit to someone somewhere. So if it’s easy for you to implement something, it’s generally worth doing. But when doing so, pay attention to usability of settings menus, as complex menus are an accessibility barrier in themselves. Presets and nesting are great tools for mitigating this.

Breaking your mechanic

In the process of figuring out which accessibility considerations to focus your attention on you’ll identify barriers that can’t be avoided without breaking what gives the experience value. This is 100% fine, part and parcel of how game accessibility works. No game can be accessible to everyone, challenge is part of the definition of what a game is, and any challenge will be an impassable barrier to someone. 

Accessibility is a process of identifying which of the wide array of barriers your game presents are in fact unnecessary, and rather than supporting the kind of emotional experience you want your players to have are in fact getting in the way of them experiencing it. So rather than viewing accessibility as a universal bar to hit or miss, think of it as optimisation. Regardless of whether you’re optimising frame rate, network lag or how many players can have the experience you want them to, every bit of optimisation has value, regardless of how much or how little optimisation it is possible for you to do. 

Legal issues

Just a brief mention here as it’s a long topic that needs its own dedicated article to explain - CVAA legislation. The short version is that any game that has text or voice chat functionality and can be played by players in the USA must by law ensure that the chat functionality and any UI/info used to locate, navigate to or operate is accessible. This will inform your priorities, and not just in the obvious direct way of prioritising what's needed for compliance - if you’re putting functionality in place for CVAA compliance anyway, applying that functionality to other areas of the game may then become a quick win and so move higher up your backlog.

Demographics

This one is a bit of a break from the others - something to avoid. It can be really tempting to look at demographics for prioritisation purposes, questions like “but how many people actually have [insert impairment here]?” are common across the industry. But I can’t stress this highly enough, demographics are not a valid means of prioritising, as considerations generally have much bigger use than the core demographic. 

For example around 2% of the population are deaf, prioritising based on that would mean that many games wouldn’t have subtitles. But 60% of Assassins Creed Origins players turned on the off-by-default subtitles, and 95% of Assassins Creed Odyssey players left the on-by-default subtitles turned on.

Prevalence of having one hand is around 1% of the population, yet Uncharted 4’s one handed mode was used by 33% of their players.

There isn’t any data available on how many people are physically unable to operate a gyroscope, but it would not be large - yet Into The Dead’s non-gyro alternative input methods were used by 75% of their players. 

It is not hard to picture the reasons why the above numbers might be the case. It is rare to find an accessibility consideration that doesn’t have wide impact like this, more often it’s just good design that benefits everyone.

In closing

While approaching accessibility can be daunting, especially for the first time, there are some easy ways in. Some sensible general things to start with. Core considerations that are widely used, easy to implement, and that match your mechanic well, and some simple ways to start figuring game-specific solutions even if you don’t have access to experts or user research or time to familiarise with big sets of guidelines.

The most important thing though is just to do something. As mentioned a couple of times already every little thing you can do simply means more people will have a more enjoyable experience, and you’ll learn a ton from it too - gaining knowledge, player feedback, experience and an existing accessibility featureset to take forward and build upon for your subsequent games.

Credits:

Republished from ian-hamilton.com/blog. Shared publicly with permission from and thanks to Alex Paschall