What Is Video Game Accessibility Consulting?

So, if you’ve been following my social media presence the past few weeks, you’re probably aware that I’ve appeared in the credits of a few recent video games for work that I’ve done as a consultant. Specifically, I appeared in the credits of Life is Strange: Double Exposure last month for work that I did on that game as an accessibility consultant, and I’ll soon appear in the credits of the queer PlayStation 1 Silent Hill inspired game Sorry, We’re Closed.

However, I’m aware that the world of video game consultancy is something that not a lot of people have first hand familiarity with. Recent trends online have painted video game consultants as some all powerful shadowy secret society forcing game developers to change their games against their will, something that couldn’t be further from the reality of what the job actually entails.

So today, I wanted to take some time to talk about what accessibility consulting in the video game industry is in practice.

This won’t be a robust list that covers every possible form that accessibility consulting might take, but it will discuss a number of forms that it has taken for me over the past few years, and what its purpose in a game development pipeline actually is.

So, what do I do?

At its most basic, accessibility consulting is work that I do as an outside freelance contributor, helping game developers, publishers, and studios to understand how they can make their games more playable by a wide range of disabled gamers.

The work is partially about giving a game developer a list of accessibility features and design ideas to try implementing in their games, but it’s also about offering advice on how to implement certain features, how to prioritise which features to add, and identifying which features might offer the most support for the least amount of additional work output for some easy accessibility wins on a particular project.

It’s not about mandating what a game is or will be. Developers come to me and other accessibility consultants because they have a game design idea in mind, and they already know that they want that game to be more accessible. I’m not forcing accessibility onto these developers, simply helping them work out what is achievable, how much more work ambitious additions might be, and getting those developers excited to tackle some of those challenges.

It’s about helping to make sure that developers are implementing things in ways that mirror best practices, or connecting them with impacted individuals for more specific tailored advice, or helping them to see new ways to approach removing known accessibility barriers.

Are you talking about specific projects?

To be clear, while there’s a small handful of games that I have recently announced being involved in as a credited accessibility consultant, they’re a tiny sample of the projects that I’ve worked on over the past 4-5 years. Some of the projects I worked on over the past few years are out now and I simply wasn’t credited on, others are still in development and will be credited in the future when they release. These examples are from a wide range of different projects undertaken during the past five or so years, and should not be assumed to be representative of my experience on any one specific project that you might know I worked on, or any project that I announce having worked on in the upcoming months. Most of my experience is still behind closed doors, and nothing in this talk is uniquely specific to any one project.

Additionally, this isn’t a discussion of the process behind any of the other kinds of consulting work I do. I consult in a wide range of capacities when it comes to video games, this is very specific to my accessibility work.

When in development does accessibility consulting happen?

The simple answer is… it varies. Ideally, accessibility consulting on a game project starts early in development, with follow up sessions as a game moves forward. This isn’t always the case, but consulting will have different strengths and aims at different points in a game’s development cycle.

To talk in vague terms around a recent indie game project – An indie game developer came to me recently with their project very early in development. They had design documents available to showcase their plans for the game, and a very basic prototype demo they had been using to pitch the concept to publishers and media funds. The prototype was far enough along for me to experience a number of early mechanics, and some of the tutorial flow of the game, but not much further into development than that.

Sometimes games will be presented to me even earlier in development, when they still only exist as a series of planning documents with diagrams for expected features.

I played through this developer’s demo several times, read through their accompanying documentation, and made extensive notes before our first video call. I workshopped a list of groups of disabled players who would be most likely to experience barriers when playing the game, and made lists of varied approaches the developer might test as solutions for the unique barriers their design presented.

I did not mandate a single correct solution to any of the novel or unique barriers in this game, but brought options and mockups to that meeting. The developer is the expert on what’s going to be most manageable to implement for them and the engine they’re developing using. My role was to get ideas out on the table, present their pros and cons for the user, and get ideas presented that the developer could quickly start testing while still at the prototyping phase.

We then made an agreement to cycle back on the project every few months during development for another pass, to see how implemented solutions were working in practice, and if any new issues had arisen during the development process.

However, this isn’t the only form that early consultation with a studio might take. It might also look like studio training sessions. These might take the form of something like a workshop designed to teach basic accessibility principles and existing best practices, alongside getting members of a development team to practise identifying accessibility barriers, suggesting solutions, prioritising severity of barriers, assessing the work needed to implement a solution, and gauging who on a team has capacity to take on that work.

Lots of development teams feel like they’re too swamped with existing work to add accessibility features or consider accessible design in their workflow. In those cases, my job is to try and get things to the point where everyone on a team understands what accessibility is and why on a human level it’s important, but more importantly than that it’s getting them used to spotting easy to implement accessibility wins, or better yet getting them excited about a feature they may feel some conceptual ownership of and might want to fight to make space to include.

Sometimes accessibility consulting takes place a little later in development, when a game has already taken shape a little more. This work tends to be a bit more practical. It often means playing a lengthier or more fleshed out demo for a game, and taking notes as I play. Sometimes it means giving feedback in real time via a video call or local recording where I talk about barriers that I’m experiencing while I’m in the process of playing.

The benefit of accessibility consulting at this stage in development is that it often allows a consultant to address issues that may not have been foreseeable when the game was still at the design document and prototype stage, either due to shifting design elements or practical implementation.

When I meet with a client early in development, I talk about what in theory they should be working on. When the build is further into development, maybe even one where some of the accessibility features are starting to be implemented, I have more of an ability to talk about things that they didn’t plan on being parts of the game during that early stage design, or to talk about features that on paper are good but aren’t working correctly in practice in their game.

Let’s say, for example, a game with first person gun gameplay stated in its design documentation plans for an aim assist feature. On paper that’s perfect, something they should definitely be doing. However, if I consult on a build where that aim assist feature has been added to the game, but was added in a way that either feels clunky to use, or fails to achieve its aim of helping a player with a mobility or coordination disability to aim with greater ease, then the feature needs reworking. I can better advise on this kind of thing when it’s in place in the game rather than a theoretical feature on paper that they know is important to have.

Doing consulting at this stage in development does have negatives compared to consulting early on a project, certain accessibility features for example require tagging game elements and are more easily handled at the start of development rather than a later retrofit, but when you pair accessibility consuntiling at this point in development with early consultation that can provide a best of both world situation.

Lastly, there’s accessibility consulting that takes place as launch is approaching, or even post launch. This tends to be focused on finding last minute, high priority issues that will either be hard progression barriers for groups of players that you’d aimed to support, or issues that might pose serious risks or complaints if unaddressed.

Did you overlook a potential photosensitivity trigger that might cause players to become ill?

Did your content warnings system fail to correctly activate in one instance of a trigger that you promised players they would have warnings for?

Is there a bug that’s likely to cause severe motion sickness issues if unaddressed?

Did you promise playability for a specific group of disabled players but your execution isn’t going to deliver?

This late in the day accessibility consulting work allows last minute fixes to be prioritised correctly, or properly messaged around. It’s often there to help identify which issues need to be sorted before launch day, and which would be great additions but could perhaps wait until a post launch patch if necessary.

How much sway do accessibility consultants have?

Generally, accessibility consultants have less sway than you might imagine. There are obvious exceptions, projects where you’re treated as a specialist and your word is treated as gospel, but generally speaking that isn’t the case.

Not everything we advise for a game will be implemented. It’s not something I can give firm examples of due to Non Disclosure Agrements, but I can broadly say that there are times where an accessibility consultant will push for a feature, and it simply won’t get implemented due to budget or time constraints. Sometimes a feature will even get the greenlight, and then get cut down the line regardless.

If a game isn’t accessible for you, chances are it’s not the fault of accessibility consultants. If we had our way, every new video game would be playable by every variety of disabled gamer possible. Our input however typically ends at giving advice – Just because we dream of a fully accessible world doesn’t mean we can translate that into tangible results on every project.

What other reasons are you brought in as an accessibility consultant?

Accessibility consultants are sometimes brought onto projects for less ideal reasons.

Sometimes we’re brought on simply to be a box ticking exercise so a developer can say they tried, and dodge critique.

Sometimes we’re brought on explicitly to help a studio decide what accessibility plans they’re “allowed” to cut for being “less important”. This is unfortunately common, being brought in basically to be the disabled person giving a dev team permission to leave certain disabled players’ needs by the wayside.

It’s never fun having to tell a developer that a feature that you’d find really beneficial, but is solving soft access barriers rather than hard access barriers, is a lower priority to keep on a project. Being brought on to act as the one giving permission to cut features that would act as wonderful support for me is never a fun day in the office.

Is this work done solo, or as part of a team?

Sometimes this work is done solo – I’m reached out to by a developer or studio for either my personal input on the disabilities that I have, or for a broad education on the basics.

Sometimes this looks like a panel discussion, multiple accessibility specialists with different needs brought in to share differing perspectives as part of a discussion with the development team.

Sometimes it’s working through a company that finds projects, such as the work I do via EasySurf, where the company finds projects and pairs them with accessibility specialists who fit the demographics needed. This work is often done solo, but sent to the client as part of a package of experiences and accompanying assessments and reports.

And sometimes it’s visiting a studio in person alongside other disabled critics, and those joining remotely via streaming gameplay tools, to discuss feedback over a couple of days of observed gameplay and intermittent developer discussions.

While this is far from all encompassing, My hope is that this overview might give you a slightly clearer picture of what it means when you hear that someone has worked as an accessibility consultant on a game project.

It’s generally an external specialist or team of specialists brought in by a developer who has already decided they want their game to be playable by a wider range of disabled gamers, and wants advice to either help them pick a good starting direction, course correct execution mid development, or avoid major issues at the final hurdle of a project approaching launch.

We’re a group of people who love video games as an art form, and whose only wish for the game industry is that we ourselves can enjoy playing more games, and make them playable for a wider number of others.

We love games, it’s only natural we would want as many people as possible to be able to play them too. We’re here making sure as many people can love this hobby as possible. At the end of the day, we’re just here to try and make games as fun to play as possible for ourselves and others.