The Game of Accessibility: Usable Versus Playable

By Jazmn Collins (Cornell Tech)

Accessibility isn’t fun. 

When a blind or low vision person turns on their phone and swipes through icons on their screen, listening to a robotic, hierarchical readout of every icon name to find the one they’re looking for, they normally don’t praise their screen reader for how pleasant its pronunciation is.

When this same person sits down to watch a TV show and has to first check if audio descriptions are available, add them if they are, and save their settings for the future, they typically don’t rave about how cool finding the toggle for those extra voices was.

When this person starts up a brand-new video game and checks if there are any Quick Time Events (QTEs, an interactive game event that requires a player to perform a designated action in a short period of time), they generally won’t enjoy filtering through the dregs of a settings menu to switch on or off every setting they think is necessary to skip those QTEs or make them playable without vision.

Accessibility features have long been relegated to menus and settings screens, a necessary evil of finding these menus in the first place and then reading through every option to identify which features you need…if your needed features are even there. Once you do find your features, perhaps a colorblind-accessible mode or an in-game screen reader that can read out alt-text for any interactable item, you flip that digital switch to activate them and do your best to enjoy your experience with their added help. But oftentimes, especially in the highly interactive world of video games, the provided accessibility measures and the pains it took to get to them don’t add much joy to that experience.

The alt-text on interactable objects is helpful, but clashes with character dialogue to make you miss important details. The spatial sound effects are great when casually exploring a world, but might not provide information fast enough when faced with a boss enemy that requires much less lackadaisical movement. The haptic vibrations that tell you when your character has run into an obstacle allow for easy independent movement, but when an enemy attack or a cutscene with special effects causes the same vibrations, the signals can be confusing. I focus on accessibility features for blind and low vision people here as my work has primarily focused on making virtual reality (VR) and other interactive digital experiences accessible for this user group [2], [5], [6], [3]. Throughout much of my work, I’ve found that existing accessibility features used by blind and low vision people to access their digital experiences are often frustrating, buried inside of bothersome menus, or reduce the immersion they feel while playing. 

This is not to say that accessibility features aren’t necessary or appreciated: far from it. Most of the people I’ve worked with are thrilled about new accessibility updates in games and VR devices, since there are so few access tools to begin with. Even finding a new accessibility option in a game menu that previously had none can be exciting, if just for a bit, for the chance to see how the industry has paid attention to user feedback. However, I believe that even the most good-faith efforts at game accessibility often struggle to integrate these features into their games in ways that are compelling, engaging, and add something more than just another toggle to the players’ experience. Herein lies the crux of a big problem I see with accessibility features in games: they focus on making games usable for people with disabilities, rather than making games playable.

There is a big difference to me between “usability” and “playability.” When something is usable, you can feasibly interact with all of the important aspects of it. You get the information you need at a baseline, you can function off that information, and you can see your main purpose in interacting with it through to the end. This is like being able to open up a game, toggle on your alt-text and spatial sounds, and make it to the end of the last boss fight, even if you missed some story dialogue or environments along the way. When something is playable, though, achieving your main purpose isn’t the only thing you can do. You can mess around with it and find enjoyment in doing so, without losing track of the information you need. This is like opening up a game, switching on your magical “playable” access features, and being able to explore the game world to the fullest, feeling completely immersed in its storyline, and even enjoying playing with the features you were given. The “playable” accessibility features in this ideal scenario are not simply features that toggle on and disrupt your gameplay; they are part of the game itself, they are enjoyable in and of themselves, and they engage you just as much as the game does.

But what would it take to make a “playable” accessibility feature? How can you make something that has been a necessary evil of the settings menu for so long into something that can be enjoyed itself? Personally, I believe there are two key steps that must be taken when developing game access features in order to achieve this magical standard: integration and interaction.

The first step, integration, is possibly the most in conflict with the current state of game accessibility. Game accessibility has long followed a trend where the onus for making experiences accessible has been placed on the disabled player community, rather than the game developers [8]. Disabled players see games that they enjoy, or would like to enjoy, and need to mock-up their own access methods to do so, releasing custom modifications to the community [7] or sharing resources for customizing game hardware and making alternative adaptive gaming controls [1]. The alternative is simply avoiding any genre of games that they can’t play with their disability until new features come out which make the game accessible [4]. It is only recently that developers have begun to experiment with wider varieties of accessibility features, integrate them into the release of their games from the beginning, or include them in game consoles rather than selling accessible tools as separate add-ons or expensive hardware. And even with this shift towards releasing accessibility features at the start, the released features are still add-ons, in a sense, because they are usually developed after the rest of the game or console.

Accessibility is an afterthought in most industries and the game industry, unfortunately, is no exception. Making the game or gaming console comes first, and once the product has been perfected, then developers will consider how to make it accessible and sandwich in their access features. This makes the game usable but all of the playability has been decided already; the game at its core is meant to be played without accessibility features, and there is no room for play with the new features that get painted on top.

Integration would seek to change that. It may be an obvious step, but it is a necessary one. As part of the game design process itself, developers should consider how to make different aspects of their game accessible. If the main character in your game was blind, how would they get access to the cryptic writing on the wall? Is there perhaps an NPC nearby who can read it for them? Is there a tool they can use to read it instead? Is there a mysterious voice that accompanies all of these messages, perhaps the ghost who is behind them all in the first place? Thinking of diegetic ways that your world can be made accessible, as it is being created, can be invaluable towards making an accessible game experience that doesn’t feel forced or painted-on. Instead, accessibility becomes part of the developer’s journey, and by extent, the player’s journey as well.

Of course, even with careful consideration of your game’s story and as many diegetic access moments as possible, there will likely still be important details in your game that need to be made accessible with an outside tool. However, this tool should not disrupt the immersion of the gameplay experience and it should not just be a frustratingly necessary toggle in a menu. This is where the second step comes into play: interaction.

As a major part of my research, I’ve looked into creating interactive guide assistants for blind and low vision people exploring VR [2], [3]. These assistants work by mimicking the technique of sighted guide from the physical world, having either a human assistant or an AI one powered by LLMs that can talk to the blind or low vision user, answer their visual questions about the VR space, and lead their avatars through it. From the beginning of this work, one of the key points of feedback I’ve gotten about these assistants is that they are entertaining to use because they are interactive companions.

The guide assistants accompany the blind and low vision users throughout the VR space, primarily helping them navigate and interpret the digital world around them, but are often used secondarily in many other ways. The human assistant, for example, became a separate “player” in the space, with the blind or low vision user often asking them to try out virtual activities with them or asking for their opinion on what to do next. The AI assistant became a novel sort of toy, which the blind or low vision user showed off to other people joining them in VR, testing out its functions in their group, seeing how it would react to different queries, and even giving the assistant new instructions to see if they could change how it assisted them.

The participants in my studies enjoyed testing out the AI assistant, pushing its limits, and seeing how it would react. They also enjoyed having the human companion with them, performing activities and exploring the VR space together. In other words, participants enjoyed playing with their interactive guide assistants, and turned that experimentation process with the tool into part of their VR experience. This is the kind of behavior that we would want to see reflected with game accessibility features as well. Playfulness and eagerness to use the feature, due to interaction methods that make the feature an entertaining part of the game in its own right.

For instance, if blind and low vision accessibility features were turned on in your game, perhaps a new character would enter the fray that would act as a supportive companion to your player. This character might be an assistant known only to the player, perhaps a spirit of an ancestor, a pet familiar, or even a talking amulet or ring whose voice is only heard by the player. This support character can help them through the game as part of the experience, answering questions about the scene, even adjusting settings on-the-fly like highlighting objects with a “magical glow” or perhaps moving over the objects and calling to the player to act as a radar. By making the tools themselves interactive, you encourage the player to use them and make your accessibility features an engaging element of their gaming experience.

Integration and interaction may not be the only steps required to make a truly “playable” game accessibility experience. Nor are they particularly easy to implement, requiring careful consideration, creativity, and effort on the part of developers to work them in. However, they can open the door to making accessibility an equally important part of game development, resulting in games that consider all of their players from the very beginning. They are an attempt at stepping up the game of accessibility, and bringing us closer to a gaming future where my opening statement is a relic of the past, and accessibility, just as much as any game, can genuinely be fun.

[1] ablegamers. “Ablegamers Charity on Instagram: ‘3D Printing Helps Disabled Gamers Customize Their Gaming Setup so That They Can Keep Playing...’” Instagram, https://www.instagram.com/ablegamers/p/C7y-EzcMcwg/

[2] Collins, Jazmin, Crescentia Jung, Yeonju Jang, Danielle Montour, Andrea Stevenson Won, and Shiri Azenkot. "“The Guide Has Your Back”: Exploring How Sighted Guides Can Enhance Accessibility in Social Virtual Reality for Blind and Low Vision People." In Proceedings of the 25th international ACM SIGACCESS conference on computers and accessibility, pp. 1-14. 2023. https://dl.acm.org/doi/abs/10.1145/3597638.3608386

[3] Collins, Jazmin, Kaylah Myranda Nicholson, Yusuf Khadir, Andrea Stevenson Won, and Shiri Azenkot. "An AI Guide to Enhance Accessibility of Social Virtual Reality for Blind People." In Proceedings of the 26th International ACM SIGACCESS Conference on Computers and Accessibility, pp. 1-5. 2024. https://dl.acm.org/doi/10.1145/3663548.3688498

[4] duz_machines. “R/Xboxseriesx on Reddit: Co-Pilot Mode Changed My Disabled Sister’s Life.” Reddit, https://www.reddit.com/r/XboxSeriesX/comments/nqk3nb/copilot_mode_changed_my_disabled_sisters_life/

[5] Gonzalez Penuela, Ricardo E., Jazmin Collins, Cynthia Bennett, and Shiri Azenkot. "Investigating use cases of ai-powered scene description applications for blind and low vision people." In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems, pp. 1-21. 2024. https://dl.acm.org/doi/10.1145/3613904.3642211

[6] Jung, Crescentia, Jazmin Collins, Ricardo E. Gonzalez Penuela, Jonathan Isaac Segal, Andrea Stevenson Won, and Shiri Azenkot. "Accessible Nonverbal Cues to Support Conversations in VR for Blind and Low Vision People." In Proceedings of the 26th International ACM SIGACCESS Conference on Computers and Accessibility, pp. 1-13. 2024. https://dl.acm.org/doi/10.1145/3663548.3675663

[7] luissanchezdev. “Accessibility plus - Mods - Minecraft - Curseforge.” Curseforge, https://www.curseforge.com/minecraft/mc-mods/accessibility-plus

[8] Shin, Mira. “A Growth of Accessibility in Video Games.” A Growth of Accessibility in Video Games | DO-IT, DO-IT (Disabilities, Opportunities, Internetworking, and Technology), https://www.washington.edu/doit/growth-accessibility-video-games

Jazmin Collins

DLI Doctoral Fellow

Cornell Tech

jc2884@cornell.edu

More Info >

Cornell Tech | 2025

Download PDF >