Accessibility Guidelines for VR Games - A Comparison and Synthesis of a Comprehensive Set

1 Introduction

In 2020 the number of people who play video games was estimated to 3.1 billion worldwide, which is 40% of the world population (Bankhurst 2020). This shows that video games are not a niche hobby anymore. The game industry has picked up new technologies like Virtual Reality (VR). Thus, VR is thriving recently, with more and more (standalone) headsets being developed for the consumer market. The current state of the art in VR headsets is dominated by Sony and Facebook’s Oculus, and the market is expected to grow rapidly in the following years (T4, 2021).

1.1 Games and Disability

The rising numbers of gamers worldwide and the technological advances come with new challenges for accessibility. According to an estimate of the World Health Organization (WHO) from 2010, around 15% of the world population has some form of disability (World Health Organization, 2011). This means over a billion people live with physical, mental, or sensory impairments. It is not surprising that an increasing number of these people play or want to play video games but are excluded from it because of barriers they cannot overcome (Yuan et al., 2011). Furthermore, not only people with impairments can profit from accessible games. Situational disabilities like a damaged speaker, loud environment or a broken arm can affect any gamer (Sears et al., 2003; Grammenos et al., 2009; Ellis et al., 2020).

VR comes with new chances to include people with disabilities and make games more accessible. However, it also adds to the accessibility problems that can occur in games. As it is a relatively new technology, new rules and interaction forms still need to be developed.

1.2 Scope and Methodology of the Review

The matter we illuminate in this work is the importance and the need for accessible games in general and VR games in particular. Like others we come to the conclusion that what is needed is more awareness and a well-formulated set of rules developers can follow. By showing how relevant it is to make accessible games, we want to draw attention to and emphasize what the problem with the current state of accessibility guidelines is. The few accessibility guidelines for games that exist, do not or little deal with special requirements for VR.

Besides the general importance of accessibility due to increasing demand, in most countries educational games including VR games are legally required to be accessible for persons with disabilities. To achieve this designers and developers need a guide they can understand and follow. However the existing guidelines make it hard for game developers to apply and follow them when developing a VR game. This work shows what already exists in this field and explores whether it is sufficient.

We evaluate all noteworthy guidelines for games and VR applications. The result shows how small the number of applicable guidelines is. We then combine the found guidelines to a union set. The challenge is, that the different sources often contain the same rules but in different formulations and levels of detail. We also evaluate which of the rules are relevant for VR games in particular and therefore reduce the need for developers to filter relevant guidelines themselves. The union set reveals what rules are missing in the evaluated relevant works and where there is room for improvement. The comparison can help developers to read about guidelines from different sources and give a broader understanding of how to increase accessibility in their games.

2 Related Works

In this section, we look at 1) the state of accessibility in games in general, 2) the state of accessibility of VR games, and 3) the role of guidelines for making games accessible.

2.1 Accessibility in Games

The accessibility of games is a more complex problem than software or web accessibility in general because they often require a lot of different skills to play (Grammenos et al., 2009). Accessibility problems in video games can affect different parts of a game. The reasons are typically divided into motor disability, sensory disability and cognitive disability (Aguado-Delgado et al., 2018).

Video games are not only a pastime for disabled players, although this is an essential part of being able to play. The benefits of making accessible games are presented by Bierre et al. (2004), Harada et al. (2011), Beeston et al. (2018), Cairns et al. (2019a), and Cairns et al. (2019b), and These sources can be summarized into the following list:

• Entertainment and satisfaction: Games are made to be a source of entertainment and distraction.

• Connection and socializing: Playing games gives the chance to participate and feel included.

• Enabling: Playing games can enable impaired people to do things they otherwise cannot do.

• Range: For companies it is important to realize that many people benefit from accessible games.

• Legal issues: Legal requirements for accessibility are becoming more, including games.

• Universal: Everyone can benefit from accessible games.

Developing accessible games has long been seen as a subordinate topic mostly looked at in special interest groups or academics. The majority of accessible games are not mainstream games and/or never leave the state of research. Often accessible games are developed specifically for one particular disability. Making special accessible games can lead to multiple point-solutions that can only be played by a small group of people. (Cairns et al., 2019a)

Additionally, many studies concentrate on easy-to-use games with simple gameplay. Most games rely on hand usage to control them and visuals and sound as output. Problems mainly arise when people are not able to receive the output feedback (visual, auditory, haptic) or use the required devices to give input (Yuan et al., 2011; Hamilton 2018). People with severe visual impairment can not use assistive features and accessible input devices often offer only limited possibilities for interaction. This is why games that can be played without visuals or with alternative input devices are often simple and require minimal input or interaction. (Yuan et al., 2011)

A reason for poor accessibility could be lacking information in schools for developers or the false assumption that making accessible games is not worth it because the number of people who benefit from it is too small. Complications in developing accessible games can be the individuality of impairments or the necessity to change the game fundamentally to make it accessible. It is difficult to find a good compromise between challenge and accessibility. (Yuan et al., 2011)

These difficulties lead to the most general problem with game accessibility: There are not many accessible games on the market. Examples of accessible games for each type of impairment are surveyed by Yuan et al. (2011), which also demonstrates the mentioned problem of point-solutions. A noteworthy mainstream game that is said to be the most accessible game to date is The Last of Us: Part 2. It has over 60 accessibility features that tend to visual, hearing and mobility impairments (PlayStation, 2020).

Many websites, organizations, and communities support accessible gamers and raise awareness. Well-known contact points are the International Game Developers Association (IGDA) Game Accessibility Special Interest Group (GASIG) (IGDA GASIG, 2020), the Able Gamers Charity (AbleGamers, 2018b) and the charity SpecialEffects (SpecialEffect, 2021). An organization that specialized in Extended Reality (XR), including VR, is the XR Access Initiative (XR Access, 2020).

2.2 Accessibility in VR and VR Games

The accessibility problems that occur in regular games overlap with the accessibility problems in VR games. VR applications and VR games come with both: ways to bypass the accessibility problems in games and new challenges and barriers that add to them. In VR, there is still little experience on a best practice compared to other domains. There is no conclusion on what approaches are good or not so far (Hamilton, 2018). This also influences already lacking methods for game accessibility (Mott et al., 2019).

Interaction in VR relies mainly on the head, hands and arms, which can be a huge barrier for people with motor impairment. Hamilton (2018), a better-known activist in the accessible games scene, did a thorough research of accessibility for all kinds of impairments in VR. Besides simulation sickness, Photosensitive Epilepsy and situational disabilities like not seeing one’s hands, he emphasized the problems with VR controllers. He summarizes issues that occur for people with motor impairment in VR games such as the presence, strength or range of limbs or the user’s height. VR controllers have developed into using one controller in each hand. They often have an emphasis on motion controls, like mid-air motions, requiring more physical ability than normal controllers or keyboards (W3C, 2020). In many games and applications there are no alternative input methods to using the controller (Mott et al., 2019). Additionally, at the moment, each manufacturer uses their own controllers, each model being different in terms of accessibility (W3C, 2020). Besides hand usage, most VR headsets are heavy and bulky, which requires strength of the neck and shoulders to use. Many games dictate the position in which the player must be. They require upper-body movements or even have to be played standing.

A more obvious barrier is the visual aspect. Apart from full blindness, barriers in VR can also occur for people with low vision, unequal vision in one eye or stereo-blindness (Hamilton, 2018). An issue that occurs only in VR is problems with wearing glasses under the HMD. Another problem is traditional zooming which can cause simulation sickness and disorientation in VR environments (Chang and Cohen, 2017). Similar problems occur for hearing impairments, such as stereo sound. Subtitles or captions are a special challenge in VR as they can not simply be put at the bottom of the screen. (Hamilton, 2018)

Despite the additional accessibility problems, VR can also help people with disabilities experience things they could not do otherwise, such as horseback riding or driving a car. Contrary to the exclusion people with disabilities might experience in games and the real world, Mott et al. (2019) see VR as a chance for all users to be equal in a game. VR offers new ways for input and output that are not possible with standard devices. Many of these can be realized with the sensors that are already included in current Head-Mounted Displays (HMD).

Most studies on accessible VR concentrate on removing barriers of VR headsets with special applications rather than introducing full games. Therefore there are not many specially made accessible VR games yet. Some games provide accessibility options, but often they only tend to one specific issue which is demonstrated by Bertiz (2019) presenting a list of some of these games. However, tools like SeeingVR (Zhao et al., 2019) and WalkinVR (2020) make VR applications more accessible in general.

2.3 The Role of Guidelines for Accessible Gaming

Software, in general, is becoming more accessible due to better awareness and legal requirements (Miesenberger et al., 2008). Guidelines are an important tool to support this. In Human-Computer-Interaction (HCI) they help designers and developers to realize their projects while also ensuring a consistent system. As for accessibility guidelines especially in the web environment they are well represented.

Different aspects of accessibility are considered in this work: games in general and VR games. The limited range of accessible games and VR games is attributed to a lack of awareness. Grammenos et al. (2009) brings this into relation with the problem of missing guidelines.

Although accessible games gained more awareness in the last few years, there is still a big gap between the regulations for web accessibility and games, which was researched by Westin et al. (2018). They compared the Web Content Accessibility Guidelines (WCAG) (Kirkpatrick et al., 2018) with the Game Accessibility Guidelines (GAG) (Ellis et al., 2020) in the context of web-based games and found that there are many differences. As a conclusion they state that game guidelines would have to be used in conjunction with WCAG for web-based games. Different references, for example Yuan et al. (2011) and Cairns et al. (2019a), draw attention to the lack of good literature, universal guidelines and awareness for accessibility in games. There is no official standard that can be used for games like the WCAG for web applications.

Zhao et al. (2019) found this to be especially true for VR games. It was also noticed by (Westin et al., 2018) who emphasize the importance to pay attention to XR in future guideline development. So far, guidelines for games rarely consider VR accessibility and few guidelines are exclusively made for VR applications. Many of them are specialized in one specific impairment or device. The way users interact with VR is hardly comparable with other software, so generalized guidelines can not be applied (Cairns et al., 2019a).

The success of using guidelines to make a game accessible depends on how good the guidelines are. Some guidelines are very extensive and aim to be a complete guide, while others are summaries or short lists of the most important rules. Many sets of rules try to be as broadly applicable as possible and match a wide variety of use-cases. However, in practice, this makes them harder to understand. It is not easy to make guidelines that are general enough, but at the same time developers can transfer them to their scenario (Cairns et al., 2019a). It can also be hard to decide what guidelines are relevant in a specific context and extract them from a big set. Yuan et al. (2011) see this as a problem when guidelines do not explain each rule’s purpose and when they should be applied.

3 Guidelines

In this section, we introduce existing guidelines that are noteworthy for this work. For each set of guidelines a summarized description is provided. They are the most relevant resources we were able to find in the English language. The guidelines were chosen by relevance in the areas of accessible games and accessible VR applications. Most of them contain explanatory texts for each rule, stating what they are for and providing good examples and tools. The relatively small number of found guidelines confirms the concerns of Yuan et al. (2011) and Cairns et al. (2019a).

The EN 301 549 standard is a collection of requirements from the European Telecommunications Standards Institute (2019). It was included in this comparison as it is the relevant work for legal requirements on accessibility. Its goal is to make Information and Communication Technology (ICT) accessible. This includes all kinds of software such as apps, websites and other electronic devices. As a European standard, these rules have to be followed by the public sector, including schools and universities (Essential Accessibility, 2019). Where applicable, the standard reflects the content of WCAG 2.1, which is why we do not look at WCAG separately in this work. The guidelines were updated several times since 2015. We use version V3.1.1 from 2019 for our comparison. Because the EN 301 549 is a very extensive document that considers any form of information technology, not all chapters are suitable for accessible games or VR. Therefore, the less relevant chapters were omitted, integrated into other guidelines or summarized into one more general rule.

3.1 Guidelines for Games

Many game guidelines build on each other or are mixtures of different sources. The most extensive game guidelines mentioned frequently in relevant literature are Includification and the GAG.

3.1.1 IGDA GASIG White Paper and Top Ten

In 2004 the IGDA GASIG published a white paper (Bierre et al., 2004) that lists 19 game accessibility rules found out from a survey. Later, they summarized these to a top ten list (IGDA GASIG, 2015) that is constantly updated. It boils down to the most important and easy to realize rules a developer should follow, providing quick help.

3.1.2 MediaLT

Based on the rules from the IGDA GASIG white paper MediaLT, a Norwegian company developed their own guidelines (Yuan et al., 2011). They presented 34 guidelines for “the development of entertaining software for people with multiple learning disabilities” (MediaLT, 2004).

3.1.3 Includification

Includification from the AbleGamers Charity (Barlet and Spohn, 2012) came up in 2012. It is a long paper including an accessibility checklist for PC and console games. Each rule is additionally explained in detail in plain text.

3.1.4 Accessible Player Experience

As a successor to Includification AbleGamers published a set of patterns on their website called the Accessible Player Experience (APX) in 2018 (AbleGamers, 2018a). They are, in fact, more patterns than guidelines, providing a game example for each accessibility problem.

3.1.5 Game Accessibility Guidelines

The Game Accessibility Guidelines (GAG) (Ellis et al., 2020) were also developed in 2012 and are the most known and extensive guidelines for games. They are based on WCAG 2.0 and the internal standards of the British Broadcasting Corporation (BBC) (Westin et al., 2018). The rules are constantly updated. For each guideline the GAG offer game examples that implemented the rule and list useful tools to do so.

We used the GAG as the basis for this work because they are the most extensive game guidelines of all considered. At the same time they also fit the game context best and provide easy-to-follow wording.

3.1.6 Xbox

Like many other companies, Microsoft has its own guidelines for products. For games on the Xbox console the Xbox Accessibility Guidelines (XAG) provide best practices (Microsoft, 2019). These guidelines are based on the GAG and also include some references to the APX.

3.2 Guidelines for VR

As before, we make no distinction between VR games and other VR applications. Only two sources that list measures for better accessibility in VR in the form of guidelines were found.

3.2.1 XR Accessibility User Requirements

The XR Accessibility User Requirements (XAUR) are a set of guidelines published by the Accessible Platform Architectures (APA) Working Group of the World Wide Web Consortium (W3C) in 2020. They contain definitions and challenges as well as a list of 18 user needs and requirements for accessible XR applications (including VR). The current version is a Working Draft as of September 16, 2020. (W3C, 2020).

3.2.2 Oculus VRCs: Accessibility Requirements

The Virtual Reality Checks (VRC) from Oculus developer portal are requirements a developer must or should follow to publish his/her app on Oculus devices. These VRCs have recently (in 2021) been extended by the section “Accessibility Requirements”, providing recommendations to make VR apps more accessible. (Oculus, 2020).

3.2.3 The University of Melbourne

On their website the University of Melbourne provides an overview of “Accessibility of Virtual Reality Environments” (Normand, 2019). The main content are the pros and cons of VR for people with different types of disabilities. For each type they provide a list which also includes use cases that can be seen as guidelines.

4 Synthesis of Guidelines

We used the previously introduced sources to derive a comprehensive set of guidelines that includes all rules that are relevant for accessible VR games. Inspired by the proposed procedure of the GAG we took the following steps to achieve this.

1) All guidelines mentioned above were evaluated and filtered by what is directly relevant for VR environments and games.

2) The remaining rules were compared to each other and the union set was formed. Similar guidelines were summarized and the formulations slightly changed or enhanced.

3) The result is a set of guidelines that combine and summarize all rules for accessible VR games found in the existing sources.

All found guidelines are shown as a list below. To avoid duplicate entries, this set is sorted by topic not by impairment or importance. This classification does not imply that some rules can not be relevant for other categories. The main source of the wording is given in parenthesis. Because the GAG was used as a basis, the most formulations were overtaken from them. This does not mean that those rules are not included in other guidelines. To provide good readability and the source of the text at the same time, the guidelines are color coded as follows:

• Black text in normal font type: Text written in black was taken as is from the original source which is written behind each rule in parenthesis. This does not mean that this rule does only appear in this particular set. It merely marks where the formulation was used from.

• Orange text in italic font type: Text written in orange marks where the original formulation from the source in parenthesis was changed or extended. This could be because the wording from another source was added or if the wording was adapted to be more clear.

The full comparison table is available as supplementary material on this paper.

Input and Controls

• Allow controls to be remapped/reconfigured; avoid pinching, twisting or tight grasp to be required (GAG)

• Provide very simple control schemes. Ensure compatibility with assistive technology devices, such as switch or eye tracking (GAG)

• Ensure that all areas of the user interface can be accessed using the same input method […] (GAG)

• Include an option to adjust the sensitivity of controls (GAG)

• Support more than one input device simultaneously, include special devices (GAG)

• Ensure that multiple simultaneous actions (eg. click/drag or swipe) and holding down buttons are not required […] (GAG)

• Ensure that all key actions can be carried out with a keyboard and/or by digital controls (pad/keys/presses) […] (GAG)

• Avoid repeated inputs (button-mashing/quick time events) (GAG)

• Include a cool-down period (post acceptance delay) of 0.5 s between inputs (GAG)

• Include toggle/slider for any haptics (e.g., controller rumble) (GAG)

• Provide a macro system. If shortcuts are used they can be turned off or remapped (GAG)

• Make interactive elements that require accuracy […] stationary or prevent using them (GAG)

• Make sure on-screen keyboard functions properly (Includification)

Audio and Speech

• Provide separate volume controls and stop/pause or mutes for effects, speech and background sound/music (independent from the overall system) (GAG)

• Ensure no essential information is conveyed by sounds alone (GAG)

• Use distinct sound/music design for all objects and events (GAG)

• Use surround sound (GAG)

• Provide a stereo/mono toggle and adjustment of balance of audio channels (GAG)

• Avoid or keep background noise to minimum during speech (GAG)

• Provide a pingable sonar-style audio map (GAG)

• Provide a voiced GPS (GAG)

• Simulate binaural recording (GAG)

• Provide an audio description track (GAG)

• Allow for alternative Sound Files (IGDA White Paper)

• Provide pre-recorded voiceovers and screenreader support for all text, including menus and installers (GAG)

• Masked characters or private data are not read aloud without the users allowance (EN 301 549)

• The purpose of each input field collecting information about the user is presented in an audio form (EN 301 549)

• […] Speech output shall be in the same human language as the displayed content […] (EN 301 549)

• Ensure that speech input is not required […] (GAG)

• Base speech recognition on individual words from a small vocabulary (eg. “yes” “no” “open”) instead of long phrases or multi-syllable words (GAG)

• Base speech recognition on hitting a volume threshold (eg. 50%) instead of words (GAG)

Look and Design

• Ensure interactive elements/virtual controls are large and well spaced […] (GAG)

• Use an easily readable default font size and/or allow the text to be adjusted. Use simple clear text formatting. (GAG)

• Ensure no essential information is conveyed by text (or visuals) alone, reinforce with symbols, speech/audio or tactile (GAG)

• Ensure no essential information is conveyed by a colour alone (GAG)

• Provide high contrast between text/UI and background (at least 4.5:1) (GAG)

• UI Components and Graphical Objects have a contrast ratio of at least 3:1 or provide an option to adjust contrast (GAG)

• Provide a choice of […] colour […] (GAG)

• Allow interfaces to be rearranged (GAG)

• Allow interfaces to be resized (GAG)

• Provide a choice of cursor/crosshair colours/designs and adjustable speed and size (GAG)

• Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound (original from WCAG 1.3.3) (EN 301 549)

• No 3D Graphics Mode (IGDA White Paper)

• Indicate focus on (UI) elements (XAG)

• Enable people to edit their display settings such as brightness, include screen magnification (VRC)

• Provide an option to turn off/hide background movement or animation. Moving, blinking or auto-update can be turned off or paused (GAG)

• Headings, Labels and Links describe their topic or purpose in their text. If they are labeled, the label contains their text (EN 301 549)

Subtitles/Captions

• Provide subtitles for all important speech and supplementary speech. (Provide a spoken output of the available captions) (GAG)

• If any subtitles/captions are used, present them in a clear, easy to read way and/or allow their presentation to be customised (GAG)

• Ensure that subtitles/captions are cut down to and presented at an appropriate words-per-minute for the target age-group (GAG)

• Ensure subtitles/captions are or can be turned on with standard controls before any sound is played (GAG)

• Provide captions or visuals for significant background sounds. Ensure that all important supplementary information conveyed by audio is replicated in text/visuals (GAG)

• Provide a visual indication of who is currently speaking (GAG)

• Captions and Audio Description have to be synchron to the audio (EN 301 549)

Simplicity

• Use simple clear language. Employ a simple, clear narrative structure. (GAG)

• Include tutorials (GAG)

• Include a means of practicing without failure […] (GAG)

• Include contextual in-game help/guidance/tips (GAG)

• Include assist modes such as auto-aim and assisted steering (GAG)

• Indicate/allow reminder of current objectives during gameplay (GAG)

• Indicate/allow reminder of controls during gameplay (GAG)

• Offer a means to bypass gameplay elements […] and/or give direct access to individual activities/challenges and secret areas (GAG)

• Allow the game to be started without the need to navigate through multiple levels of menus (GAG)

• Offer a wide choice of difficulty levels. Allow them to be altered during gameplay, either through settings or adaptive difficulty (GAG)

• Include an option to adjust the game speed and/or change or extend time limits (GAG)

• Allow players to progress through text prompts at their own pace (GAG)

• Allow all narrative and instructions to be paused and replayed, care for automatic interruption. (GAG)

• Give a clear indication on important or interactive elements and words (GAG)

• Provide an option to turn off/hide all non interactive elements (GAG)

• Players can confirm or reverse choices they have made […] (APX)

VR

• Avoid (or provide an option to disable) VR simulation sickness triggers (GAG)

• Allow for varied body types in VR, all input must be within reach of all users (GAG)

• Do not rely on motion tracking and the rotation of the head or specific body types (GAG)

• If the game uses field of view, set an appropriate default or allow a means for it to be adjusted (GAG)

• Avoid placing essential temporary information outside the player’s eye-line (GAG)

• Ensure the user can reset and calibrate their focus, zoom and orientation/view in a device independent way (XAUR)

• Applications should support multiple locomotion styles (VRC)

• Provide an option to select a dominant hand (VRC)

Multiplayer

• Support voice chat as well as text chat for multiplayer games (GAG)

• Provide visual means of communicating in multiplayer (GAG)

• Allow a preference to be set for playing online multiplayer with players who will only play with/are willing to play without voice chat (GAG)

• Allow a preference to be set for playing online multiplayer with/without others who are using accessibility features that could give a competitive advantage (GAG)

• Use symbol-based chat (smileys etc) (GAG)

• Realtime text - speech transcription (GAG)

Others

• Allow gameplay to be fine-tuned by exposing as many variables as possible (GAG)

• Avoid flickering images and repetitive patterns to prevent seizures and physical reactions (GAG)

• Provide an option to disable blood and gore, strong emotional content or surprises (GAG)

• Avoid any sudden unexpected movement or events as well as a change of context (GAG)

• Provide signing (GAG)

• Include some people with impairments amongst play-testing participants and solicit feedback. Include every relevant category of impairment […], in representative numbers based on age/demographic of target audience (GAG)

• Provide accessible customer support (XAG)

• If a software can be navigated sequentially, the order is logical (EN 301 549)

• Provide details of accessibility features in-game and/or as accessible documentation, on packaging or website. Activating accessibility features has to be accessible (GAG)

• Ensure that all settings are saved/remembered (manual and autosave). Provide thumbnails and different profiles (GAG)

• Do not make precise timing essential to gameplay […] (GAG)

• Allow easy orientation to/movement along compass points (GAG)

• Where possible software shall use the settings (color, contrast, font) of the platform and native screen readers or voice assistance (XAUR)

• Ensure that critical messaging, or alerts have priority roles that can be understood and flagged to assistive technologies, without moving focus (XAUR)

• Allow the user to set a “safe place” - quick key, shortcut or macro and a time limit with a clear start and stop (XAUR)

• Locking or toggle control status can be determined without visual, sound or haptic only (EN 301 549)

• Using closed functionality shall not require to attach, connect or install assistive technology (EN 301 549)

5 Discussion and Final Remarks

The rapidly growing market of video games and VR headsets indicates an increase in the number of people who play games.

In this work, we address the chances and problems for people with disabilities regarding games and VR applications. Our comparison of existing game and VR guidelines provides a broader understanding on existing guidelines from various sources. It can also help the authors of the guidelines to improve them in the future as they see what might be missing. Furthermore, we hope this work can help raise awareness, especially for accessible VR games.

The comparison showed that none of the presented guidelines is an exhaustive list. We found that there are some important rules missing in the relevant works that are included in other guidelines. However, most rules are covered by either the Game Accessibility Guidelines or the EN 301 549 standard. Among game guidelines, only the GAG and Xbox Accessibility Guidelines include rules that are specific to VR. As can be seen, the guidelines from MediaLT (2004) and the Top Ten from IGDA GASIG (2015) do not add any rules to the set that are not included in other guidelines.

It should be noted that our resulting set of guidelines is based on literature research only, and that we have not conducted empirical research with users to identify possible omissions of accessibility requirements in existing guidelines. Therefore, the “comprehensive” set of guidelines that we present in this paper may need to be further extended in the future to address accessibility needs that have yet to be identified in the field.

We noticed that there are a few guidelines in the EN 301 549 standard that do not occur in the GAG. On the other hand, there are some rules that are missing in the European standard or are not stated with sufficient specificity. We conclude that the legal requirements are currently not sufficient to cover the full range of accessibility needs of the users. Therefore, we suggest that missing guidelines should be added to the European standard.

Another problem with the European standard is its structure and wording. During the evaluation it became apparent that the standard is very hard to read and understand. Rules that are not linked to WCAG can be interpreted in different ways and no examples are given. We fear that the EN 301 549 may not be suitable as a guide to be used by developers directly. A possible approach would be to translate the standard into an alternative version of more applicable rules with practical examples. Also, a tutorial should be provided that shows in detail how each criterion is applied to VR applications.

A last remark on the European standard relates to the fact that it does not include a table that lists all criteria that are legally required for VR applications. Such tables are given for Web and mobile applications. Therefore, it is currently unclear which criteria are enforced by the European Commission for VR applications in public institutions, as opposed to criteria that are “nice to have”.

The overall conclusion from working with the available guidelines was that there is room for improvement in all existing guidelines and including rules that are specific for VR should be considered by the most relevant guidelines.

A comprehensive and widely acknowledged set of accessibility guidelines for VR games is needed in the future, just as the Web Content Accessibility Guidelines for Web applications. The guidelines we presented in this paper can be a starting point for this. However, we use the wording of the original sources and there are no explanations or examples included. To make for a good checklist for developers to follow, a much more detailed description of each guideline would be necessary. Also, a companion tutorial would be useful to provide support for VR game developers who are new to the field of accessibility.

As mentioned, not only guidelines are underrepresented for accessibility, but there is also a lack of available tools for developers. Many of the approaches to avoid accessibility problems in games could be supported by suitable libraries and automatic checking tools. This takes some of the burden away from developers and makes development much easier and faster while ensuring a consistently high level of accessibility. Eventually, the employment of suitable platforms and libraries should ensure a decent level of accessibility, and the majority of guidelines could be automatically checked and hints for fixes provided by development tools.

Author Contributions

This manuscript was written by FH with corrections and minor adaptions made by GZ. The research work was conducted by FH and supervised by GZ and PM. All authors have read, and approved the manuscript before submission.

Conflict of Interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Publisher’s Note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Supplementary Material

The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/frvir.2021.697504/full#supplementary-material

Abbreviations

ADB, Android Debug Bridge; APA, Accessible Platform Architectures; APX, Accessible Player Experience; BBC, British Broadcasting Corporation; BCI, Brain-Computer-Interface; DoF, Degrees of Freedom; EEG, Electroencephalogram; GAG, Game Accessibility Guidelines; GASIG, Game Accessibility Special Interest Group; HCI, Human-Computer-Interaction; HMD, Head-Mounted Display; ICT, Information and Communication Technology; IGDA, International Game Developers Association; JSON, JavaScript Object Notation; PoC, Proof of Concept; RPG, Role-Playing Game; UA-Games, Universally-Accessible Games; UEQ, User Experience Questionnaire; VR, Virtual Reality; VRC, Virtual Reality Checks; W3C, World Wide Web Consortium; WCAG, Web Content Accessibility Guidelines; WHO, World Health Organization; XAG, Xbox Accessibility Guidelines; XAUR, XR Accessibility User Requirements; XR, Extended Reality.

References