Honours Project: Accessibility in 2020-2021.
Promotional video showcasing some features of the prototype.
Project Overview and Justification:
The focus of the project+disseration is not to create a complete taxonomy of inclusive design since there is no consensus about the universal rule of inclusive and accessible design but rather an exploration of software-based solution baked in the game prototype rather than through third-party solution.
The development of accessibility features is supported by an extensive literature review and case studies of games with notable accessibility features.
Aim and research question:
My overall aim is to improve and gain knowledge on accessibility and its design.
To achieve this, my research question is, “what accessibility features should a game have in 2020-2021?”
Literature
The literature selected for this dissertation is based on the Zotero list available through the website of the International Game Development Association – Game Accessibility Special Interest Group (GASIG 2019). The list of literature made available from this association covers each area of impairment in detail, with each area having multiple peer-reviewed papers, with an extensive look at Accessibility in general with papers focused around quantitative data, while others are focused on qualitative data.
Although they are four different areas, the accessibility options developed for one area might benefit other areas.
Related practical research:
Case studies on accessibility features found in:
-
Metro Exodus
-
Celeste
-
Gears 5
-
The Last Of Us Part II
-
Far Cry New Dawn
-
Overland
Pictures of the project's map, options and accessibility features
Area of work:
The project had four main areas to develop accessibility option for:
-
Cognitive
-
Hear
-
Visual
-
Motor
The tab below list every accessibility feature developed for the project. Click on an area's arrow to learn more about the accessibility features of that area.
Cognitive
-
Dyslexic-friendly font
-
Auto-solve puzzle
-
Control Scheme viewer anytime
-
Re-read instructions
-
Objective reminder
Visual
-
Scan vision (High contrast)
-
Colour-blind facilitator
-
Screen reader support for UI
-
Lock Z axis for mouse
Hear
-
Subtitles
-
Colour for subtitles
-
Speaker's name
-
Dynamic box
-
Directional sound indicators
-
Tinnitus friendly mode
Motor
-
key rebind
-
Sensitivity slider
-
Double the sensitivity
-
QTE more time
-
QTE disable
-
Controller support
Cognitive features:
Dyslexic-friendly option:
The font chosen to address the accessibility of people with reading impairments is called OpenDyslexic.
The reason why I chose the font OpenDyslexic are two, the first is that it is under the SIL-OFL license, which means that it is free to use for personal, educational and commercial project; the second is that from the literature review that I did, there was no unified consensus on what font was the best to use to help dyslexic users.
According to the British Dyslexia Association, there is no consensus on a single optimal font to use, but the guidelines are to "use sans serif fonts", which are neither helpful nor clear.
Due to this, I decided to look at fonts made for people suffering from dyslexia and what fonts they use and prefer. OpenDyslexic was the most cited and the most rated, hence I decided to go with it.
Auto-solve Puzzle:
As outlined from the literature review, some players with cognitive impairment might need to have the option to skip puzzle due to their inability to solve it.
The option to automatically solve the puzzle implies the existence of a puzzle, hence the need to create both the puzzle and the option to automatically pass the puzzle rose during the development of the project.
The auto-solve puzzle is made out of four components: the puzzle model, the puzzle widget, the key-cards and the puzzle auto-solve option in the option menu.
Control Scheme viewer anytime:
As mentioned in the previous pages, cognitive impairment can directly impact both short-and long-term memory.
A player should be able to return to a game after weeks or even longer periods without feeling the need to restart the game because the controls and their functions are not remembered. With this feature, the player can simply pause the game and click on the help button to reread the game's control scheme.
The ability to read once again the instructions is needed in a game to be considered accessible for the aforementioned reason
Re-read instructions:
The same concept of the control scheme viewer applies to the instructions given to the player during the start of the game. For this reason, on the same page as the control scheme viewer, it is possible to read the basic instructions of the game once again, such as “collect keys to complete the puzzle”. There are two ways to reach the page with the reminder. One is through the cognitive page in the options menu and the other by pausing the game and pressing the HELP button.
Objective reminder:
Players suffering from cognitive impairments have problem with keeping track of tasks in both the long term and short term due to the way that the cognitive impairment can interfere with memory.
Given the fact that with each “stand”, there is a new objective almost every 5 to 10 second, the need to have a constant reminder for the player is needed.
The objective reminder function is on by default, and it is based not on the short-term goals (which are the various showcases of how a certain accessibility feature works and how to activate it), but on the long-term goals, which are to explore each pavilion until each, and everyone is explored.
Visual features:
Scan vision (or High contrast mode):
To help those that are legally blind or have degraded eyesight, a high contrast mode is needed. There are two approaches to tackle this issue:
1. Create a shader and have it activate in runtime.
2. Have different models and texture that are swapped, causing a refresh of the game.
The outline system that I created in the first semester is fine, but due to the nature of the project, it might be a little too subtle and hard to notice for people with vision impairments. So, I decided to create a new system to highlight objects.
.The old system technically was a material that highlighted the vertex on the edge of a mesh.
The new system is still a material applied on the custom depth render, but it highlights the object completely, with a little transparency to let some details in.
It can show up to four different colours, which are modifiable by the developer
Colour-blind options:
People with colour deficiency might find some puzzle and the user interface inaccessible due to their difficulty in distinguishing colour.
To solve this, I put three options to correct the most common colour deficiency. This correction applies to both the UI and some elements of the game itself.
Deuteranope corrects the inability to see green and shades of green. Protanope corrects the inability to see red and shades of red. Tritanope corrects the inability to see blue and shades of blue.
Lock Z-axis:
The ability to use the mouse to look up and down can be detrimental to those who suffer from visual impairments, making it difficult to orient and understand the position of the player’s character for the player.
To remedy this, I developed the option to disable the input received from the mouse along the Z-axis, making the mouse move the camera only horizontally, ignoring the vertical input.
Screen reader support:
All the widgets for the UI have been created with native support for screen reader. To activate this feature, a tick had to be activated in each widget.
Hear features:
Subtitles:
At the end of the development of all of these features(speaker's name, box and colours), the subtitle function works as intended, with the ability to resume If the player stops the collision with the area in which the subtitles are playing.
It is also extremely modular and can be re-used through the level as many time as the developer wishes.
The ability to activate the outline box helps with those that suffer from low vision or for when the background has the same colour of the text.
The ability to change the colour of the subtitles, as well as read the name of the speaker helps to understand better the context and make sense of what is happening.
The texts in the subtitles function are supported by the Dyslexic-friendly font, meaning that every single text can have its font changed, with the wrapping box taking into account the difference of spacing that each font has.
Speaker's colours:
Colours for the speaker’s name help those that don’t understand what is happening or who’s talking to whom.
In the project, the first speaker will always have the text-coloured black, whereas the second will always have the text coloured cyan.
I chose those two colours due to the fact that they are very visible, with and without the dynamic box on.
.
Speaker’s name in subtitles:
The speaker’s name is not hardcoded but it’s gathered from the data table that contains both the line and the speaker’s name, to provide full modularity.
.
Directional sound indicator:
The directional sound indicator is an accessibility feature that helps people suffering from hearing impairment understand where sounds are coming from, by converting the audio cues to visual cues on the screen.
Traditionally this feature has not been included in games due to the fact that games usually have similar features, such as the damage Indicator or the detection indicator as shown in the bottom image
Even though the features mentioned above are welcome from an accessibility standpoint, the amount of information that they relay is not enough to offset a player that cannot hear/is hard of hearing, hence the necessity of this accessibility option, which conveys both the direction and the "cause" of the sound.
The final iteration can track up to two sounds at the time, sorting the sounds through a priority list. Different colours convey how important the sounds are at a quick glance, without the need to read the text. Once the player is knowledgeable enough, it can discern what sound is only by the colour of the outbox, saving them precious time.
The text inside the boxes is fully changeable to OpenDyslexic.
.
Tinnitus friendly sounds:
Hearing impairment can manifest in multiple ways and one of those ways is with tinnitus.
Tinnitus is usually described as a ringing in the ears, with the tone and pitch changing from person to person. Its volume can stand above other sounds or not, and it can be in both ears or in only one.
The fake ringing is commonly used in fps, where explosions and various grenades have a ringing sound effect included with the “main” sound effect, and is not possible to remove or disable it.
Tinnitus can get worse when those that are affected by it, hear a similar sound to their tinnitus or a ringing tone.
This accessibility option aims to alleviate this problem.
Motor features:
Key rebind:
This widget is responsible for the re-bind keys. This was done because, as outlined in the literature review, the ability to rebind keys is vital to those that suffer from motor impairment.
This enables the player to use uncommon controllers, which are usually rarely natively supported by the game, which makes it vital to manually rebind keys.
Sensitivity slider:
The option to change the sensitivity input for the mouse or controller is vital to people who suffer from motor impairment.
The slider normally is set with the default sensitivity similar to the one used by windows on default. Here the player can decide to lower it (in case of tremors or similar impairments) or raise it.
Double sensitivity slider:
As mentioned in the previous slides, the ability to change the sensibility is paramount for certain impairments.
In some cases, the default maximum sensibility might not be enough, hence the need to double it.
QTE preface:
QTE, also known as a quick-time event, where the player has to press in a short amount of time a specific combination of buttons displayed on the screen for a concise amount of time.
To make these events accessible, these sections are very inaccessible since players with motor impairment cannot physically push buttons at the speed required, or players with cognitive impairments who cannot register the keys shown on screen in time.
ere are two option in the project:
1. Disable QTE event which disables the QTE event altogether
2. Allow more time for the QTE event, which takes the time of the QTEfrom 2 seconds to 10
Allow more time for QTE event:
As mentioned in the previous slide, QTE events are inaccessible by nature. To make them more accessible to players that have slower reflexes or might have difficulties at reading the required input or at pressing it, this option makes the QTE event more accessible.
Allow to skip or auto-solve the QTE:
In case the QTE is not accessible even after the player has activated the “allow more time” option, then they can skip the QTE event by ticking the option Skip QTE.
Controller support:
The game itself natively support the control as an input mode.
Full playthrough of the prototype
Thank you for reading this text at the bottom of the page. I hope I was stimulating enough to make you think about accessibility and designing for it in games.
If you need any clarification or get in touch with me, you can click here
If you want to play the prototype, you can download it here but beware that it is not polished and still a work in progress. If you wish to download it from a more official source, you can find it here on itch (If the link doesn't work, use this https://gamesux.itch.io/accessibility-in-2021-honour-project).