W3C Workshop on Web Games Position Paper: Adaptive Accessibility

This document summarises some ways in which we believe that game accessibility could be furthered on a technical level, complementing projects such as the Game Accessibility Guidelines. The key ideas of specificity of adaptations, and multimodality, come from a proposal for an Active Game Accessibility (AGA) framework, as detailed below.

Accessibility & games

The demands games put on users can be high; extremely complex input devices, control schemes that require a high degree of precision, timing and simultaneous action; ability to distinguish subtle differences in busy visual and audio information, having to juggle multiple complex goals and objectives, and so on.

But this isn't what makes games' relationship with accessibility unique. What makes it unique is that significant challenge is required. Remove all of these barriers and what you have left is no longer a game, and what the required challenge is varies entirely from game to game.

So there is no fixed bar of 'reasonably accessible', as what's reasonable is specific to each game. But this does not mean accessibility is not possible. There is a great deal that can be done to open games to a wider audience. Part of this landscape is support for assistive technologies (ATs).

Integrating with existing assistive technologies

We need to enable users' existing assistive technologies (ATs), such as screen-readers, screen magnifiers or specific input/output devices, to communicate with games/engines in much the same way as they do with browsers or other applications presently.

There's already a standard for denoting accessibility information in content and interfaces on the web—W3C's Accessible Rich Internet Applications (ARIA)—and there are standard OS-level interfaces for assistive technologies (ATs) to communicate with applications (on Windows there is Microsoft Active Accessibility (MSAA) and Microsoft UI Automation (UIA), for example).

To provide access to games, a standard API—or bridge to, or extension of, existing APIs such as ARIA—could be developed. It would function like MSAA does on Windows (and its equivalents on other platforms), providing a common interface for games and assistive technologies (ATs) to communicate.

Specificity of adaptations and personalisation

Games generally do not use operating system (OS) standard UI widgets and UX conventions, in order to present a particular game world that has its own look, feel and behaviour. Therefore, a major challenge is making the accessibility layer interoperable with as many games, game engines (middleware frameworks used by most games) and as many ATs, or adaptations, as possible. The adaptations themselves could be developed with a varying degree of specificity, as in the following examples:

What are assistive technologies, adaptations and personalisation?

Assistive technologies could be traditional products such as screen-readers, screen-magnifiers, speech-to-text or physical hardware. But they could also be more minor adaptations, as implied above.

It should be noted that there are privacy implications involved in supporting specific hardware/software that is designed for people who may have certain disabilities, or is configured in a particular way. Presence or absence of certain hardware or software does not necessarily mean that the user has a specific disability (for example: someone using a screen-reader may have good sight, but find reading difficult—a common assumption is that someone using a screen-reader has a vision impairment). However, when the user allows personalisations to occur based on their system hardware, software or settings, some information is inherently revealed.

Multimodality, parameters and game mechanics

Another key part of the Active Game Accessibility (AGA) proposal involves classifying the mechanics of games and, thus, high-level accessibility requirements and hooks that might be needed. There have been accessible versions of some sorts of games, such as card games and abstract board games like Chess, for some time. There are other mechanics, such as exploration, action, etc. that may involve more immersive content, or precise timing requirements. There are some limits to how far this kind of classification can be taken; new game mechanics and new methods of input and output are not uncommon, and the impact of design intent and the desired emotional experience is also a factor, but often games are composed of a mix of existing known styles that have certain functional requirements and accessibility implications.

Multimodality may be used to render some of these more accessibly, e.g. there could be an adaptation that converts the task of aiming from a visual one into an audible or haptic one, in order for it to be accessible to a wider range of gamers. Multimodality can also assist with situational/contextual impairments (or the player's rendering preferences).

We could also bring in appropriate sets of adaptations in different phases of play, as the game mechanics change. Further, people could be teamed-up based on their abilities.

What is already possible?

It is worth considering what can already be achieved with thoughtful content design, when following established best practice such as the Game Accessibility Guidelines and the W3C's Framework for Accessible Specification of Technologies (FAST) and Media Accessibility User Requirements (MAUR), and Accessible Player Experiences.

The Framework for Accessible Specification of Technologies (FAST) advises creators of technical specifications how to ensure their technology meets the needs of user with disabilities. Whilst it focuses on UI and content the like of which are prevalent on the web, it may inform game UI accessibility and may be informed by the game experience.

The Media Accessibility User Requirements (MAUR) document presents the accessibility requirements users with disabilities have with respect to audio and video on the web, which relates to games also, and contains recommendations such as providing separate background music, sound effects and audio descriptions, so that they can be filtered out and adjusted independently.

The educational game Railway Hero (Building an Accessible Math Learning Game: The Railway Hero Case Study) was developed with these best practices in mind, and references some of the research cited below, to provide features such as:

Despite being not interfacing with existing assistive technologies (ATs) such as screen-readers (rather the game is self-voicing), features such as these can provide an accessible experience to many people, and demonstrate that thoughtful content design is key—however, much more can be possible if we are able to interface with gamers' existing assistive technologies (ATs), desired personalisations and favourite hardware, as discussed above.

Getting from here to there

The ideas presented above range from relatively low-hanging fruit to much larger efforts. How might we begin to implement them?

Concrete beginnings

Keeping things immersive, fair and fun

Further scope

Questions for discussion

There seems to be a progression of questions, starting with low-hanging fruit and moving to more blue-sky exploration.

Suggested outputs

Some thoughts on possible output from the workshop:


Authoring, review, amendments and feedback: Matthew Tylee Atkinson (The Paciello Group); Ian Hamilton; W3C Accessible Platform Architectures Working Group and its Research Questions Task Force (Main APA/RQTF discussion thread); Joe Humbert and Kit Wessendorf (The Paciello Group).

The key ideas of an MSAA/UIA-like layer, specificity of adaptations and the benefits of multimodality, were developed as part of the Active Game Accessibility (AGA) proposal, led by Dominique Archambault and Klaus Miesenberger and their research groups.


  1. Game Accessibility Guidelines

  2. More Than Just a Game: Accessibility in Computer Games

  3. Towards accessible interactions with pervasive interfaces, based on human capabilities

  4. W3C's Framework for Accessible Specification of Technologies (FAST)

  5. W3C's Media Accessibility User Requirements (MAUR)

  6. Accessibility Object Model

  7. Proof-of-concept 3D level creation tool for blind gamers

Contributing literature

This is a list of papers arising from the research groups that contributed to the development of the Active Game Accessibility (AGA) proposals.