Reimagining infrastructure for video game accessibility: exploring Access Profiles with players with disabilities and game designer-developers

Abstract

Games provide opportunities for entertainment, socializing, and community building. However, many games are not built with players with disabilities (PwDs) in mind. Accessibility features, like captions or auto-aim, vary in availability and quality. While some standards and guidelines exist, designer-developers continue to face several resource, knowledge, and practical challenges in implementing accessibility features. Complementing prior work about specific needs and features, we present Access Profiles (AP), a framework for multi-directional communication between game designer-developers and PwDs. Through a qualitative study, we investigated how systems utilizing the AP framework could support designer-developers in selecting, implementing, and documenting accessibility-related features in their games, as well as how PwDs may be supported in both finding accessible games and improving the initial experience of new games. Our findings include insights on how AP has the potential to improve game discovery and configuration, but also necessitate comprehensive changes across game engines, retailers, and launchers used across the gaming ecosystem. We then apply theories of propagation to discuss how AP can support the standardization of known features and spreading of novel features to systematically improve game accessibility over time.

1 Introduction

Digital games vary widely in how accessible they are to people with disabilities (PwDs)¹ (Brown and Anderson, 2021). Despite intentions to make games for a broad audience, many game designer-developers are unaware of PwDs' experiences, often due to unexamined ableism and/or a lack of resources (Lewis, 2022; Hofmann et al., 2020; Ymous et al., 2020; Kulik et al., 2021; Martinez et al., 2024). Even for designer-developers who try to be more inclusive, achieving a high level of accessibility is challenging, as accessible design varies widely between genres, games, and platforms. For example, the audio descriptions for sensory aspects of horror games vs. puzzle games will be substantially different. Accessibility in itself also continues to evolve. While cutting-edge innovations in gaming accessibility result in nascent, necessarily experimental features (e.g., tools for non-visual exploration Nair et al., 2024), several features such as captioning or controller re-mapping, are mature enough to have established best-practices (General Services Administration, 2024; Netflix, 2022; Microsoft, 2026). This opens questions around how to conceptualize and implement accessibility in shared or different ways across games, and in turn, what support that designer-developers need beyond critiques of inaccessibility and broad feature lists.

The present paper centers both PwDs and designer-developers' experiences in with accessibility features and their propagation. Accessibility feature refers broadly to a system or mechanic a PwD leverages to create a more accessible playing experiences for them. These features may be affiliated with but are not inextricably tied to a disability diagnosis. Examples include “general” settings such as the ability to pause a game as well as high contrast modes for visually impaired players. Propagation—“the act of increasing the user base of an innovation” (Taylor et al., 2018)—of accessibility features in games is a large challenge (Brown and Anderson, 2021). Some propagation occurs through mimicry; for example, large game studios will have team members dedicated to studying previous games in their genre to understand how accessibility features could be implemented in their game (Kulik and Cairns, 2023). However, propagation can be especially challenging for independent (indie) or hobby designer-developers, who often use common game engines such as Unity or Unreal that lack native support for implementing most accessibility features. Therefore, instead of problematizing individual designer-developers' choices in game pre-production, we problematize the lack of designer-developer-centered interventions for collectively implementing game accessibility.

By the time that games become available to the public, there are varied implementations and vague signals of their accessibility offerings. PwDs then often scour through settings menus and engage in a process of trial-and-error to determine a game's features, the quality of their implementation, and the combination of settings that fits them (LauraKBuzz, 2024; Martinez et al., 2024).

This necessitates a point of view for research that bridges designer-developers' pre-production experiences with building games and PwDs' post-release experiences with discovering games. As a co-author team of academics and indie game designer-developers, we present the Access Profiles (AP) framework and two interrelated interview studies:

• The AP framework is an initial design of a multi-system approach to streamline communication of accessibility settings. Players indicate preferences in profile instances that can then be interpreted by specific games to automatically adjust available settings. Designer-developers can reference AP as a concrete starting point for the accessibility features that players might expect and, in turn, make informed, clearly signaled choices about what features their game supports. An example of this is illustrated in Figure 1 where caption font and high-contrast mode are automatically changed on game load.

• The first interview study, featuring five independent (indie) game designer-developers, examines how resources like AP can impact attitudes and workflows for implementing game accessibility. We explore the research question: How might AP facilitate changes in tooling (e.g., game engines) and systems (e.g., shared terminology) needed to better support game accessibility development and propagation?

• The second interview study, featuring nine PwDs, shares insights about their experience playing and configuring games and responses to AP. We explore the research question: How might AP foreground and centralize access needs²in player-facing nodes (retailers, library launchers, in-game menus, etc.) of the gaming ecosystem?

Figure 1

Our interview findings concur with previous evidence that PwDs desire rich gaming experiences, face unpredictable barriers to accessing these experiences, and often find innovative paths around/through these barriers (Gonçalves et al., 2020; Martinez et al., 2024; Porter and Kientz, 2013; Ringland et al., 2017; Spiel and Gerling, 2021). We expand on the scope of prior work by also putting these findings in conversation with designer-developer experiences. That is, we find that indie game designer-developers often lack the resources, skills, or motivation to implement accessibility features and design patterns into their games. The present paper addresses these concerns by investigating the design space of aligning players' and designer-developers' efforts toward creating accessible games.

In this paper, we present both conceptual and empirical contributions.

Our framework, Access Profiles, contributes an initial design of infrastructure for (1) PwDs to find relevant games and automatically select desired settings on launch and (2) for supporting designer-developers to improve the design, implementation, and communication of accessibility features.

While analyses of inaccessible game interactions exist (Martinez et al., 2024; Porter and Kientz, 2013; Gonçalves et al., 2020; Spiel and Gerling, 2021), prior work does not explore interventions to different parts of the gaming ecosystem, such as game engines, stores, search, and launchers. The inclusion of both PwDs and designer-developers in the interview study provides empirical evidence of the relational aspects of game accessibility and highlights the need for designer-developer-supportive interventions.

Our framework and analysis builds on theories of propagation (Hovey et al., 2023; Henderson and Dancy, 2007; Rogers, 2003; Taylor et al., 2018) to understand how different accessibility features require different collective strategies. In turn, we discuss changes in infrastructure needed to support PwDs and designer-developers with varying levels of prior accessibility experience, ultimately toward creating a gaming ecosystem with diverse disabled participation in mind.

2 Related work

As games evolve in academic, industry, and hobby spaces, PwDs are important stakeholders. It is also necessary to contextualize the technological and systemic factors that lead to games being variably in/accessible. We provide an overview of (1) games and PwDs, (2) current accessibility frameworks in games, (3) general digital accessibility standards, (4) the impact of studio size, and (5) current innovations in gaming accessibility.

2.1 Games and players with disabilities

Digital/video games are a uniquely interactive, multimodal, and social mode of play-centered media. Through digital games, players connect, build community, and experiment with individuality, control, and agency (Lenhart et al., 2008; Lai and Fung, 2020; Skolnik and Conway, 2019). PwDs are motivated by similar factors as non-disabled players, such as experiencing social connection and escapism through games, but also view games as a mechanism to feel enabled and equal (Cairns et al., 2021; Martinez et al., 2024; Ringland, 2019; Ringland et al., 2017). Despite representing 20% of players, PwDs often encounter barriers to fully accessible experiences, or complete exclusion from certain games, due to inaccessible design (Wilhelmsson et al., 2015; Martinez et al., 2024). PwDs face exclusion by various features, such as the ability to remap controls or remove overstimulating visual effects, not being included in many games. Additionally, the existence of accessibility features does not guarantee quality implementation, e.g., captions that are too small are not usable (Brown and Anderson, 2021).

In spite of so many games being inaccessible, PwDs are in all corners of the gaming landscape. For example, Autcraft, a custom server for Minecraft, offers an autism-centered digital space (Ringland, 2019; Ringland et al., 2017). Within existing games, PwDs have creatively invented workarounds to circumvent access barriers, such as players with low vision navigating visual-centric games by swinging their sword around, almost as a digital white cane, and relying on audio cues for feedback (Gonçalves et al., 2023). Additionally, DeafBlind mobile gamers with limited vision select colorful themes to better perceive gameplay (Theil et al., 2023).

PwDs have persistently championed efforts to improve accessibility. For example, some PwDs work directly with designer-developers as accessibility consultants (Sony Interactive Entertainment, n.d.). Others advocate for more inclusive gaming systems: many games utilizing controllers and keyboards remained extremely inaccessible, leading to advocacy that resulted in commercially available controllers designed specifically for PwDs, such as the Xbox Adaptive controller³ and the 8BitDo Lite SE controller⁴ (Aguado-Delgado et al., 2020).

2.2 Video game accessibility “standards”

Video games, at present, do not have a set of comprehensive, enforceable accessibility standards. While not comprising formal standards, the Entertainment Software Association announced the Accessible Games Initiative which aimed to implement and standardize accessibility-related tags on all major digital game storefronts, with the exception of Steam who elected to use their own non-standardized tags (Entertainment Software Association, 2025; Valve Corporation, 2025). This was in response to long-running uncertainty of what features are supported by a specific game. However, store tags do not guarantee that a game has actually implemented a tagged feature in any standardized way, or implemented it at all. Given the uncertainty of what features are supported by a specific game, accessibility focused journalism, such as Can I Play That? (AbilityPoints, 2018), and vloggers/streamers, such as LauraKBuzz (Dale, 2015), form integral parts of the information ecosystem that PwD leverage. Additionally, both the Accessible Game Database (DAERSystem provided by Apex Access, 2021) and AbleToPlay (Good Trouble Games, 2025) provide ways to search for games by accessibility feature.

In addition to tags and journalism that seek to empower PwDs to make informed choices, several organizations have released resources focusing on accessible design targeted toward designer-developers. These include AbleGamers' Accessible Player Experience (APX) design pattern library (Power and Barlet, 2019; AbleGamers, 2019; Accessible Games by The AbleGamers Charity, 2022) and the Game Accessibility Guidelines, which provides a searchable list of commonly implemented accessibility features (Ellis et al., 2016). The present paper seeks to bridge these broader initiatives with designer-developers and PwDs' experiences on the ground with prototyping and configuring games.

2.3 Digital accessibility standards

Looking outside of the field of video games, we find several digital accessibility standardization projects. One of the largest of these has been the Web Content Accessibility Guidelines (WCAG)⁵. While WCAG is not without criticisms (e.g., Clark, 2006), it is also an accepted ISO standard (Web Accessibility Initive, 2012). WCAG seeks to cover a wide range of web content and styles, similar to how digital games can take many formats. However, there are some areas where WCAG does not cover, such as common features used by web-based video games (Westin et al., 2018)). Although imperfect, WCAG is an example of a living set of standards with detailed explanations, thorough documentation and examples, and enforceable compliance standards.

Centralizing settings through standardized software has been explored in different domains. The Global Public Infrastructure (GPII) project sought to create persistent, personalized settings for interacting with kiosks (Vanderheiden et al., 2013). Ackermann et al. explored centralized user preferences in the context of web-based applications (Ackermann et al., 2012). AP aims to learn from these external examples by incorporating the elements of detailed documentation of best-practices of WCAG with the streamlined, centralized preference structure of GPII, and situate this combination within the domain of video games.

2.4 Effects of studio size

AAA studios⁶ such as Nintendo and Electronic Arts (EA), develop and publish games that account for close to half of all game sales (Video Game Insights, 2024). There are some recent examples of AAA games that have centered accessibility, such as The Last of Us Part II, an action-adventure game, had over 60 accessibility settings focused on fine-motor, audio, and visual adjustments (PlayStation, 2020). Kulik et al. investigated designer-developer attitudes toward accessibility at an AAA studio and showed that designer-developers found accessibility an important consideration, and in practice, they analyze existing video games with accessibility features (Kulik and Cairns, 2023). However, designer-developers at large studios often felt that their accessibility-related knowledge was often limited, they did not have sufficient accessibility-related tools, and they did not feel like they had the time required to learn about accessibility or to develop clear accessibility goals for their project (Kulik et al., 2021; Kulik and Cairns, 2023).

In 2024, 99% of games added to Steam and 58% of games sold were developed by indie designer-developers (Video Game Insights, 2024). While reports for platforms whose sales numbers are not publicly available, such as Xbox, Nintendo, and PlayStation, these trends indicate that the marketplace for digital games is distributed across thousands of different studios and publishers. Therefore, the majority of games developed today are not coming from large AA/AAA studios with decades of releases and large, intricate internal tooling (Kulik and Cairns, 2023), but rather from smaller teams. Given this development landscape, it is important to consider how these smaller studios acquire accessibility-related knowledge, which may be quite different than AAA studios. This is why the present paper centers the experiences of indie designer-developers with varying years of experience.

2.5 Innovations in accessible gaming

In tackling inaccessibility in digital game design, researchers have adopted different approaches ranging from systematic investigations to designing novel technologies. To better understand the experiences of PwDs, Martinez et al. developed the “discovery, evaluation, and adaptation” model of game adoption and play among PwDs which highlighted the personal and often-iterative process through which a PwD may develop unique play-styles and workarounds (Martinez et al., 2024). While their work focused on the perspective of PwDs, they offered several design insights for designer-developers and retailers which include clearly communicating supported features and encouraging alternative ways of playing.

Various academics and indie game practitioners have focused on innovating specific accessibility features. Nair et al.'s work has focused specifically on visually impaired player experiences. This included the design of an audio-based tool that enables blind players to better navigate 3D worlds (Nair et al., 2021) as well as comparative assessments of different spatial awareness systems (Nair et al., 2022). Clark et al. focused on PwDs' experience of location-based games and developed concrete design recommendations for games in this specific genre (Clark et al., 2023). Some indie designer-developers have implemented innovative accessibility features, such as Moss, a virtual reality adventure game, featuring a main character that communicates with American Sign Language (PolyArc Games, 2018), or Chairdevil, a racing game where players can use physical wheelchairs as controllers (Bobby Lockhart, Andy Saia, 2024).

In our Related Work, we explained how research and practice show accessibility features in games build on known specifications (e.g., captions) and continue to evolve as game genres as a whole evolve (e.g., games that reappropriate assistive technologies as controllers). Drawing on this background about the diversity of players, companies, and genres involved in the games ecosystem, the present paper seeks to align the prototyping experiences of indie game designer-developers with the discovery and configuration experiences of PwDs. Next, we discuss how our framework offers a collection of mechanics and resources for supporting different stakeholders.

3 Access Profiles (AP) framework

3.1 Overview

The design of the AP framework was motivated by three main factors: (1) Co-authors' prior experience with the multiple points of friction when incorporating accessibility features while developing a commercial indie game, (2) Previous work that has highlighted the heterogeneity in video game accessibility (Brown and Anderson, 2021; Kulik and Cairns, 2023; Martinez et al., 2024), and (3) Systems designed to standardize or streamline disabled access in other contexts (Web Accessibility Initive, 2012; Vanderheiden et al., 2013). Given the multi-faceted nature of video game accessibility, we elected to design the complete conceptual framework as well as two vertical slices in the form of technical and experiential probes (which we describe in the subsequent Methods section). Below we explain how AP's workflows streamline accessibility-related communication⁷ between designer-developers and players by:

• creating a unified AP Central, a third party that can provide designer-developers with non-exhaustive lists of common accessibility features and robust documentation with practical examples, as well as verify accuracy of AP tags and moderate community reports of existing games on behalf of players;

• allowing players to use the Access Hub website to create AP Instances, which are lists of accessibility features they would like to use, stored in a centralized location relative to the player's games;

• creating plug-ins to support designer-developers in implementing features and an API through which designer-developers can call a player's AP on initial game load;

• curating a shared list of AP tags, with which designer-developers can self-tag to enable their games to be more discoverable, while PwDs can use these tags to find games that have specific accessibility features; and

• allowing games to call a player's AP Instance on launch to automatically configure settings based on their preferences or notify the player about the absence of the settings.

Regarding privacy, AP instances only share the list of requested features (e.g., high-contrast mode on) and do not use personally identifiable information or full lists of disabled-related identities (e.g., Player Sarah Smith is Blind). For PwDs, this mitigates the risk of players' disability identity being unwillingly disclosed, and for IDs, the lists of specific game features in AP instances are more actionable than disability identity labels because they do not require developers to guess which features would be related to different communities (e.g., blind and low vision players will vary in whether they request screen reader support, enlarged test, high-contrast mode, and/or other features).

3.2 Usage example

To illustrate the AP framework, outlined in Figure 2, we imagine a scenario where Parker, a gamer with low vision, creates an AP Instance on the Access Hub website. Parker knows they have different preferences for 2D and 3D games, so they create separate 2D and 3D AP instances that specify different accessibility features. To enter their preferences into a specific game, Parker knows they could use a secure Summary Code, but chooses to Sync their AP with Steam, their Game Retailer of choice, instead. After syncing, Parker's AP is linked with their Steam Profile and ready to be applied in the future. Elsewhere, Dani, an indie designer-developer, is developing a new 2D platforming game, JumpI/O. They consult the AP Documentation to understand the scope of possible accessible features they could include in their game. This informs the Design & Development as Dani chooses to include a variety of settings, including a high contrast mode, but they note that implementing a text-to-speech or in-game screen reader would be out-of-scope for their solo-developed game. Dani utilizes the AP Plug-In as a starting point for their high-contrast mode, finish development, and integrates the AP API into JumpI/O. They add the game to the Steam store with AP Tags that indicate JumpI/O has a high contrast mode, but not text-to-speech. Parker, searching for a new game with a high contrast mode, searches the Steam store, finds, and purchases JumpI/O. On initial launch, JumpI/O Applies AP Settings that best correspond to Parker's AP. The game launches with high contrast mode active and Parker is able to dive right into the game. After experiencing a few levels in JumpI/O, Parker decides to Adjust Local Settings and change the volume of the sound effects.

Figure 2

3.3 Design reflections: raising the floor and ceiling for game accessibility

Here, we reflect on AP as a collective technology and how this framework can engage with accessibility as an evolving, ongoing process.

One of AP's goals is to streamline communication and provide baselines, not to imply that any of the accessibility features we mention are “solved problems.” For instance, while closed-captioning has a mature set of best practices that has been developed over decades (General Services Administration, 2024), innovations in digital games captioning are constantly occurring such as captioning speaker emotions in Assassin's Creed Shadows and Atomfall (LauraKBuzz, 2025a,b). Regarding well-known features that players can anticipate, our intention is to have AP establish the “floor” of game accessibility so it is also possible to continue collectively raising it. As such, we emphasize that AP is a process, not a certification or stamp of approval.

We are also enthusiastic about accessibility being a motivating force for gaming innovations. The “ceiling” of game accessibility continues to rise as features are constantly being discovered, developed, re-mixed, and re-purposed. Therefore, AP's documentation needs to be clear that AP is a curated set of resources to support a broad range of interactions, but still recognize when the lived experience of PwDs and seasoned accessibility-focused designer-developers overrides or nuances AP's current information. The corollary here is that AP's resources will be revised and announced over time, in a similar fashion to how games continue having patches and player-facing update logs after release.

We recognize that AP will still co-exist with local settings menus that designer-developers implement with various aesthetics and options. The incredible diversity of digital games should be honored by ensuring that settings a player selects locally for a specific game should be used instead of the setting on their AP. In practice, this means that the AP should only be called on the initial launch of a game with a specific launcher and AP profile.

4 Methods

We enacted a process informed by Research-through-Design (Gaver et al., 1999; Boehner et al., 2007; Wallace et al., 2013; Zimmerman and Forlizzi, 2014) and qualitative semi-structured interview methods (Magnusson and Marecek, 2015). To vet the AP framework and identify potential benefits and pitfalls, we first engaged with PwDs on the centralized profiles and game-specific aspects of AP. Then, to complement PwD insights, we interviewed designer-developers to gain their insights on the implementation aspects of AP.

4.1 Study 1: technology probe with players with disabilities

4.1.1 Recruitment

We recruited 9 PwDs from co-authors' professional networks and social media platforms, including Twitch, YouTube, and Discord. For broader online recruitment, we reached out to Twitch streamers who have self-tagged themselves as a PwD, as well as gamers online who publicly self-identify as disabled. Additionally, we sent recruitment messages to the research team's professional networks and three Discord servers oriented around gaming and disability. Toward the goal of engaging with different communities within the disability umbrella, we aimed for a spread of participants with sensory, motor, cognitive, and psychosocial disabilities. See Table 1 for more information.

4.1.2 Semi-structured interviews with probes

Each PwD engaged in a 60–90 min semi-structured interview and probe session with the first author. Interviews began with questions about PwDs' current experiences with different game genres and existing accessibility tools. Then, PwDs interacted with AP microgame library probe, leading to critical design commentary, feedback on its role toward more inclusive gaming, and feature requests. Below we elaborate on our rationale for creating probes to explore centralized and game-specific aspects of AP.

4.1.3 Probe: game library

To improve our understanding of the player-facing aspects of AP, we created a technology probe: a game library that has centralized AP and game-specific accessibility settings. Our goal is to show PwDs how their global AP settings configuration would be interpreted by our three distinct microgames, and how they may additionally customize those settings locally. Below we articulate our design rationale for AP and integrated games.

In this probe, the accessibility features we focused on captions and high contrast mode. Captions are often expected for games with dialogue and sound effects, while high contrast mode is often expected for games where color comparisons are necessary for distinguishing game world information (e.g., enemy or ally). We chose these features because they would likely be familiar to participants and are well-established (Netflix, 2022).

On the game library homescreen, players may set “global” settings in an AP Instance. As shown in the “Applies AP setting via Secure Code or Sync” portion of Figure 2, the game library sends a player's AP Instance metadata to the microgames. Any particular game may have different interpretations of players' instances. For example, a game might interpret user's preference for Medium caption font size as either the middle point on a sliding scale or 12pt. After the AP Instance is automatically applied, players can further adjust in the in-game setting menu. See Figure 3 for screenshots of the microgame library, AP Instance, and local game settings.

Figure 3

The microgames are modeled after well-known games to reduce the time needed to learn to play. The microgames are Snake, modeled off of the classic fruit collection game; Grumble, a clone of the Wordle word guessing game with the addition of a snarky narrator; and Gem Run, a 2D platformer. See Figure 4 for player experience screenshots.

Figure 4

Additionally, our microgame collection reflects how accessibility feature relevancy and availability varies by games. Each microgame has different core mechanics (e.g., guessing a word) and ability assumptions (e.g., comparing colors) relevant to different game accessibility features. Table 2 shows which games use dialogue or color features as part of the player experience, and whether they include captions or high contrast mode.

For demonstrating how AP can communicate access features or lack thereof to players, microgames demonstrated how AP infrastructure can handle notifying users when requested accessibility options are unavailable. Specifically, the probe notified players if a requested setting was unavailable because it was not relevant, such as Snake having no caption-able dialogue or audio-only information systems, or because it was simply not implemented, such as Grumble deliberately not having a high contrast mode despite having elements that could be made more legible by one, as shown in Figure 5.

Figure 5

Altogether, the above design choices for profiles, games, and accessibility features created opportunities for PwDs to experience these scenarios: (1) configuring an AP Instance, (2) seeing how specific games apply an AP Instance locally, (3) perceiving availability of access features, (4) perceiving lack of access features. For more information, Please see Section 1 if the Supplementary material.

4.2 Study 2: interviews with game designer-developers

Whereas our first study explores how AP shapes PwDs' play-and-configure process, our second study aims to investigate the viability of incorporating AP into independent commercial game development.

4.2.1 Recruitment

We recruited five professional indie game designer-developers (IDs) from regional or resource-focused game development Discord servers. All designer-developers have designed and programmed several indie games using major game engines (Unity, Unreal Engine, Godot, etc.) by themselves and collaboratively. See Table 3 for more information. As we explained earlier in Related Work, since AAA studios operate within complex production pipelines (Kulik and Cairns, 2023), they likely require bespoke solutions. Therefore, we elected to focus on the experiences of IDs, who generally operate in a more fluid and legible ecosystem of popular game engines and self-publishing.

4.2.2 Semi-structured interviews

Professional indie game designer-developers engaged in a 60–90 min semi-structured interview with the first author. The interview first focused on designer-developers' prior and ongoing game development experiences; awareness and implementation of accessibility features in different contexts; accessibility for their target audiences; and motivations for implementing accessibility features.

The interviewer then described the AP framework, specifying how designer-developers would interact with the AP subsystems and asked about AP's potential, possible drawbacks, and requested features.

For the game designer-developers who also self-identified as PwDs, (or vice versa), the interviewer asked a combination of questions from both the PwD and designer-developer interview protocols. This subset of participants saw the microgame library probe, in addition to explaining the AP framework.

As such, designer-developer interviews provided further context on the pre-production and post-production considerations with AP, complementing the player-facing experience insights from the PwD probe sessions. Next, we describe how we put these responses in conversation with each other in our data analysis.

4.3 Data analysis

We engaged in an iterative data analysis process informed by Thematic Analysis methods (Braun and Clarke, 2012), Disability Studies (Hendren, 2020; Bennett et al., 2018; Ellcessor, 2016; Dolmage, 2017; Garland-Thomson, 2011; Kafer, 2013), Disability Justice (Piepzna-Samarasinha, 2018; Hamraie and Fritsch, 2019; Invalid, n.d.; Mingus, 2011), and Player-Centered Game Design (Zubek, 2020; Hunicke et al., 2004; Brown and Anderson, 2021).

We used an inductive approach where we were aware of existing theories but did not force them onto the data.

To prepare the dataset for collaborative analysis, transcripts from the interviews and workshops were obtained from Zoom live transcription and uploaded onto the ATLAS.ti qualitative data analysis platform. Then, the first author created an initial codebook based on the project's research topics (PwD experiences, designer-developer experiences, AP features) and their experience interviewing all participants.

To begin familiarizing themselves with the data and establish a shared understanding of the codebook's open-ended scope for analysis, all four authors individually and separately coded the same transcript. As we were memoing, we also encouraged each author to propose new codes or revisions to existing codes. The team then reconvened to iteratively discuss, merge, and refine existing and new codes to consolidate a second version of the codebook, which would guide coding and memoing for all other transcripts. At this stage, codes revolved around the tentative groupings of Access Goals, Access Profiles, Context, Current State of Play, Development, Hardware, Social Factors, and Systematic Concerns. Each transcript was then assigned a primary coder, who did the coding separately, and a secondary coder, who reviewed the codes. Both the primary and secondary coder assisted with checking transcripts and audio for accuracy. The entire co-authoring team then met several more times to consolidate and elaborate on codes, as well as share longer form memos about comparisons between different participants, coded segments, and technology-mediated interactions in game development (e.g., game engines, online communities, streamers, special events from game distributors) that could shape how accessibility is considered in different stages of a game's life cycle. Below, we describe how we developed and mapped themes several times before producing the current findings section.

4.3.1 First thematic map

After everyone completed both their primary and secondary coding assignments, the second author synthesized existing codes, tentative groupings, and memos into three potential themes: Supporting many goals for accessibility; Negotiating player-specific, game-specific feature sets; Bridging designer-developers and players. The rest of the team reviewed this three-section organization and integrated their curated quotes and memos into a full draft. However, as we continued writing the findings and other sections of the paper, we realized the substantial overlap between the findings draft in progress and existing publications on game accessibility. We then decided to temporarily discard our first draft of the findings, and then the second and third authors revisited the dataset for more analysis.

4.3.2 Second thematic map

While we used the same codebook and coded segments as before, we memoed specifically about the ways in which participants of different positionalities related to AP (e.g., discovery and configuration for PwDs, development support for IDs). We also focused on the nuances of how features would apply in different situations (e.g., on the one hand, the AP infrastructure can provide plug-ins for well-known accessibility features and on the other hand, it can provide informative examples for “unchartered” game accessibility features). At this point, when we made comparisons across memos from different participants, what stood out to us was the variety of individual, systemic, and technological factors that lead to accessibility features existing or not existing in games before PwDs open them. The underpinning phenomenon of how accessibility features are implemented in the first place is what motivated us to apply the lens of propagation, i.e., “the act of increasing the user base of an innovation” (Taylor et al., 2018).

After revisiting all participants' transcripts and meeting several times to compare memos, the second and third author then integrated their memos into a new set of potential themes: Current Experiences of Game Accessibility, Benefits of Access Profiles, and Hesitations about Access Profiles. In doing so, the corresponding sections would more clearly illustrate what the current experiences are with a lack of systematic propagation in game accessibility and how AP could align efforts from different stakeholders (PwDs, IDs, game engines, game distributors, etc.). After the whole co-author team reviewed the themes with the dataset as a whole, we decided to use the second thematic map and refined our work into the longform prose of the current findings.

4.4 Positionality reflection

We acknowledge how our lived experiences and values shape our qualitative research.

All of us are semi-professionals, instructors, or students in game development, as well as gamers. This background in both gaming and software development enabled us to build rapport with participants and understand both player and designer-developer experiences. Our training spans across computing, communication studies, and audio composition. This shapes how we understand game design as a combination of design, content, and programming. As academics rather than game companies, we tell participants we are not affiliated with corporate partners nor looking to make money from research. This is important for inviting honest feedback about the gaming landscape and the design probe.

As team members with different minoritized identities, we share a passion for making game spaces more inclusive underscores why we are conducting this study and how we envision our findings impacting the future. Based on prior experience with disabled communities in both academic and non-academic settings, we draw on Disability Studies to guide how we connect with disability culture and represent lived experiences. Important aspects of our approach include (1) resisting deficit narratives; (2) identifying inaccessibility in the built environment; (3) appreciating PwDs' pre-existing creativity; and (4) extending critical disability concepts into aesthetic domains. These aspects drive the subsequent Findings and Discussion.

5 Findings

Our findings are organized into three sections illustrating (1) indie game designer-developers' (IDs) and players with disabilities' (PwDs) current experiences of game accessibility, (2) benefits of AP for aligning stakeholders' engagement with accessibility, and (3) cautions about AP's broader uptake. Altogether, they showcase how AP has potential to intervene on the relationships between different entities of the gaming ecosystem as game accessibility continues to mature and evolve.

5.1 Current experiences with game accessibility

Within their game development training, IDs expressed a structural lack of emphasis on accessibility. ID2's curriculum at best “mostly discussed [accessibility] through the…basic user experience stuff” and at worst “never…really [discussed] accessibility.” Since accessibility is not currently a mainstream concern within the industry, many IDs “just didn't think of it” (ID3). Moreover, ID2 attested that they are hesitant to implement some accessibility settings because they “don't fully understand all the different spectrums of [a disability]” they would like to design for. These quotes show various responses to the lack of regulation and communal resources for ID-led game accessibility, despite aforementioned initiatives with Accessible Player Experiences (AbleGamers, 2019) and the Game Accessibility Guidelines (Ellis et al., 2016).

For IDs who do implement accessibility features, their knowledge of game accessibility is mostly self-taught and community-sourced, via reaching out to disabled gaming communities for feedback—“analyzing the games that they've played” (ID1)—and researching Steam forums or Reddit threads. P5, who is also a designer-developer working on an audio-only game, mentioned their work “to develop a network of blind and low vision people so that I can send my game to them to be like, ‘Please test this.”' Other designer-developers may implement features without explicitly testing them with PwDs. ID5 chose to include separate sliders for music and sound effects in one of their games because “some people want might want to play with their own music and some people might not be able to hear as well if there is music, so it's just all those factors, accessibility being one of them” (ID5). These contrasting examples show how game designer-developers approach accessibility feature implementation through a variety of disability and non-disability specific motivating forces.

Acknowledging that there is no one-size-fits-all approach to accessibility, PwDs do not look for exhaustive implementation of accessibility features, but rather iterative and transparent efforts from IDs. P7 noted that if IDs “show me transparently that you realize you have an [accessibility] issue, that makes you trust you more”, as well as emphasized the importance of studios signaling to the players that they have consulted with members of disabled communities. Similarly, P5 remarked that while we could only “scratch on the surface of things like cultural and psychological accessibility,” there are “big, obvious things that are easy to deal with” in accessibility development that could be the baseline for game development. This suggests a need for clearer signaling to bridge this gap between IDs' approach to game development and PwDs' access needs, and aligns with AP's design intentions as a communication framework.

While we acknowledge the importance of building effective player-developer paradigms, the responsibility to promote and implement accessibility should not fall on individual IDs or PwDs. Both PwDs and IDs called attention to inaccessibility ingrained the gaming ecosystem's nodes, such as game retailers. P2 and P4 shared that certain online game retailers' stringent no-return policies and lack of game demos mean they often unknowingly bought expensive, unplayable games. P7, while trying to access a sales event, had a seizure because of a banner's graphical animation. Despite retailers' prominent role in displaying and selling games, their game tags are often vague and not helpful to PwDs' discovery process (P2). On the designer-developer front, ID2 noted that existing resources, such as the game engine Unreal's colorblindness simulation feature, need to go beyond only “simulating” issues of accessibility and “tell people how to solve these things and break it down.” These findings illustrate how the base affordances of retailers and game engines can improve or worsen the odds of accessible game implementation and discovery, which corroborates AP's efforts to intervene on them as part of infrastructure.

Current platforms for player-developer dialogue about accessibility have areas of improvement. Existing channels of communication (e.g., Steam forums, in-game feedback buttons) are either overloaded with general feedback or can be unsafe for PwDs to communicate their access needs. P7 explained that they often get no meaningful replies to their reports or garnered hate on public forums for speaking out about inaccessibility. For example, P7's post about which parts of a game induce seizures was “competing for attention with a dude who is convinced that the autocannon is underpowered.” While inaccessibility can cost PwDs time and money (e.g., the purchase of an inaccessible game), it could also bring about bodily harm (e.g., seizures). Again, these findings call for more immediate and serious interventions in shared infrastructure (e.g., game engines, retailers, forums) from stakeholders who are not designer-developers and players.

Within this landscape, we position AP as a communal resource that improves awareness, manages expectations, and provides better workflows for PwDs and designer-developers. Building on the multi-pronged commentary from this section, we proceed to show how AP can impact different aspects of game accessibility.

5.2 Benefits of access profiles

Grounded in both designer-developer and PwD perspectives, we describe below how AP can be a mediator to incorporate accessible design resources into game implementation and configuration practices.

5.2.1 For designer-developers

When presented with the AP framework, designer-developers reflected on AP's potential to support (1) prototyping practices and (2) game customization.

Improving prototyping revision workflows for game accessibility. Game designer-developers confirmed that AP's features for informing and implementing features would lower barriers to developing accessibility features. For example, current game engines do not have native support for common accessibility features such as font changes or captions. In a game supporting font options for accessibility, an AP plug-in could enable IDs to link all game text as AP actors and change their font with a single function call from an AP manager. ID5 affirmed “that would be great, as I don't have to manually kind of change every font when I create it, which takes a bit of time [and is] annoying.” Digital games contain a myriad of game objects in their data structures, so this streamlining of “annoying” editing labor is especially important when there might be a shortage of programmers in an indie game studio. For example, ID3 described how a company he formerly worked at only had “three other people who actually enjoyed coding, everyone else wanted to do 3D modeling or game [player experience] design.” The quotes above highlight AP's potential to intervene on what is happening in a game engine to support revisions across many game objects at once that are relevant to a given accessibility feature. Across different prototype versions, this can save designer-developers additional time and effort in responding to revisions from other subteams (e.g., visual art, sound art, writing) and playtesting feedback.

Integrating across different motivations for customization. IDs reflected on how the AP framework can benefit both PwDs and the greater whole of their player audiences. Designer-developers stated that they saw AP's appeal for both access needs and non-disability related factors. ID1 connects AP to PC gamers' enthusiasm for configuration: “If you were trying to get more people on board, maybe spinning it as a 'Settings Profile,' because PC gamers, especially, they love their settings. So we could market it like: 'This would help you keep your settings across all your games!”' Regarding specific features, ID5 remarked on how audio sliders and keybindings have similarly become “something that you know everybody wants, but it's also an accessibility feature.” During our analysis, we noted the resemblance between these statements and historical dialogue about how accessibility features can benefit more than just a disabled community (Dolmage, 2017; General Services Administration, 2017; Washington, 2025). This surfaces tensions about whether to ‘brand' AP as something affiliated with disability and accessibility or as a general-purpose tool. Nevertheless, we advocate for foregrounding PwDs' perspectives and experiences in the usage of APs, which we elaborate on next.

5.2.2 For players with disabilities

PwDs currently go to great lengths to scour through settings menus and third party sources to determine the odds of a specific game being playable given their access needs. PwDs confirmed that AP could reduce the overhead costs of (1) discovering accessible games, (2) configuring games the first time they open it, and (3) reconfiguring games when experiences of disability and access needs fluctuate over time.

Discovering accessible games. PwDs expressed enthusiasm about AP's potential to have accessibility features as parameters for searching game stores. P5 expressed “if I could go into Steam and I could search like I need—I wanna find games that are in this category, and have these like lists of accessibility features, whether it's need[-to-have] or optional…and then get a list of games that fulfill that criteria, that would be awesome.” This quote describes how the search-related feature of AP would not exist in a vacuum. AP's tags could be combined with search parameters for other categories, such as single vs. multiplayer, genre, ratings, etc. P2 explained that an accessibility feature-based search would be an improvement over their current approach of trying to glean this information from reviews: “When you're looking at reviews and you're looking at, it's somebody's opinion, right?…I wish reviews went more into like the settings menus and what you can toggle. Like for a racing game: Is there an auto accelerate?” By incorporating communication of accessibility features into different parts of the gaming ecosystem, we infer that AP can begin to provide more accessibility-based lenses in publicity for games across different channels.

Configuring games when first opened. PwDs responded positively to AP's library-level features to apply settings upon loading a game for the first time. Regarding the usage of AP Instances, P1 appreciates that “I can just type in a code, and no one else has to know anything else about me,” which contrasts with their experiences in other contexts of “hav[ing] to divulge so much information about [myself] to get like basic accommodation[s].” Because AP is not ingrained with clinical diagnosis procedures and documentation, its benefits are not locked behind identity disclosure or paperwork barriers. Additionally, P5 states “I think it's [AP Instances] an excellent idea from a privacy point of view. I would just be wary of adding too many steps in implementation... Because when you start doing privacy, there's always quality vs. quantity. It's like 2-factor authentication. It's more onus on the user, but they can't have it both ways. They can't want it to just be really fast and easy, and then also have all of this extra security.” This is a reminder to ensure that AP's configuration processes do not become barriers in themselves. P8 also affirms this feature would “save me so much work on the back end from having to go in [settings menus], and I can just be excited for the game, and just start playing, which is exactly what I want to do. I don't [currently] have the luxury of doing that.” Here, P8 implies that they already dedicate substantial overhead to settings menus, and interventions like AP to streamline that process would be a quality of life improvement. This feature is especially helpful for access needs that PwDs know a priori, such as reducing the amount of simultaneous button presses (P5), reducing graphical intensity (P7), or showing captions (P1). Yet, we acknowledge that accessibility continues to evolve as games evolve as a medium. These findings motivate additional strategy around how to represent known and novel accessibility features upon load, which we elaborate on in the Discussion.

Configuring games when disability and accessibility experiences fluctuate over time. PwDs also considered the benefits of AP in a longitudinal time scale. For example, P8 explained their access needs may vary if they are or are not “having a good day with my joints.” In a similar vein, P5 put AP in conversation with the dynamic aspects of chronic illness: “People with chronic pain or mental health conditions, you're not gonna know, like you're not gonna know [symptoms] in advance, and the ability to change your [settings] as you play or day to day, like ‘Yep, temporary setting of this. I want to set it for X number of hours or X number of days, because I'm having a flare up' or ‘For the next 2 hours need the brightness to be quite low, because I'm really sensitive right now.”' Here, P5 nuances the AP infrastructure by adding a time dimension to an AP Instance. These findings motivate longitudinal observations of how AP can change as lived experiences of disability and accessibility change.

Above, we highlighted how AP has the potential to intervene on game development or configuration in situ. Instead of game accessibility information existing outside of game engines or stores, AP can assist designer-developers with revising in game engines and assist players with expectation-setting and configuring games upon load. In doing so, AP can improve the likelihood of designer-developers prototyping accessible design choices and PwDs having to do less work before playing. Yet, informants anticipated pitfalls on the way to AP achieving these benefits, which we share next.

5.3 Hesitations about access profiles

Given the communal nature of AP, both parties expressed concerns about feasibility and consistency at scale. Designer-developers wondered about how AP would mix with their prior and current game projects, while PwDs were optimistic but skeptical about how well games and platforms would follow through on the features that AP could signal. As the researchers, we interpret these statements as insights toward making AP more robust and useful.

5.3.1 For designer-developers

While designer-developers were not opposed to AP, they mentioned several factors that would impact their likelihood of adopting it. These factors revolved around the need for AP to be (1) applicable across different genres and types of games, (2) incorporated early in a game's lifecycle, (3) accompanied by high-quality educational resources.

AP support for games may vary by genre. When IDs considered AP for previous or ongoing projects, they wondered whether AP could support the different genres in their portfolios, especially the less conventional ones. For example, ID5 reflects on how AP could be applied to their grand strategy game in comparison to more “generic games,” since “there's so many different kinds of controls [e.g., custom keyboard shortcuts].” Yet, this designer-developer does not yet realize that control remapping is a relatively well-known feature they could apply. Due to lack of genre-specific sensitization, some accessibility feature implementations may not be immediately clear to designer-developers. These findings imply that genre-diverse examples or developer logs would be a beneficial addition to AP. These resources could inform when generic AP plug-ins could be used or when it is worthwhile to explore unchartered accessibility features. We revisit this concern in terms of “mature” and “nascent” features in the Discussion.

AP integration might be challenging for projects in later stages of development. Upon reflecting on how AP would fit into their process, designer-developers noted that it would be substantially easier to implement AP early on. For example, ID3 attested that they might have to make numerous changes when implementing a color blind mode in the later stages of development. This is not an AP-unique comment, as it echoes previous research and practice (Kulik et al., 2021; Lazar et al., 2015) to consider accessibility early and often in the design process. However, since IDs work with constrained resources, the cost of project revision after AP integration is a legitimate concern, and we do not want to discourage designer-developers who find AP “late” in their development process. With these findings in mind, we revisit the topic of how to support designer-developers in different stages of their accessibility journey in the Discussion.

AP can benefit from having multi-modal educational resources other than documentation. Drawing on what they find impactful in their existing workflows, designer-developers suggested additional pieces of infrastructure to support an ongoing learning journey about accessibility and AP.

Additionally, building on existing content platforms for learning game development, “having someone well-known, like Brackeys⁸ make [educational resources] for you would go a long way in getting more people to actually learn about it [and] trust it more, because people trust Brackeys” (ID3). While outside the scope of the current probe, these findings indicate the importance of community building, publicity, and spheres of influence within the gaming ecosystem for AP.

5.3.2 For players with disabilities

Reflecting upon their current experiences with inaccessibility, PwD anticipated different stakeholders misusing AP. They stated that AP (1) does not guarantee effective accessibility implementation, (2) might be used to check off a box and provide false signaling, and (3) might break game immersion.

AP involvement does not guarantee effective accessibility implementations. While PwDs were optimistic about AP as scaffolding for IDs to develop more accessible games, they were concerned about “how well-integrated into the game” (P1) AP would be. Upon being shown the AP instance before engaging with specific microgames, P8 was worried that their accessibility configuration in the Access Hub would not be translated appropriately into the game upon launch. The responsibility still falls on IDs to configure where to place AP actors and managers within their game, and to consider what the player experience would look like with accessibility settings active. Using AP and importing AP code plug-ins into the game engine does not abstract away the importance of playtesting accessibility features and obtaining feedback from disabled gaming communities.

AP might be misused to check off the accessibility box and provide false signaling to PwDs. Within the AP infrastructure, games would be able to signpost their compatibility with AP and which accessibility features are offered on their storefront. In response to this feature, P1 emphasized the need for designer-developers to offer “clarifications on what it is [the game] actually have” because they were wary of games that claim to “meet all accessibility needs, and they don't really do it in a way that's actually helpful.” Indeed, many IDs mentioned that AP would not only sensitize them to accessible development, but also boost visibility for their game via AP tags. To provide accountability, P5 also states that “having a third party is a really good option... you can work with a third party to remain consistent and then basically say to producers and your big companies that this is the format you need to adhere to.” Here, P5 points out that having AP processes be separate from the companies' attempts to make profits reduces the odds of misuse. Given PwDs' past experiences with inaccessible games and the stakes involved in gameplay, the AP infrastructure needs to provide mechanisms for IDs to demonstrate thorough engagement with accessibility implementation and for PwDs to report inaccurate tags. This indicates how accountability mechanisms are necessary for AP to be a reliable infrastructure.

AP in-game signposting of available accessibility features might break game immersion. In an attempt to signpost which accessibility settings from AP Access Hub were inherited, the game library probe displayed a pop-up text box on the microgame's home screen. To this, P4 said that “it disrupts the experience of the game” and suggested more subtle signposting in order to not break game immersion. While the pop-up text box was meant to signpost which accessibility features were present, which was metadata that other PwDs (P1) have expressed interest in knowing, accessibility features need to be treated like any other design elements and go through testing and prototyping in order to achieve game immersion and the ID's artistic vision. Regarding the design of AP infrastructure, these findings surface the tradeoff between perceptibility and unique game aesthetics that AP can revisit in future work, especially when AP is deployed at a larger scale with more games and genres.

6 Discussion: toward communal practices for game accessibility

Game accessibility continues to evolve as game genres evolve. We are in an exciting time period where we have substantial game accessibility venues (e.g., ACM's CHI, CHI PLAY, and ASSETS, as well as the Game Developers Conference⁹ and Access-Ability Showcase¹⁰), collections of guidelines and design patterns (Ellis et al., 2016; Accessible Games by The AbleGamers Charity, 2022), and journalism (Dale, 2015), as well as a growing body of commercial games who implement some or many accessibility features. Yet, both designer-developers and players on the ground face difficulties with implementing or identifying accessible games because of a lack of shared language and workflows when every game world is unique. In other words, designer-developers grapple with “What does accessibility look like in my game and how do I implement it?” while players navigate “Who is this game built for and how can I make it accessible to me?” This calls for improvements in communal processes for game accessibility, especially as many designer-developers do not already have Disability Studies or accessibility expertise.

Looking beyond individual studies and products, the present paper explores infrastructure to collectively stay on an iterative and improving path for diverse disabled participation. Specifically, we make a call to action to understand and design for accessibility as a cross-stakeholder intervention: support the innovators and advocates who are blazing new trails; onboard the critical mass of designer-developers who do not already know about disability and access; make existing accessibility features easier to implement in industry standard game engines; and provide shared language for platforms to mediate communication between designer-developers and players. We emphasize that AP infrastructure is a process, not a static certification or checklist. Building on our study and prior theorizing on propagation (Hovey et al., 2023; Henderson and Dancy, 2007; Rogers, 2003; Taylor et al., 2018), we present both conceptual and practical contributions toward this multi-pronged mission.

6.1 Using Access Profiles infrastructure to propagate mature and nascent game accessibility features

Propagation of accessibility features is currently happening in bits and pieces through designer-developers' ad-hoc examination of prior art and varying personal connections to disabled communities. To establish a more systematic propagation of accessibility features, AP inscribes game engines, distributors, and launchers as critical sites for propagation. In a shared commitment toward accessible and player-centered gaming experiences, we advocate for lowering the barriers for indie game designer-developers—who are often working under resource constraints and implementing less conventional game elements—to design with a broad range of access needs and different minoritized communities in mind.

Rather than present new features, AP intervenes on how designer-developers are doing the work of creating accessible games. In doing so, we aim to increase the prevalence of accessibility features and the possibility of them working compatibly with each other. Depending on the feature, AP can either aid with most of the implementation or provide guidance on exploring novel accessibility features. In addition to improvements to game products, our underpinning goal for designer-developers' professional development is a game-specific version of Henderson and Dancy's levels of cognizance for propagation (Henderson and Dancy, 2007): (i) awareness of the practice [accessibility features], (ii) how to implement it [in the game engine of their choice], and (iii) understanding why it works [i.e., how players relate to it in their unique game world]. Below, we explain how AP's key features—particularly plug-ins, documentation, and tags—can support the propagation of mature (i.e., commonly practiced accessible design patterns) and nascent accessibility features over time.

6.1.1 Propagating mature accessibility features

We characterize mature accessibility features as being prevalent across existing games and may be seen in other media contexts. Mature features are often something that people with disabilities likely have prior knowledge and experience with, and already have clear guidelines for their implementation. For example, captions for both sound effects and dialogue are common in many games and other audio-visual media, and clear guidelines, such as Netflix's “Timed Text Style Guide” (Netflix, 2022), exist for this feature. Similarly, high-contrast modes and color-blind accessible modes are also seen in many games and websites, and have design guidelines, such as in APX's “Distinguish This From That” section (AbleGamers, 2019). Mature accessibility features are also less likely to have major variation within and across genres. However, despite their prevalence, many of these features are not natively supported in game engines. For instance, Unity does not include captioning features out-of-box, whereas differentiated volume controls are more intuitive to implement in popular game engines (see Findings 5.1). In the same way that we would not want to burden website designer-developers with re-inventing image alt-text and BLV users with verifying every instance of alt-text implementation, we argue that the issue of limited mature feature propagation is in large due to the lack of in-engine support. By streamlining these features within the game engine, we can encourage designer-developers to implement best-practice accessibility features by default, even if they are not willing or able to test these features with PwDs.

Toward reducing collective overhead for implementing accessibility features, our system design and findings show AP can utilize (1) AP plug-ins to guide the revision and implementation of specific accessibility features, and (2) AP tags to indicate presence of up-to-standard accessibility implementations. In the case of (1), designer-developers could immediately start implementing and previewing accessibility features within their games. Regarding (2), the centralized list of AP tags can ensure that despite games all being unique, we will have a shared notation for whether accessibility features are available. This can improve players' experiences with “discovery” and “evaluation” of accessibility in new games (Martinez et al., 2024). Building on the potential of tags and experiences mentioned in Section 5.3.1, informants requested an additional layer of quality control with verification by a third party sensitized to access needs, similar to how they already seek out third party reviews or streams to vet the accessibility of a game. Especially when some access needs are too nuanced to be encapsulated by a tag, detailed accessibility-focused reviews and streams remain a vital part of the gaming accessibility ecosystem.

6.1.2 Propagating nascent accessibility features

We characterize nascent accessibility features as features that PwDs are very unlikely to have previously encountered, do not have established design guidelines, and are likely being actively researched/designed. Therefore, PwDs are unlikely to predict whether or not a nascent feature that is completely novel to the player would benefit them before opening a game. For example, Nair et. al created “exploration assistance” mechanics for blind and low vision players to experience discovery of new places and objects in game worlds (Nair et al., 2024), which contrasts with how many assistive navigation tools (e.g., non-visual GPS Fleet, 2019) will lead blind and low vision users directly to the target object or destination. We note that the “nascent” descriptor is not set in stone; it is possible for nascent features to eventually become mature features with successful propagation and documentation. The variety of nascent accessibility features goes hand in hand with how indie games are known for experimenting with genres by including both classic game tropes and subversions thereof. Indeed, games such as Moss (PolyArc Games, 2018) and Chairdevil (Bobby Lockhart, Andy Saia, 2024) have explored how disabled ways of being can be jumping off points for character design and mechanics. As such, nascent accessibility features are likely to require more playtests and deliberation than the mature features mentioned above. We aspire for AP to create the opportunities for designer-developers to propagate the nascent accessibility features in their specific game to future games.

Toward supporting designer-developers' design and propagation process for nascent accessibility features, our system design and findings show that AP can (1) let designer-developers self-identify which mature AP tags are related to their nascent features to bring to a new player's attention, (2) utilize AP tags to provide analytics about players' access needs and preferences to guide development and prioritization of accessibility features, and (3) diversify available resources for designer-developers to consult during the AP integration and overall design and development process. Regarding (1), while nascent feature tags will not already exist in AP's centralized tags list, IDs can self-designate recommendations for what nascent features could be applicable to users of existing mature features. For example, caption users may be interested in nascent features that visualize audio cues. Regarding (2), the AP infrastructure could help IDs track engagement analytics for when players interact with the features they have implemented. This would help IDs understand how their players are interacting with their implementations, and be informed if they decide to move forward with implementation or playtesting. AP tags could also provide data at the community scale on how many other games are developing accessibility features for a certain genre, or even game mechanics to showcase and connect different designer-developers' approaches. Regarding (3), IDs (Findings 5.3.1) proposed that in the future, the AP infrastructure community, including both designer-developers and players, can contribute to the expansion and propagation of accessibility features by exchanging information via online forums, writing new documentation, and creating step-by-step video tutorials for AP. Additionally, the AP infrastructure could be introduced in computing curricula as a design tool to sensitize designer-developers-in-training foregrounding accessible design in the earlier stages of development.

6.1.3 Signs of successful propagation

We anticipate several signals of successful propagation with AP. Regarding mature accessibility features, we envision the majority of new games having them implemented or recognizing those features are not applicable to their game, and then having that information clearly conveyed on store pages where players would typically download or purchase games. This is intended to be an upgrade in consistency and quality over the current trial-and-error experiences with individual game settings menus, and is already seeing mainstream implementation (Entertainment Software Association, 2025). Regarding nascent features, we expect to see a lively dialogue and new plug-ins based on accessible designs situated in different game worlds. This is an evolution of the skillshare that already occurs through game journalism, developer logs, and design patterns (Accessible Games by The AbleGamers Charity, 2022) taught in practitioner courses. Additionally, as nascent features propagate, some of them may transition into mature features that players can name off-the-cuff and expect for future games.

Engaging with our informants reinforced the need for AP to be upheld by a third party outside of companies and platforms. If a full AP central were to be developed, it would require dedicated moderators, software maintainers, and other resources to enact the quality control, updates to documentation and plug-ins, and advocacy to platforms. To ensure player trust is maintained in AP central, members of AP central or related game-accessibility organizations could test and verify the functionality of accessibility features in a given game. Resources will likely not be available to verify every game, therefore a system of community rating and reporting would be needed to cover non-verified games as well as catch anything the verification team may have missed. In addition to this, several privacy related features, such as allowing PwDs to select which games can access their AP, are required would need to be developed to ensure user privacy is maintained. This triangulation of access labor between developers, platforms, and players has to be overseen and supported by AP as a third party.

By strategizing for both mature and nascent features, it appears possible to systematically raise both the floor and ceiling of game access through the careful implementation and detailed design of a system like AP. That is, in a future with AP, mature features would become easier to implement. Additionally, nascent features would be prototyped more frequently and spread to new players by the ability to suggest relevant nascent features to users of mature features. For example, games could suggest the nascent feature of an audio-radar map (Nair et al., 2024) to users with AP Instances specifying high contrast mode and text-to-speech. In addition to different supports for different features, designer-developers can also vary in how they relate to AP. Developers who are just getting started with game accessibility can immediately get hands-on practice with plug-ins, while designer-developers who already have substantial sensitization and experience can contribute their innovations to AP Central. The next subsection elaborates on our understanding and support for designer-developers at different stages of their accessibility journey.

6.2 Understanding designer-developer responses to raise the floor and ceiling of game accessibility

To collectively improve game accessibility, we must understand designer-developer's responses to being probed to implement access. Prior propagation literature has identified how adopters of innovations can differ based on the timeliness of their adoption: innovators, early adopters, early majority, late majority, and laggards (Rogers, 2003). We adapt this progression to be more specific to game accessibility by putting designer-developers' attitudes about accessibility in conversation with their development actions and how they might relate to the AP infrastructure.

Active Ableism. Unfortunately, there are designer-developers who believe that PwDs should not be able to play games in general, or a particular game for socio-political reasons¹¹. AP, or any tool alone, can do little to combat this (Wolbring, 2008).

Access Apathy. Some designer-developers (ID2, 3) expressed a lack of prior knowledge and awareness around accessible design (Findings 5.1). For designer-developers who look to prior games for example implementations or touchstones (e.g., ID1, 5), a feedback loop forms when those games also lack the same accessibility features. AP's non-exhaustive list of accessibility features can help sensitize these designer-developers to a wider array of accessibility features currently in games, as well as the prevalence of players who utilize those features.

Access Freezing. However, even when designer-developers are sensitized to an access need, they are not always equipped to design for it, as suggested by ID2's reflections on Unreal's colorblindness simulation feature (Findings 5.1). This “access freezing” can stem from not knowing enough about accessibility, not knowing where to look for the information, or a fear of the harm that implementing an accessibility feature incorrectly might cause. For these designer-developers, AP could provide access to a centralized resource with guidance and examples of common features.

Access Patchworking. Some designer-developers are aware of access needs and potential feature implementations, yet still struggle to implement features. This can stem from implementing features at a late stage of development (ID3, Findings 5.3.1) or from lacking requisite experience, time or other resources (ID3, Findings 5.2.1). For these designer-developers, plug-ins to help develop quickly could introduce them to features they might otherwise have little time to implement, and coherent documentation would help educate them further where their knowledge is lacking. Additionally, AP could help designer-developers make informed choices about what features are feasible to incorporate if time and budget are limited.

Access Implementing. Some designer-developers choose to implement accessibility features by default, especially well-established features like differential volume sliders for music and sound effects (ID5, Findings 5.1 and 5.2.1). However, they might not explicitly test these features with PwDs. The benefits of AP to these designer-developers would include guidelines to confirm they are on the right track with implementing various features (e.g., self-assessing that their captions are not covering up other important game information), as well as a store- or library-level tag integration, which would enable them to signal the features available and in turn, streamline PwD's process with investigating whether a game supports their access needs and the configuration before playing the game. Additionally, AP could bear some of the burden of responsibility for decisions like caption size and alternate fonts, which might make designer-developers more amenable to implementing mature features with reduced fear of being directly criticized by players for their implementation.

Access Innovating. Finally, there are designer-developers who are developing with accessibility in mind and are on the frontier of accessibility-focused innovation in games. Designer-developers like P5 heavily involve PwDs in their process (Findings 5.1). These designer-developers are actively testing new features or re-imagining standard features. AP may not explicitly be able to provide tags for these features, but it could support designer-developers in other ways, like by allowing them to signal features to relevant players. For example, if a designer-developer released a game with a new type of audio visualizer, they could provide a pop-up for players who have captions enabled in their AP preferences inviting them to try the new feature. We also anticipate that these designer-developers would be valuable contributors to AP's evolving resources, for example, contributing formative examples for new plug-ins and participating on AP designer-developer forums.

6.3 AP principles for game design and development

Acknowledging that everyone is at different stages of their accessibility journey, we articulate guiding values for the AP community. We provide these principles to be immediately actionable for game designer-developers reading the present paper:

• Streamline Explicit Communication:

  One of AP's core goals is to encourage efficient, explicit communication between designer-developers and PwDs. Therefore, future systems that utilize the AP framework (which this principles list will refer to as “AP systems”) should prioritize features that enhance this communication such as the ability to add nuanced, clarifying information to simplified store tags. In doing so, AP will only store information about features and games, not players' personally identifiable information.

• Center Nuanced, Personal Experiences of Disability: The experiences of PwDs differ widely from person-to-person, but also from moment-to-moment within the same player. It is therefore important to incorporate the ability for a single player to have multiple profiles/instances of an AP from which they can easily select when launching a game.

• Respect Context: AP systems should respect that the local context of a specific game is more relevant than global AP preferences. This could be done by the AP only being called on initial launch or when explicitly called by the player to reset the current settings to a specific AP profile/instance.

• Empower Designer-Developers and Encourage Learning: Designer-developers are incredibly diverse in their motivations, previous experience, and aesthetics goals. AP systems should accordingly attempt to create a culture of learning and support, as opposed to one of fear and chastisement. This can be achieved through clear and thorough documentation with examples, easily accessible video tutorials, and plug-ins to support rapid implementation in popular game engines where possible.

• Honor the Difficulty of Design Decisions: Creating digital games is complex, challenging, and time/resource intensive. As a result of this, it is not feasible to include every feature a designer would want into the final game. AP systems should therefore support designer-developers in consciously deciding which accessibility features are most relevant and realistic to include in their games.

• Embrace Experimentation, Innovation, and Re-Factoring: Accessibility is not a fixed target, nor is it a goal we will ever exhaustively reach. Access is an ever-evolving process. Therefore, AP systems should be designed in a flexible way that allows for designer-developers to experiment with alternate implementations of a feature and for the list of supported features to grow and change.

• Triangulate PwDs, IDs, and AP's bodies of knowledge: Accountability structures are important for ensuring that AP tags and related signals are reliable, especially given the dynamic aspects of game accessibility mentioned in the previous principles. Therefore, AP systems should enact recurring review of IDs' tags, PwDs' community reports, and its own resources over time.

6.4 Limitations and future work

This project included PwDs and IDs. While we recruited participants from a variety of countries and cultures, future work could explore cultural factors that may impact AP. The PwDs recruited all have extensive experience playing digital games, and future work could explore how AP might better onboard PwD with less experience. Our participants did not include designer-developers in AAA studios. Future work could explore ways to support large studios in integrating AP into their complex production pipelines. Additionally, only a medium-fidelity micro-game prototype was used as opposed to a library of commercially released games. The micro-game prototype was the only aspect of the system that was developed for the present paper, and future work could explore the implementation of other aspects of the AP framework in more detail. The design of an AP at scale raises numerous avenues for exploration ranging from the UX of PwD inputting their preferences, the tradeoff between perceptibility and aesthetics of AP signals (see Findings 5.3.2), how to best support a diversity of designer-developers using game engines, and how privacy and player agency maximized throughout the process.

Additional crucial implementation details such as data structures, encryption, and API integrations will also need to be carefully examined to make AP effective and secure at scale. Future work deploying AP at scale could explore this and many other questions and could incorporate a larger sample size and include longitudinal data collection. While the project did include a variety of disabled communities, future work could expand on how additional PwD perspectives provide nuances and more specific propagation advice for mature vs. nascent features.

7 Conclusion

Game accessibility is unpredictably different across genres and therefore not possible to capture in a static resource. This motivates us to develop infrastructure to represent accessibility features in a situated and evolving way, while still being concrete enough for ease of implementation. In contrast to prior work about accessibility of specific game elements, the present paper aligns indie designer-developers' and PwDs' experiences with accessibility feature implementation. We contribute Access Profiles (AP), a framework to streamline communication of accessibility preferences between players and games. Responses to AP design probes in qualitative interviews affirm the potential of this infrastructure to improve implementation and configuration, and highlight important design considerations for AP to be useful at scale. We discuss how AP can be both player-centered and designer-developer-supported by supporting clearer communication of what accessibility features are available and scaffolding the propagation (Hovey et al., 2023; Henderson and Dancy, 2007; Rogers, 2003; Taylor et al., 2018) of mature or nascent accessibility features within game engines. In combination with ongoing efforts to raise the floor and ceiling of game accessibility, AP can become part of the greater whole of player-centered design practices to co-create the future of accessible gaming.

References

• 1

  AbilityPoints (2018). Can I Play That? Available online at: https://caniplaythat.com/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 2

  AbleGamers (2019). Accessible Player Experiences (APX). Available online at: https://accessible.games/accessible-player-experiences/ (Accessed April 12, 2025).

  • Google Scholar
  • View reference in article

• 3

  Accessible Games by the AbleGamers Charity (2022). Design Patterns: How to Use Design Patterns for APX. Available online at: https://accessible.games/accessible-player-experiences/design-patterns/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 4

  AckermannP.VelascoC. A.PowerC. (2012). “Developing a semantic user and device modeling framework that supports ui adaptability of web 2.0 applications for people with special needs,” in Proceedings of the International Cross-Disciplinary Conference on Web Accessibility, W4A '12 (New York, NY: Association for Computing Machinery). doi: 10.1145/2207016.2207018

  • CrossRef
  • Google Scholar
  • View reference in article

• 5

  Aguado-DelgadoJ.Gutiérrez-MartínezJ.-M.HileraJ. R.de MarcosL.OtónS. (2020). Accessibility in video games: a systematic review. Univ. Access Inform. Soc. 19, 169–193. doi: 10.1007/s10209-018-0628-2

  • CrossRef
  • Google Scholar
  • View reference in article

• 6

  Arielle Silverman (2017). On People With Disabilities, Also Known as Disabled People. Available online at: https://www.disabilitywisdom.com/2017/03/31/on-people-with-disabilities-also-known-as-disabled-people/ (Accessed April 10, 2025).

  • Google Scholar
  • View reference in article

• 7

  BennettC. L.BradyE.BranhamS. M. (2018). “Interdependence as a frame for assistive technology research and design,” in Proceedings of the 20th International ACM SIGACCESS Conference on Computers and Accessibility (New York, NY: Association for Computing Machinery), 161–173. doi: 10.1145/3234695.3236348

  • CrossRef
  • Google Scholar
  • View reference in article

• 8

  Bobby Lockhart Andy Saia. (2024). Chairdevil.

  • Google Scholar
  • View reference in article

• 9

  BoehnerK.VertesiJ.SengersP.DourishP. (2007). “How hci interprets the probes,” in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI '07 (New York, NY: Association for Computing Machinery), 1077–1086. doi: 10.1145/1240624.1240789

  • CrossRef
  • Google Scholar
  • View reference in article

• 10

  BraunV.ClarkeV. (2012). “Thematic analysis,” in APA Handbook of Research Methods in Psychology, Vol 2: Research Designs: Quantitative, Qualitative, Neuropsychological, and Biological (Washington, DC: American Psychological Association), 57–71.

  • Google Scholar
  • View reference in article

• 11

  BrownM.AndersonS. L. (2021). Designing for disability: evaluating the state of accessibility design in video games. Games Cult. 16, 702–718. doi: 10.1177/1555412020971500

  • CrossRef
  • Google Scholar
  • View reference in article

• 12

  CairnsP.PowerC.BarletM.HaynesG.KaufmanC.BeestonJ. (2021). Enabled players: the value of accessible digital games. Games Cult. 16, 262–282. doi: 10.1177/1555412019893877

  • CrossRef
  • Google Scholar
  • View reference in article

• 13

  Center for Disability RightsInc. (2024). Disability Writing and Journalism Guidelines. Available online at: https://cdrnys.org/disability-writing-journalism-guidelines/ (Accessed April 10, 2025).

  • Google Scholar
  • View reference in article

• 14

  ClarkJ. (2006). To Hell with WCAG 2. Available online at: https://alistapart.com/article/tohellwithwcag2/ (Accessed August 25, 2025).

  • Google Scholar
  • View reference in article

• 15

  ClarkM. O.SinghA.BarbareschiG. (2023). Towards greater inclusion and accessibility for physically disabled players in location-based games. Proc. ACM Hum. Comput. Interact.7, 699–720. doi: 10.1145/3611046

  • CrossRef
  • Google Scholar
  • View reference in article

• 16

  DAERSystem provided by Apex Access (2021). Accessible Games Database.

  • Google Scholar
  • View reference in article

• 17

  DaleL. K. (2026). LauraKBuzz - Official YouTube Channel. Available online at: https://www.youtube.com/LauraKBuzz/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 18

  DolmageJ. T. (2017). Academic Ableism: Disability and Higher Education.Ann Arbor, MI: University of Michigan Press.

  • Google Scholar
  • View reference in article

• 19

  EllcessorE. (2016). Restricted Access: Media, Disability, and the Politics of Participation. NYU Press.

  • Google Scholar
  • View reference in article

• 20

  EllisB.Ford-WilliamsG.GrahamL.GrammenosD.HamiltonI.LeeE.et al. (2016). Game Accessibility Guidelines. Available online at: https://gameaccessibilityguidelines.com/full-list/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 21

  Entertainment Software Association (2025). About the Accessible Games Initiative. Available online at: https://accessiblegames.com/about/ (Accessed August 30, 2025).

  • Google Scholar
  • View reference in article

• 22

  FleetC. (2019). Accessibility, Augmented. Digital Frictions. New York, NY: The Architectural League. Available online at: https://urbanomnibus.net/2019/11/accessibility-augmented/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 23

  Garland-ThomsonR. (2011). Misfits: a feminist materialist disability concept. Hypatia26, 591–609. doi: 10.1111/j.1527-2001.2011.01206.x

  • CrossRef
  • Google Scholar
  • View reference in article

• 24

  GaverB.DunneT.PacentiE. (1999). Design: cultural probes. Interactions6, 21–29. doi: 10.1145/291224.291235

  • CrossRef
  • Google Scholar
  • View reference in article

• 25

  General Services Administration (2017). Benefits of Accessible Design. Available online at: https://www.section508.gov/blog/benefits-accessible-design/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 26

  General Services Administration (2024). Content Creation - Create Accessible Captions and Transcripts. Available online at: https://www.section508.gov/create/captions-transcripts/ (Accessed April 11, 2025).

  • Google Scholar
  • View reference in article

• 27

  GonçalvesD.PiçarraM.PaisP.GuerreiroJ.RodriguesA. (2023). ““My Zelda Cane”: strategies used by blind players to play visual-centric digital games,” in Proceedings of the 2023 CHI conference on human factors in computing systems (New York, NY: Association for Computing Machinery), CHI '23, 1–15. doi: 10.1145/3544548.3580702

  • CrossRef
  • Google Scholar
  • View reference in article

• 28

  GonçalvesD.RodriguesA.GuerreiroT. (2020). “Playing with others: Depicting multiplayer gaming experiences of people with visual impairments,” in Proceedings of the 22nd International ACM SIGACCESS Conference on Computers and Accessibility, ASSETS '20 (New York, NY: Association for Computing Machinery). doi: 10.1145/3373625.3418304

  • CrossRef
  • Google Scholar
  • View reference in article

• 29

  Good Trouble Games (2025). Abletoplay.

  • Google Scholar
  • View reference in article

• 30

  HamraieA.FritschK. (2019). Crip technoscience manifesto. Catalyst: Feminism, Theory, Technosci.5, 1–33. doi: 10.28968/cftt.v5i1.29607

  • CrossRef
  • Google Scholar
  • View reference in article

• 31

  HendersonC.DancyM. H. (2007). Barriers to the use of research-based instructional strategies: the influence of both individual and situational characteristics. Phys. Rev. ST Phys. Educ.3:020102. doi: 10.1103/PhysRevSTPER.3.020102

  • CrossRef
  • Google Scholar
  • View reference in article

• 32

  HendrenS. (2020). What Can a Body Do?: How We Meet the Built World (New York, NY, USA: Riverhead Books, Penguin Random House LLC)

  • Google Scholar
  • View reference in article

• 33

  HofmannM.KasnitzD.MankoffJ.BennettC. L. (2020). “Living disability theory: reflections on access, research, and design,” in The 22nd International ACM SIGACCESS Conference on Computers and Accessibility, ASSETS '20 (New York, NY: Association for Computing Machinery), 1–13. doi: 10.1145/3373625.3416996

  • CrossRef
  • Google Scholar
  • View reference in article

• 34

  HoveyC. L.BundeD. P.ButlerZ.TaylorC. (2023). “How do i get people to use my ideas? Lessons from successful innovators in CS education,” in Proceedings of the 54th ACM technical symposium on computer science education V. 1 (New York, NY: Association for Computing Machinery), SIGCSE 2023, 841–847. doi: 10.1145/3545945.3569779

  • CrossRef
  • Google Scholar
  • View reference in article

• 35

  HunickeR.LeBlancM.ZubekR, (2004). “Mda: a formal approach to game design and game research,” in Proceedings of the AAAI Workshop on Challenges in Game AI, vol. 4 (San Jose, CA: AAAI), 1722.

  • Google Scholar
  • View reference in article

• 36

  Invalid S. (n.d.). 10 Principles of Disability Justice.

  • Google Scholar
  • View reference in article

• 37

  KaferA. (2013). Feminist, Queer, Crip. Indiana University Press.

  • Google Scholar
  • View reference in article

• 38

  KulikJ.BeestonJ.CairnsP. (2021). “Grounded theory of accessible game development,” in Proceedings of the 16th international conference on the foundations of digital games (New York, NY: Association for Computing Machinery), FDG '21, 1–9. doi: 10.1145/3472538.3472567

  • CrossRef
  • Google Scholar
  • View reference in article

• 39

  KulikJ.CairnsP.KulikJ. (2023). “A qualitative investigation of real world accessible design experiences within a large scale commercial game development studio,” in 2023 IEEE conference on games (CoG) (New York, NY: IEEE), 1–8. doi: 10.1109/CoG57401.2023.10333178

  • CrossRef
  • Google Scholar
  • View reference in article

• 40

  LaiG.FungK. Y. (2020). From online strangers to offline friends: a qualitative study of video game players in hong kong. Media, Cult. Soc. 42, 483–501. doi: 10.1177/0163443719853505

  • CrossRef
  • Google Scholar
  • View reference in article

• 41

  LauraKBuzz (2024). Video Games Need Accessibility Standards: 2024 - Access-Ability. Available online at: https://www.youtube.com/watch?v=WPTwCsCr6iU (Accessed April 10, 2025).

  • Google Scholar
  • View reference in article

• 42

  LauraKBuzz (2025a). Emotion Captions in Assassin's Creed Shadows Support Autistic Players! Available online at: https://www.youtube.com/watch?v=uAcLbZxFORY (Accessed April 12, 2025).

  • Google Scholar
  • View reference in article

• 43

  LauraKBuzz (2025b). More Emotion Subtitles in Video Games (Atomfall / Midnight Asphalt)- Access-Ability. Available online at: https://www.youtube.com/watch?v=nzGfGWXlcSs (Accessed April 12, 2025).

  • Google Scholar
  • View reference in article

• 44

  LazarJ.GoldsteinD. F.TaylorA. (2015). Ensuring Digital Accessibility through Process and Policy, 1st Edn. San Francisco, CA: Morgan Kaufmann Publishers Inc.

  • Google Scholar
  • View reference in article

• 45

  LenhartA.KahneJ.EllenM.MacgillA.-R.EvansC.VitakJ. (2008). Teens, Video Games, and Civics: Teens' Significant Social Interaction and Civic Engagement. Tech. rep. Washington, DC: Pew Internet & American Life Project.

  • Google Scholar
  • View reference in article

• 46

  LewisT. A. (2022). Working Definition of Ableism - January 2022 Update. Available online at: http://www.talilalewis.com/1/post/2022/01/working-definition-of-ableism-january-2022-update.html (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 47

  Ly Xīnzhèn Zhǎngsūn Brown (2017). Identity and Hypocrisy: A Second Argument Against Person-First Language. Available online at: https://www.autistichoya.com/2011/11/identity-and-hypocrisy-second-argument.html (Accessed April 10, 2025).

  • Google Scholar
  • View reference in article

• 48

  MagnussonE.MarecekJ. (2015). Doing Interview-based Qualitative Research: A Learner's Guide. Cambridge: Cambridge University Press. doi: 10.1017/CBO9781107449893

  • CrossRef
  • Google Scholar
  • View reference in article

• 49

  MartinezJ. J.FroehlichJ. E.FogartyJ. (2024). “Playing on hard mode: accessibility, difficulty and joy in video game adoption for gamers with disabilities,” in Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems, CHI '24 (New York, NY: Association for Computing Machinery). doi: 10.1145/3613904.3642804

  • CrossRef
  • Google Scholar
  • View reference in article

• 50

  Microsoft (2026). Xbox Accessibility Guideline 107: Input. Available online at: https://learn.microsoft.com/en-us/gaming/accessibility/xbox-accessibility-guidelines/107/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 51

  MingusM. (2011). Changing the Framework: Disability Justice. Available online at: https://leavingevidence.wordpress.com/2011/02/12/changing-the-framework-disability-justice/ (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 52

  NairV.MaS.-e.Gonzalez PenuelaR. E.HeY.LinK.HayesM.et al. (2022). “Uncovering visually impaired gamers' preferences for spatial awareness tools within video games,” in Proceedings of the 24th International ACM SIGACCESS Conference on Computers and Accessibility, 1–16. doi: 10.1145/3517428.3544802

  • CrossRef
  • Google Scholar
  • View reference in article

• 53

  NairV.ZhuH. H.SongP.WangJ.SmithB. A. (2024). “Surveyor: facilitating discovery within video games for blind and low vision players,” in Proceedings of the 2024 CHI conference on human factors in computing systems (New York, NY: Association for Computing Machinery), CHI '24, 1–15. doi: 10.1145/3472749.3474768

  • CrossRef
  • Google Scholar
  • View reference in article

• 54

  NairV.ZhuH. H.SongP.WangJ.SmithB. A. (2024). “Surveyor: facilitating discovery within video games for blind and low vision players,” in Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems, CHI '24 (New York, NY: Association for Computing Machinery), 1–15. doi: 10.1145/3613904.3642615

  • CrossRef
  • Google Scholar
  • View reference in article

• 55

  NetflixInc. (2022). Timed Text Style Guide: General Requirements. Available online at: https://partnerhelp.netflixstudios.com/hc/en-us/articles/215758617-Timed-Text-Style-Guide-General-Requirements/ (Accessed March 10, 2025).

  • Google Scholar
  • View reference in article

• 56

  Pacific Alliance on Disability Self-Advocacy (PADSA) (2019). Pacific Alliance on Disability Self-Advocacy Resource Library.

  • Google Scholar
  • View reference in article

• 57

  Piepzna-SamarasinhaL. L. (2018). Care Work: Dreaming Disability Justice. Arsenal Pulp Press.

  • Google Scholar
  • View reference in article

• 58

  PlayStation (2020). Accessibility options for the last of us part II. Available online at: https://www.playstation.com/en-us/games/the-last-of-us-part-ii/accessibility// (Accessed May 29, 2026).

  • Google Scholar
  • View reference in article

• 59

  PolyArc Games (2018). Moss. Available online at: https://www.polyarcgames.com/games/moss/ (Accessed May 29, 2026).

  • Google Scholar

• 60

  PorterJ. R.KientzJ. A. (2013). “An empirical study of issues and barriers to mainstream video game accessibility,” in Proceedings of the 15th International ACM SIGACCESS Conference on Computers and Accessibility, ASSETS '13 (New York, NY: Association for Computing Machinery). doi: 10.1145/2513383.2513444

  • CrossRef
  • Google Scholar

• 61

  PowerC.BarletM. (2019). Accessible Player Experiences: A New Approach to Data Informed Design for Accessible Games. Available online at: https://www.gdcvault.com/play/1025719/Accessible-Player-Experiences-A-New/ (Accessed May 29, 2026).

  • Google Scholar

• 62

  RinglandK. E. (2019). “A place to play: the (dis)abled embodied experience for autistic children in online spaces,” in Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, CHI '19 (Glasgow: Association for Computing Machinery), 1–14. doi: 10.1145/3290605.3300518

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 63

  RinglandK. E.BoydL.FaucettH.CullenA. L.HayesG. R. (2017). “Making in minecraft: a means of self-expression for youth with autism,” in Proceedings of the 2017 Conference on Interaction Design and Children, IDC '17 (New York, NY: Association for Computing Machinery), 340–345. doi: 10.1145/3078072.3079749

  • CrossRef
  • Google Scholar

• 64

  RogersE. M. (2003). Diffusion of Innovations, 5th Edn. New York, NY: Simon Schuster.

  • Google Scholar

• 65

  SkolnikM. R.ConwayS. (2019). Tusslers, beatdowns, and brothers: a sociohistorical overview of video game arcades and the street fighter community. Games Cult. 14, 742–762. doi: 10.1177/1555412017727687

  • CrossRef
  • Google Scholar

• 66

  Sony Interactive Entertainment (2021). Accessibility Consulting: Opening New Doors for All Gamers. Available online at: https://sonyinteractive.com/en/news/blog/accessibility-consulting-opening-new-doors-for-all-gamers// (Accessed May 29, 2026).

  • Google Scholar

• 67

  SpielK.GerlingK. (2021). The purpose of play: How HCI games research fails neurodivergent populations. ACM Trans. Comput. Hum. Interact.28, 1–40. doi: 10.1145/3432245

  • CrossRef
  • Google Scholar

• 68

  TaylorC.SpaccoJ.BundeD. P.ButlerZ.BortH.HoveyC. L.et al. (2018). “Propagating the adoption of CS educational innovations,” in Proceedings companion of the 23rd annual ACM conference on innovation and technology in computer science education (New York, NY: Association for Computing Machinery), ITiCSE 2018 Companion, 217–235. doi: 10.1145/3293881.3295785

  • CrossRef
  • Google Scholar

• 69

  TheilA.BuchweitzL.SchulzA. S.KornO. (2023). Understanding the perceptions and experiences of the deafblind community about digital games. Disab. Rehabil.: Assist. Technol. 18, 1347–1356. doi: 10.1080/17483107.2021.2008026

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 70

  Valve Corporation (2025). Showing Accessibility Support for Your Games on Steam. Available online at: https://steamcommunity.com/groups/steamworks/announcements/detail/536595840131663919 (Accessed August 30, 2025).

  • Google Scholar

• 71

  VanderheidenG. C.TreviranusJ.GemouM.BekiarisE.MarkusK.ClarkC.et al. (2013). “The evolving global public inclusive infrastructure (gpii),” in Universal Access in Human-Computer Interaction. Design Methods, Tools, and Interaction Techniques for eInclusion: 7th International Conference, UAHCI 2013, Held as Part of HCI International 2013 (Las Vegas, NV: Springer), 107–116. doi: 10.1007/978-3-642-39188-0_12

  • CrossRef
  • Google Scholar

• 72

  Video Game Insights (2024). Global Indie Games Market Report 2024. Tech. rep.

  • Google Scholar

• 73

  WallaceJ.McCarthyJ.WrightP. C.OlivierP. (2013). “Making design probes work,” in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI '13 (New York, NY: Association for Computing Machinery), 3441–3450. doi: 10.1145/2470654.2466473

  • CrossRef
  • Google Scholar

• 74

  WashingtonU. (2025). Digital Accessibility Benefits Everyone – Accessibility at the UW.

  • Google Scholar

• 75

  Web Accessibility Initive (2012). Iso/iec 40500: Web Content Accessibility Guidelines (WCAG). Technical report, International Organization for Standardization.

  • Google Scholar

• 76

  WestinT.KuJ. J.DupireJ.HamiltonI. (2018). “Game accessibility guidelines and wcag 2.0 – a gap analysis,” in Computers Helping People with Special Needs: 16th International Conference, ICCHP 2018, Linz, Austria, July 11-13, 2018, Proceedings, Part I (Berlin; Heidelberg: Springer-Verlag), 270–279. doi: 10.1007/978-3-319-94277-3_43

  • CrossRef
  • Google Scholar

• 77

  WilhelmssonU.EngstromH.BruskJ.OstbladP.-A. (2015). “Accessible game culture using inclusive game design - participating in a visual culture that you cannot see,” in 2015 7th International conference on games and virtual worlds for serious applications (VS-Games) (New York, NY: Institute of Electrical and Electronics Engineers), 1-8. doi: 10.1109/VS-GAMES.2015.7295764

  • CrossRef
  • Google Scholar

• 78

  WolbringG. (2008). The politics of ableism. Development, 51, 252–258. doi: 10.1057/dev.2008.17

  • CrossRef
  • Google Scholar

• 79

  YmousA.SpielK.KeyesO.WilliamsR. M.GoodJ.HorneckerE.et al. (2020). ““I am just terrified of my future” – epistemic violence in disability related technology research,” in Extended Abstracts of the 2020 CHI Conference on Human Factors in Computing Systems, CHI EA '20 (Honolulu, HI: Association for Computing Machinery), 1–16. doi: 10.1145/3334480.3381828

  • CrossRef
  • Google Scholar

• 80

  ZimmermanJ.ForlizziJ. (2014). “Research through design in HCI,” in Ways of Knowing in HCI (New York, NY: Springer), 167–189. doi: 10.1007/978-1-4939-0378-8_8

  • CrossRef
  • Google Scholar

• 81

  ZubekR. (2020). Elements of Game Design. MIT Press.

  • Google Scholar