An Interview with the Team Behind the Gamer Accessibility Guidelines – Part I

Sometime last fall, I had the opportunity to interview some of the team members behind the Gamer Accessibility Guidelines. The website for the guidelines describes them as:

A collaborative effort between a group of studios, specialists and academics, to produce a straightforward developer friendly reference for ways to avoid unnecessarily excluding players, and ensure that games are just as fun for as wide a range of people as possible.
When I first revamped Gamerrazzi, to make it completely about inclusion for all gamers, and we started posting a lot more about gamer accessibility, the online Gaming Accessibility became an invaluable website, for me. This website is located here: http://gameaccessibilityguidelines.com/.

Reaching out to Ian Hamilton put me in touch with some of the other team members. I wanted to know, who these people are, why they wanted to be involved, in making games more accessible, and how we could get their website to more game developers, studios, coders, etc. The best way, in my opinion, is to make people aware of who the team is, what their mission is, with the Gamer Accessibility Guidelines, and what the guidelines actually say.

Given that this was an extremely comprehensive interview, I have divided it into two parts.

First, let’s meet the cast of characters. These are just some of the team members who are behind the Guidelines. Here is a bit about each of them!

Ian Hamilton
I’m an accessibility specialist, working on advocacy and awareness raising initiatives, across several industries, but most of my focus is on gaming. My background is in design for games and web, including six years at the BBC, which is where I became interested in accessibility. I eventually ended up kicking off my own accessibility projects, and working on internal best practice guidelines, and other work such as educating and advising internal and external developers on game accessibility. I now do the same kind of things, but in the wider industry.

Barrie Ellis
I run the website OneSwitch which deals in assistive technology for switch users, as well as promoting game accessibility solutions from far and wide. From this, I was approached also to work for the amazing charity www.SpecialEffect.org.uk, where I’m their technical specialist. I’ve been working in the field of assistive technology since the mid-1990s, and have ever since frequently come up against the limits of my knowledge and ability. What the internet and passionate people have done for game accessibility and making the world a slightly fairer place has been wonderful to be a part of.

Brynley Gibson
I’m Brynley Gibson, an Executive Producer at SCEE [Sony Computer Entertainment Europe] London Studio in Soho. At the time of the Accessibility Guidelines, I was the Executive Producer at Headstrong Games and worked with lots of the team there to provide our contribution and feedback to the guidelines.

Gareth Ford-Williams
I’m Gareth Ford Williams. My title is the Head of Accessibility for BBC Future Media, and I established and manage the BBC Future Media’s Accessibility Team. We work across the entirety of the BBC’s digital portfolio on Web, IPTV, and Mobile platforms. This includes the development of our Standards and Guidelines, as well as techniques libraries, QA frameworks, tools, and resources. We also consult directly on key products such as, BBC iPlayer, YouView, and the BBC Olympics offering.

Thomas Westin
I’m a PhD student writing my thesis about inclusion in digital culture, such as accessibility in computer games. I am co-chair of the IGDA Game Accessibility SIG, and I have developed games for e.g. blind and sighted. I also teach students in game engine development, game prototyping, and of course game accessibility. Several of my students have written their bachelor theses about game accessibility.

After learning about the initial team, I thought it was important to delve a bit deeper into their background, to better understand why they wanted to become a part of the team developing the Accessibility Guidelines. In their own words, they all shared how their backgrounds and life experiences helped them to want to become involved in this in depth, ongoing project.

Ian: I already had a background in guidelines development from the BBC, including for games, which I worked with Gareth on. So when I started trying to raise awareness in the wider industry, through conference talks and the like, and kept being asked for a comprehensive developer resource, it was a logical next step. As I already had experience of both how to (and how not to) produce guidelines, and also how game developers respond to them, it seemed like a sensible way for me to be able to contribute to the wider game accessibility effort.

Barrie: At the very beginning of running OneSwitch, I was introduced to the IGDA’s Game Accessibility Special Interest Group. It was here that I learnt of their White Paper for Game Accessibility, and worked with them in 2005-ish on their Top 10 Game Accessibility list. I’ve been keen to support such endeavours ever since, as so many games could be massively improved accessibility-wise with fairly minor tweaks. There’s definitely a limit to what you can do with custom hardware.

Brynley: In everyday life we have seen a positive increase in aids to accessibility, and it seemed right that games should go the same way. When Ian explained what he was trying to achieve I wanted to help, and I was in a position to do so. It is good to be supporting something within games that is clearly progressive, as so often, as an industry, we are saddled with so much negative press in the mainstream media.

Gareth: I had the pleasure of working with Ian when he was a Designer and Accessibility Champion for BBC Childrens. Ian has collaborated with the Accessibility Team on many occasions, and this just felt like a natural extension to that relationship.

Thomas: When I was invited to join this team I didn’t hesitate a second, as game accessibility is part of my research interest.

Knowing about their background, and how they got involved in being a part of the team behind the Gamer Accessibility Guidelines, made me wonder if any of them have personal connections to disability. Do they have family or friends with disabilities, do they themselves have disabilities, or did they garner an interest in accessibility for games in some other way?

I was surprised to learn only Gareth and Brynley had a personal connection to disability, with Gareth having a son with CP, and Brynley having a minor disability, himself. While Ian and Thomas have family or friends with disabilities, that did not factor into their interest in gaming accessibility.

In their own words:

Ian: I do have an immediate family member who has cerebral palsy, but that wasn’t actually a factor, at all. The thing that first got me interested was seeing games for preschoolers that had been adapted for switch access, i.e. could be controlled by just one or two keypresses, which then mapped to devices such as a button on a wheelchair headrest, or a sip-puff tube. These were kids who just a generation or two ago wouldn’t have been able to do anything independently, but were now laughing and playing, doing what kids were supposed to do, doing what all of their classmates were doing. So that was pretty mind-blowing, and I immediately started working on similar projects, myself.

Then, as my career progressed, I ended up overseeing many games, and kept seeing the same mistakes being made over and over again, huge swathes of potential audience [members] being lost over trivial decisions on things like colour and contrast. That’s what really made me aware that something had to be done. So my interest in accessibility is simply because it is important – important to the quality of life of people who rely on it, and important to the bottom lines of companies who implement it.

Barrie: [My interest] started around 1994, when I started working in a Day Centre that had a small range of assistive tech, including cause and effect/basic games running on a BBC Micro, which is a machine I learnt how to programme when I was back at school. It was really seeing the enjoyment people got from having control, who normally had so little.

Brynley: Personally, I have a minor disability in that I am colourblind and every game I have worked on I have made sure gets adjusted, so I can clearly see what is going on. Making only minor adjustments, especially on GUI’s, made a huge difference for me and I hope those little tweaks made the games enjoyable for other colourblind players out there, without them ever knowing it was done.

At Headstrong, one of the lead designers is profoundly deaf, and the request for contribution sparked some interesting discussions on disability between us. On discussing his views, it [be]came apparent that as a deaf developer he didn’t, in the past, cry for support for deaf players, as he didn’t want to be seen as the one guy pushing that angle, which is understandable, although now it is something he feels much more confident about driving.

Gareth: Gaming was my introduction to digital accessibility. My son has Cerebral Palsy and by age 5 he started to want to play games on sites like Cbeebies. This got me interested in switch gaming and then accessibility in a wider context. I’ve never looked back.

Thomas: I have a friend with Asperger’s, but that is not the reason I got involved. My interest came from being interested in game development since the early 80s, which later made me interested in interface design. In 1997, when I helped out in a project for stroke patients, at Karolinska Hospital (Sweden), by making a virtual reality simulation with biofeedback, I became aware of accessibility.

In 1998, web accessibility was a hot topic, and I made a talking web solution, which could run directly in the browser. I then went on and made my first audio-only 3D game, as my bachelor exam project, in 1999. After that, I was hooked. I set up a team of five people, and from 2000-2003 we created a 3D-game called Terraformers, in our spare time, with solutions such as a Sonar and Sound compass. So, my interest initially came from a need to improve the situation for rehabilitation of stroke patients. I still find it intriguing to see all the innovative ways people use to interact with computers, and socialise in games. In the long run, my personal interest is to be able to play games when I grow old, or if I get hurt in an accident or sick.

One thing I love about the Accessibility Guidelines is how neatly organized they are. The fact that they offer practical examples of accessibility, so developers understand exactly what they need to do to make their games accessible, is brilliant! I wanted to know, from the team, how long it took to compile all of the examples. The guide is ongoing, as new game options become available, new opportunities to arise to improve the guide, but what is there, currently, is extensive. I was certain the process took a bit of time.

Ian: The guidelines themselves were produced over a couple of years, with the bulk of the work taking place over 2012, with various phases including core team work, reviewing with other studios and gamers with disabilities, and public post-launch feedback.

The best practice examples, shown as part of each guideline, are an ongoing process and one that we’re always grateful for help with, Robert Kingett for example contributed some great ones just a few weeks ago. So, if anyone reading knows of a good best practice example for a particular guideline that’s currently lacking one, please do get it touch!

Gareth: Just look at the people involved. Ian brought together an extraordinary team and they brought their expertise, which included the analysis of existing best practices. Just seeing the list of who was involved at the start of the project, I knew something special was going to happen.

Thomas: The guidelines I contributed with did not take very long to write, but they are based on practical, long term experience of developing accessible games.

Additionally, I wanted to know why the team decided to split accessibility up into Basic, Intermediate, and Advanced categories. I also wanted to know how they established what types of accessibility fit in which category…was it based on difficulty in implementation or monetary costs of implementation (or both)? The team was happy to answer these questions.

Ian: Splitting [accessibility] up into levels was one of the first decisions to be made. It differs from similar approaches in other industries, because they’re a way for devs to find information relevant to their level of interest, rather than compliance levels (which you can’t really have in games), and that’s really important; some people just have a casual interest and want some top level ideas of how they can help, some people need precise details on how to design for a specific niche audience. It also differs by including cost as a factor. I’ve seen so many times developers look at a list of guidelines, see one thing that doesn’t seem feasible, and write off the entire set of guidelines, as a result, so some kind of filtering is essential.

The details were inspired by the BBC’s commissioning process, which does an excellent job of evaluating their output on a balance of public service potential, and value for licence payers’ money. So what we ended up with from that was a balance of three things:

Reach – the number of people who benefit
Impact – the level of difference made to those people
Value – cost to implement
Evaluating against those three criteria gave us a basic set, which are of significant benefit to large numbers of people, and are easy to implement if considered early enough; an intermediate set which take a bit more effort, don’t benefit as many people, but are of great help to those that they do; and advanced, the tricky things that only benefit niche audiences, but make a really huge difference to those people.

Thomas: I think Ian explained this very well. I can just add that when I joined the team, the structure was already in place, and it made sense. Game developers are like any professionals, who need to meet deadlines and budgets. The difference is that games are not required, by law, to be accessible (which is often the case with public service web pages etc.). This means that game accessibility is a voluntary effort, unless, of course, the target group is so large that it is obvious that it has to be done. For instance, color blindness which Epic has built-in support for in Unreal 4, or left-handed keymappings, which is easy to do once you have a keymapping feature in the game. Another example is the closed-captioning support by Valve in Half-life 2 and all games after that, which came as a request of the large group of deaf Counter-Strike gamers.

So, yes it’s a balance between value rationales (what we value as important in culture e.g. inclusion) and goal rationales (what the market requires). However, the goal-rationale is what sets the framework of what value rationales can be done in practice.

From there, I wanted to know how inspired Ian and the rest of the group were by the Includification Guide by Able Gamers. I wondered if the information in that played a role in how the Accessibility Guidelines evolved. Able Gamers has been the ultimate authority, here in the states, for accessibility, but it seems that Ian and his team were working before, and even concurrently with the Able Gamers team. Ultimately, the more groups striving for accessibility in gaming, in my opinion, the better.

Ian: Not at all, as it didn’t exist yet – both actually launched within a couple of weeks of each other, in September 2012. The fact that we were both working on similar initiatives at similar times is a testament to the growing understanding and desire amongst developers.

However reviewing previous literature was an important part of the process, we were building upon great work done, over the years, by people and organisations such as Brannon Zahand, Eelke Folmer, and MediaLT, to name just a few. For anyone interested in history of guidelines, Sandra Uhling maintains a nice archive of historical documents at gameaccessibility.de.

Barrie: [The guide was] more so inspired by the SpecialEffect Wish List for Accessible Game Design in 2011: http://www.gamebase.info/magazine/read/wish-list-for-accessible-game-design_531.html.

Gareth: These guidelines are based on the accumulative expertise of the group involved and you’ll find that the individuals have been involved or influenced by other projects, and even each other, previous to being involved in developing these guidelines. Because of this, you will find other projects that have influenced this, but nothing previous to my knowledge has been this comprehensive. At the BBC, our past work has been influenced by the work of other members of this group, such as Barrie’s work on switch gaming.

Thomas: I agree with Ian’s reply. It should be added that there has been several other sets of guidelines, in the past, but there is always room for improvement of all heuristics. The greatest thing with the Game Accessibility Guidelines is how it evolves and improves, over time.

Further, in 2012 there was also a set of guidelines (best practices) published by CEAPAT in Spanish.

In 2013 there was a set of game access guidelines published for seniors:
http://gestion.ibv.org/productos/index.php?option=com_docman&task=doc_download&gid=435&Itemid=
Guidelines always have some overlap, but mostly they complement, by highlighting different aspects, or just by making the guidelines themselves accessible in different languages (such as Spanish or English).

So, the big question I had for them was, what can we, as consumers with disabilities, do to encourage the gaming industry to embrace the idea of gaming accessibility?

Ian: Keep the conversation going, in any way you can. I wouldn’t recommend taking official channels, i.e. talking to publishers. Instead, speak directly to the developers. Twitter is a great way, as are individual game forums. Compared to even five years ago those routes are far more friendly and welcoming for people with disabilities. Attitudes amongst other gamers have changed significantly. Get onto beta tests, respond to calls for playtesting participants, apply for jobs in testing. Write, try to get pieces in mainstream games media, or just mainstream media, in general. Anything, at all, that you can do to let developers know that you exist and you’re a potential customer that they’re missing out on.

If possible, go to them with easy fixes, rather than problems, but also be pragmatic. There are sometimes factors outside developers’ control (eg. technical restraints in engines) that prevent them from considering it, so if they say they can’t, just ask if they’ll consider it for their next game, instead.
Then, of course, if developers are doing it right, if they’ve made some consideration that makes a difference to you, tell them. Let them know how valuable and important it is. Ask them to make sure they keep including it in their future games.

Barrie: Ditto!

Brynley: If you are really engaged with a series then making contact with the community manager is a great way in. If a game is ongoing or a service, then they are tailoring it for their customers, so why not have them tailor it for you? They will if there are enough voices.

Gareth: All I can talk about here is the BBC’s own services, and the best thing you can do is give us feedback. If something doesn’t work for you, tell us what is either right or wrong, and we can then keep doing it, or learn from that feedback, and make improvements. The more information we get the better the work we can do in the future, so please give us detail.

Thomas: I think that making developers aware of the lack of game accessibility, combined with how many gamers are affected, is a good way to go. Case in point is when Valve became aware of the deaf gamers playing Counterstrike and had a hard time doing so. Then, when they made HL2 they implemented support for closed-captioning in the engine, so it could easily be added to all their games, after that. That is why I think engine developers and especially those who make tools for other developers (e.g. Unity, Epic/Unreal, CryTek) are the most important targets. If the engine has built-in support, the threshold for getting return on investment is lowered, and developers can more easily convince their publishers to do it.

The Gamer Accessibility Guidelines, won an FCC award, so I told them all “Congrats!” on th award. The FCC’s Accessibility and Innovation Initiative honored the team and the guidelines.

Ian: Thanks! It was obviously a nice landmark for accessibility in gaming, great to have games discussed equally as part of the wider accessibility effort, and of course anything at all that gets more people talking and thinking about it is always good.

But it was also nice for gaming in general. It’s certainly a good thing to have a government body publicly recognise the positive impact that games can have.

Gareth: It still hasn’t really sunk in yet.

Thomas: That was awesome news for game accessibility and for the great work of Ian and the team.

The FCC states that over 20% of gamers have disabilities. I wondered if Ian, et. al. thought that it is ignorance to this fact that prevents some of the AAA gaming developers from implementing accessibility options.

Ian: Yes. That figure comes from PopCap’s research. They discovered that prevalence amongst their audience was higher than in the general population (20% Vs 15%). And that 20% is only what classically comes under the self-identified disabled banner, it doesn’t include the really common things like colourblindness (8% of males) or difficulty reading (14% of USA/UK adults). So there’s a huge business case to answer, but often developers either have never thought about it at all, or incorrectly assume that people with disabilities account for less than 1% of the population.

Brynley: Absolutely! I think that is by far the biggest issue. Sure, there are financial concerns in doing what could be perceived as additional work. When one looks at some of the simple, but highly effective guideline implementations, and the possible market it could open up, you can start to make some of that effort make financial sense. We are a business, and if there is a clear business case for something, then on the whole, it is easier to achieve.

Gareth: These gamers need to get together and have a voice in the industry, not an aggressive lobbying one but one that can ask questions, build relationships, give advice, and help foster an understanding of the opportunities that an audience of this size offers.

Thomas: Yes, at least in part. As you know, disabilities are varied, and all individuals have different needs. Further, games are designed to be challenging in different ways (as opposed to other software). This makes the picture more complex. However, while the deliberate barriers of the game are essential for the game itself, there are often unnecessary barriers which should be removed. Achieving the basic set of guidelines is do-able for most games and dev teams, which is why the structure makes so much sense.

I wanted to know what each of them felt was the biggest/greatest challenge facing the concept of universal accessibility becoming a tenant of all future game development. Did they think it was possible the game industry would make it a requirement of, at least, the professional gaming industry?

Ian: Honestly, I don’t think it’s possible, no. The definition of ‘game’ requires there to be some kind of challenge, and that will inevitably exclude some people. However, it is entirely possible to avoid all of the other unnecessary barriers, and pretty much every game out there could be more accessible that it currently is.

There are some things that can be required, for example, Ubisoft require all of their studios to subtitle their games (a direct consequence of the complaints about lack of subtitles in Assassins Creed 1), but in general, what’s appropriate to consider varies from game to game.
Although you can’t just have something like web accessibility’s fixed compliance levels, there are proven methods of how industry bodies can encourage uptake. For example the GDAA’s accessibility category in their national industry awards, and Screen Australia and Film Victoria’s optional accessibility box in their funding applications, which resulted in 91% and 100% uptake respectively.

Barrie: I think it is possible, but we’d not all be playing the same game. See: http://www.gamasutra.com/view/feature/130260/the_theory_of_parallel_game_.php?print=1. If life is a game, you could say that everyone who is living is taking part in it/playing it, although not all of it is accessible to everyone. Realistically though, it’s going to be an extremely rare occurrence to pull this off, and far more desirable is simply for more developers to take the stance that reasonable adjustments to their games, led by the likes of the GAG, would make a real positive difference.

Brynley: Sadly, that feels a long way off, and talking about requirements seems even further off. It would be interesting to see what impact our trade bodies of TIGA and UKIE could have with a sustained effort, in this regard. It seems to come back to awareness, and highlighting the ease on which some of the guidelines can be implemented, and the possible market that you can attract my doing so.

Thomas: Not in the near future, but as commercial off-the-shelf games become used in public schools, the picture may change. I have been involved in two such projects (2002-2006 and 2010-2012), to make schools more inclusive for gamers, who had dropped out. While it worked very well, it could have been a serious issue if some of the pupils had a severe visual impairment. As public schools have to be inclusive, it may force, or be an incentive of game developers, for making their games more accessible. Just in Sweden, with 10 million people, we spend approx 90 million euro on school books alone each year. If game industry can take part of that, well…money talks, and regulations may be acceptable.

Speaking of professional versus indie development, I have found a lot of small indie developers extremely interested in developing their games, so they are more accessible. Whenever I find a lack of interest, it seems to be more geared towards the fact that these developers believe it will be quite expensive to make games accessible. I’ve consistently heard from developers that understand accessibility, that implementation is less expensive than most developers would think. I asked the group behind the guidelines to discuss a little bit about the financials behind implementation of accessible components.

Ian: Part of it is that the majority is just simple game design that benefits all players…Something that’s an impassable barrier for one person is still often an annoyance for other players. For example, a lack of remapping, or a map (Burnout Paradise, I’m looking at you) that is based solely on colour. So, developers reading through the guidelines for the first time, often have a bit of a nice surprise in that there are things that they’re doing already, just as general game design.

The other part of it is that cost is directly tied to the point at which it is first considered. One example I’ve seen was a studio who spent literally months trying to fix a control inaccessibility issue late in the process, unpicking, retrofitting, re-testing. The same consideration would have taken then a matter of days, had they thought about it from the start. Or another example, text…deciding at the start that you’re going to use decent contrast, 14pt, costs nothing. Deciding at the end to change from 10pt to 14pt, and adjust the colour palettes for decent contrast, can be highly (i.e. prohibitively) expensive.

If you can keep costs low, it can be a simple profitable business decision. Games are in a unique position to be able to gather the data to prove it, to demonstrate that these features are actually used, and are worth including. It’s a pretty trivial task to track how many of your payers turn on subtitles, colourblind mode, remap their controls, etc., and compare that against the cost to develop the feature.

Barrie: Some fixes, like giving players access to game parameters (with some kind of restriction for on-line play, such as friends-only play areas), could take next to no effort. Some may call it cheating (such as switching off damage to a car, or giving a player limitless stamina or lives), but is it really if all it does is turn a completely unplayable game into a playable one?

Gareth: There is a misconception that accessibility costs a fortune and this is not always about the delivery of guidelines, but on the mismanagement of the work that delivers those requirements. As soon as someone starts planning an accessibility sprint, they have already failed.

Accessibility implementation happens at sprint zero, and then continues throughout every subsequent sprint. For every feature, the team should be asking themselves, what are we designing/building, and how do we do it accessibly? This way, you avoid expensive, and often ineffective retrofitting, and code re-factoring. Plan this stuff properly, listen to feedback from gamers, and the cost is kept to a minimum. Leave this stuff to the last minute, and you’ll end up de-scoping it, due to cost.

Thomas: I have conducted some research about that with game producers, and we could confirm that ROI was possible for the basic guidelines, although we could not get statistical significance in the study. Other than that, as I said above, if engine devs implement solutions it may be easy enough for anyone to do it with almost no time/cost. That is also what happened in the W3C efforts for web accessibility; after some time focus shifted towards targeting Macromedia (remember Dreamweaver? Flash?) and Adobe (PDFs. etc) to have support for accessibility, built in. Still, of course, it’s up to the developer, using the tool, of being aware of why the alt-tag text must be used.

This concludes the first part of my interview with the team behind the Gamer Accessibility Guidelines. Stay tuned for part two, in the next day, or so! The second part of the interview gets a lot more up close and personal with the individual team members!

For now, check out the Gamer Accessibility Guidelines at http://gameaccessibilityguidelines.com/, and, as always, keep gaming!!