On the 12th of June, I had the opportunity to speak at the Freeplay Independent Games Festival on a couple of topics that are dear to me – game accessibility and the representation of disabled characters in games. The talk in question can be found here. Games are a common means for disabled people to socialise and have experiences that they otherwise would not be able to. As a person on the autism spectrum for whom games were a major part of my upbringing, it is important for me that disabled people can play games and that they feel respected and included in the process. As a web application developer I also work with accessibility on the Internet, where similar accessibility needs are addressed in a different context.

The accessibility component of my talk discussed the four most common accessibility complaints in games. These are text size in games, the presentation of subtitles, button remapping, and colour-blindness support. There is significant similarity between game and web development, however there are also substantial differences between both domains. This results in some significant differences between accessibility in both fields.

Web development has a recognised industry standard set of guidelines.

These are the Web Content Accessibility Guidelines 2 (WCAG) from the W3C which have been approved as an ISO standard. One benefit of this is that this means there are clear expectations regarding what features a website should have to make it accessible. There is currently not an industry standard for games accessibility, so what constitutes an accessible game is less defined. There are sets of guidelines for creating accessible games though, such as the Game Accessibility Guidelines and the Xbox Accessibility Guidelines. These sets of game accessibility guidelines have some minor differences (for example, they recommend different minimum text sizes) but they generally do make similar recommendations.

User interaction across different websites tends to be much more uniform than in games.

This is largely because the interaction is often a large part of the appeal in games, whereas in websites it is just a means of performing a task. Games often have complex user interactions by design, whereas good design in web development often emphasises usability and simplicity. This affects accessibility in a couple of ways.

Firstly, it means that the goals of accessibility are slightly different for both fields. The goal of making a website accessible is to make it as simple as possible for a disabled person to use it. In video games, the goal is to make it as simple as possible to interact with the game while preserving as much of the original experience as possible.

Secondly, this means that while the majority of accessibility guidelines for websites are applicable to all websites, some game accessibility guidelines may only apply to some games. For example, any guideline that applies to the usage of motion controls in a game won’t apply to any game that does not use them.

The format of websites is very standardised.

No matter what framework or toolset you’re using to make a website, the output result will consist of HTML, CSS, and potentially some scripts in languages such as JavaScript or PHP. This means that it is possible to create programs that can perform tasks such as auditing web page accessibility (e.g Google Lighthouse) and text to speech for websites. There are games that contain text to speech functionality (such as The Last of Us Part 2), but these games have implementations of text to speech built into the game itself. There are some accessibility plugins for games (such as this UI plugin for the engine Unity) but they are generally engine specific and need to be integrated into the game by the developers, whereas tools like Google Lighthouse can be run on any website. There are also some engines such as the interactive fiction engine Twine that compile games to HTML, games made in these engines can be used with tools such as Lighthouse but these are an edge case.

The last major difference is that there is a much stronger legal mandate for making websites accessible than there is for games.

Quick disclaimer that I am not a lawyer and any information in this paragraph and the rest of this post does not constitute legal advice. In New Zealand, any website for a public or non-public service agency must legally meet the New Zealand Government Web Accessibility Guidelines, these are derived from the WCAG 2.0. While there hasn’t been any instance of this in New Zealand yet, there has been cases in countries such as Australia and the USA where companies have been taken to court over breaching discrimination laws because their websites were inaccessible. Laws relating to game accessibility generally only affect certain components of games, the most notable example being the American 21st Century Communications and Video Accessibility Act (CVAA) which governs the accessibility of any technology with communication functionality such as text, voice, or video chat. Chat functionality and any menus related to chat in a game by American law has to be accessible to disabled players, any feature in a game that is not related to chat functionality is not subject to this act.

As mentioned earlier, there are substantial differences between accessibility for websites and for games despite both domains being software. Some of the reasons for this are due to differences between both fields. This includes the emphasis on interaction in video games as well as how the format for websites is much more standardised than games. Another part of it is that accessibility is not as entrenched in the games industry as it is in web development, though games are fortunately making progress in this area. Accessibility is important because we should be trying to allow as many people as possible use the software that we create. It is also a field that can vary significantly based on the specifications of what we are creating, it is therefore important to consider the purpose of the project when deciding how to make it more accessible.