Introduction

Some people participating in the Games for Blind Gamers jam were confused that I put a lot of effort into the visual presentation for my game. After all, it is a game jam for blind people, right? I am writing this article to help better explain this design choice and hopefully encourage indie developers interested in blind accessibility in gaming to avoid potential pitfalls with assumptions in their presentation and game design.

Understanding Blind Accessibility in Games

Audio Games vs Blind Accessible Games

First, it is important to understand that audio games and accessible games are NOT necessarily the same things. In fact, Audio Games are a real genre of games that extends beyond just blind players - although it is mostly popular with blind players. These are games that often have limited or no graphics and use audio to describe events in the game. They may even be fully voice acted and not use a screenreader at all! They are very unique and cool experiences that I think sighted players should give more a chance.

However, with audio games, the emphasis is not so much on “accessibility” and more so on the presentation of the game through an audio only channel. Sure, it is accessible for blind people who can hear well, but many blind people can’t hear the best. And obviously, without special design accommodations, audio games are not accessible to those who are hard of hearing (HoH) or deaf.

On the other hand, blind accessible games are games that are designed specifically to be accessible to the blind. They can be audio games, but they can also be any other kind of game. When a commercial game provides blind accessibility and screenreader access, this is an attempt in implementing blind accessibility into the game. Many blind accessible games do have graphics, because they are designed for a wide audience, and blind accessibility is implemented as a means to expand that audience even further.

Audio games are usually blind accessible, but they also focus specifically on the audio design, and often have limited or no graphics. Additionally, most often, blind people make audio games simply because they are not working with a sighted person to produce the graphics.

This is of course to not say there is anything wrong with an audio game! In fact, I started with audio games way back when I first started developing games back in 2013. But there is significant value in integrating a graphical interface, especially if you want to retain a more mainstream audience with the game. I also want to encourage a more open ended design philosophy with approaching accessible games.

Common Misconceptions About Blind People and Accessible Games

One thing I noticed in the game jam especially with developers new to blind accessibility was their desire to make specifically audio games, and to not focus on graphics. There are a few reasons for this, partly because a game jam is a short period of time and graphics take quite a bit of work to produce, and they are experimenting with new technology they may be unfamiliar with, such as accessible HTML design, or connecting a game engine to a screenreader (in some cases, it is not well supported).

However, a major reason for this was also the misconception that blind people prefer games with no graphics. This is simply not the case! Most blind people have at least some vision, and many still have some useful vision they can use at a computer. Think about it - if your vision is very limited, you can still see stuff on the screen that could be useful, even if you need to use the skills you learned in O&M (Orientation and Mobility) training to get around outside. This means that blind players, like sighted players, benefit greatly from graphics.

Another misconception that lead to the majority of submissions being audio games was the idea that blind people usually compensate for their poor vision with hearing. This is sometimes true - however, blind people often also have hearing impairment, which can make relying on sound design alone very difficult. This is part of the reason why screenreader compatibility is useful, because it allows for the user to use the settings that is best for them, even hard of hearing users.

Something often missed with discussing accessibility in indie spaces is the accessibility of sharing play activity; not only having the ability to play with others online in multiplayer games (The Castle is single-player), but also activities such as streaming or video reviews. Having graphics in your game means that blind streamers are sharing something that they can also interact with sighted players, so instead of sighted players seeing a blank screen or a stationary graphic, they can be part of the game as well, encouraging blind players to integrate into the larger discourse surrounding the game.

A Spectrum of Accessibility

It can be problematic to try to develop accessibility for a specific group of people. Sometimes it is professionally necessary, but it also leads to a lot of reinforcement of stereotypical design patterns and assumptions about blindness that harm the user experience, either for blind players or sighted players.

These assumptions can be avoided by taking a different design philosophy. Instead of designing specifically for blind people (which is a wide range of visual impairments), it may be easier to design for a wide expression of possibilities for a user interface. This means that the Options screen may be one of the most important things that you write for an accessible game, because its implementation leads to how customizable and fine-tuned the experience can be. Then, after designing that, presets can be developed and loaded when a screenreader is detected - this way the game is usable for a blind player when they first play the game, but they can further customize their experience.

What we should focus on with this kind of design is not, “who will be playing my game?” but rather “what ways can I express the input/output loop of the game so that there is enough information for the player to understand what is going on?”. This means that when designing games, such as the Avoid Traffic game, we have to think not just what is displayed on the screen, but splitting apart the concept of the “vehicles” as visual representations and trying to understand what movement information we are perceiving when looking at the vehicles, and translating that into sound effects that can reliably be used to navigate. Accessibility really is a matter of breaking everything down into its finest pieces and re-arranging it into new ways that can be reached by a wide variety of users.

Furthermore, some accessibility features that are graphics only are also really useful. Currently, it is underdeveloped and has an incomplete interface, but The Castle also supports a magnifier feature. This feature is extremely helpful for people with limited vision who may not see the game screen easily even in full screen, and allows players to see in more zoomed in detail. Another important feature is the box that centers around selected elements with the screenreader. It is true many screenreader users will never need this feature, but many other screenreader users will find it helpful to see clearly what is the selected element.

Fun fact: Did you know that blind indie developers and player feedback in the 2000s and 2010s on Audiogames.net played a significant role in developing the expectations that blind players have with interacting with video games? The blind have always been central and pivotal to producing blind games. Later, these design patterns developed by the community were used as the backbone for many commercial accessibility projects.

As a result, you should try to find blind play testers whenever you can. The Discord Server for the game jam has plenty who would love to try your game. However, if you are a larger production and are able, I highly recommend hiring a consultant and financially contributing towards the lifestyle of a blind working person.

Bug Fixes

And now for the boring part - some bug/behavior fixes to make the game experience smoother.

• Some options have been renamed to be more clear.
• Removed the debug (blank) color palette.
• Removed “textbox” text being read after selecting textboxes.
• Made it so Options can use [Z] to modify entries and [F1] to ask for clarity on things.
• Improved screenreader enabled message.
• Added confirmation when exiting game with [ESC].
• Sound effects no longer play during the tutorial in the Avoid Traffic game.

And additions!

• Verbose Screenreader mode.
• Screen Curtain.
• Ability to exit story mode and free play with [ESC].
• message when exiting the game.
• Back button on credits screen.
• NVDA auto-detection.