Abstract
This work covers general guidelines and methods to make a product more accessible and explains what benefits and costs are associated with it. A recommended approach for varying team sizes is also included.
In addition to the previously stated content, will this work also includes a list of specific features, and how they could be implemented, that will help to make a project more accessible.
Subject descriptions:
Design; System Design; Game Design; Accessibility;
General Terms:
Game; Design; Accessibility;
Keywords:
Game Design; Accessibility; Development Tools;
Publication Date:
01.02.2023
Introduction
Adding accessibility describes the act of adding handles/options or streamlining existing procedures with the goal of making something easier to use, be it by offering a simpler approach for everyone or a new handle that is required by a specific group of users.
Adding accessibility to a project usually comes with the objective of making it easier to use for a larger group of potential customers or users. Be it because a previously difficult interaction has now been eased out or because a new option allows someone who was previously unable to interact with the product to now do so.
It is important to note that during the last few years, many additions that have been included for accessibility reasons have now become the standard because they make a product better for every user. Examples of this would be colour blindness considerations just for general readability and extended options like screen shake toggles or alternative input patterns.
In general accessibility additions will either be a foundational change to how something in the project is handled in general or a toggleable option within the menu.
Reasons for making a product more accessible
Ignoring the obvious fact, that is nice and probably simply the correct thing to strive for a world that allows more people to properly interact with everything and each other, adding more accessibility options will have benefits for the organisation doing so.
~10% of humanity suffers from some form of colourblindness and allowing these people to interact with your product can add them to your potential target audience. All in all, it is not unreasonable to expect an ~25% increase in your potential target audience by having a good selection of accessibility options.
Additionally, many general product improvements can be found by investing in accessibility research allowing the overall quality of products to increase, if your team is the first to figure something out your product will also be the first that features the improvements.
Reasons not to add accessibility options
In general, the inclusion of accessibility features should be considered an overall improvement to the project or it should be placed behind a toggleable option. Because of this adding accessibility options should never be a bad thing for a project.
However, including them costs a lot of development time and a team needs to be aware that adding to accessibility will come at the cost of other gameplay features, this cost is also not to be understated even using already established methods will require a lot of testing with the target audience the feature is intended for since this is the only way for the team to confirm that the feature is functional. Establishing new accessibility features will require extensive research so the team properly understands the conditions that should be resolved by them.
Many accessibility features also require specific technical setups, it is not uncommon that an accessibility feature can’t be implemented because of some initially selected render settings or because the engine backend did not expect a specific input/output. Because of that more extensive accessibility options will need to be planned from the very start of the project which can make it difficult since the team is usually just figuring out what the project itself wants to be.
It’s also important to understand that not every product needs to be accessible to every user. If the product is about representing the beauty of colour accessibility options for blind people will probably be wasted efforts. Think about what your potential target audience looks like and add accessibility options to fit their needs.
This last section is a more personal opinion: While adding to accessibility is a worthwhile investment creating a bad product because accessibility options have consumed the time that would have been required to make it better helps nobody. Try to prioritize delivering a good product and add accessibility on top of it, based on this definition accessibility should always be considered important but never be in the way of relevant features for the product’s overall quality.
Recommended approach for adding accessibility
Rather than considering accessibility options something that should completely be included in the current project, add a selection but create them in the form of easily portable plugins, this will allow the creation of a larger option set with every passing project.
Think of 1/2 more complex options (like screen readers or visualized audio cues) at the start of a project and a hand full that can be easily added (like god mode or infinite resources) at the end of a project create if possible portable versions of these features and carry them over to the next project. Within the next 10 years, a good set of options will exist and it can even be shared with other teams.
For smaller teams, this can be done as described and is just part of the usual development cycle. For larger teams, it might be beneficial to have a group of people just focusing on accessibility this allows for a constant stream of new features during the development of a product that could even be used for multiple projects at the same time.
Additional Reading
https://gameaccessibilityguidelines.com/
https://design-system.service.gov.uk/community/accessibility-strategy/
https://www.playstation.com/en-us/games/the-last-of-us-part-ii/accessibility/
https://learn.microsoft.com/en-us/gaming/accessibility/xbox-accessibility-guidelines/123
