Skip to content using Screen Reader
What it would Take
Home

Guidelines for Building Blind-Accessible Computer Games

This page is where this Web site all began. Our colleague, Dark, kept getting asked for a template or checklist for developers who wanted to make their games blind-accessible. He, in turn asked us what we could do. This Web site, and this page in particular answer that question.

The suggestions here are Windows-centric as that's what we do at 7-128 Software. However, many of these suggestions apply to Macs, consoles, and smartphones. Many also apply to any software you want to make useable by people who are blind.

This page is intended to be used as a checklist. Technical details on how to implement these items can be found in articles elsewhere at this Web site.

Absolutely Critical Features

1.1. All controls and game components should be accessible via the keyboard.


With very rare exceptions, gamers who are blind do not use the mouse. If the controls and the components of your game are not keyboard accessible, then likely it can not be played by a person who is blind.

A colleague, Aprone, points out that the blind accessible game Daytona and the Book of Gold uses the mouse / touchpad. Still, without keyboard access, most games are blind-inaccessible.

1.2. All controls and game components should speak text or have some mechanism that gives their user-understandable identification.


Buttons with just images, menus with just images, control groups with no text title need text, otherwise they can not be heard by gamers who are blind. Maps that are just images without text are invisible to gamers who are blind.

Go to top

General Feature Checklist

These suggestions also apply to all platforms.

2.1. The tab order should be left to right, top to bottom.


This improves the user interface for sighted as well as blind gamers. As an experiment, use the Tab key on your own Windows apps and see how many times the tab order is awkward. Power gamers use keys because they are faster than the mouse.

2.2. Radio buttons should speak associated labels or tool tips to identify what they control.


2.3. Radio buttons should speak a titled border that tells what group they belong to.


If they don't speak, then the gamer who is blind can't know what the selection set is.

2.4. Ensure the program always has focus set when it starts and never loses focus during play.


Screen readers and self voicing generally require focus to speak.
This is particularly critical when a game first starts.

2.5. Controls should speak when they gain focus.


2.6. Ensure all menu operations can be executed via the keyboard.


This benefits sighted power gamers as well as the blind.

2.7. Menu items, including sub-menus, should speak when they gain focus.


2.8. Ensure that all images speak what they are when they gain focus.


2.9. Tables should speak column headers.


Otherwise when your game speaks the cell values, they are meaningless.

2.10.Tables should be traversable by keystrokes: Tab, Arrow, etc.


2.11. Tables should speak what cell currently has focus.


2.12. Tree controls should be traversable via the keyboard.


2.13. Tree controls should speak their structure and status.


2.14. Lists, drop downs, and text areas should speak their contents.


2.15. Canvas controls should be navigable by keyboard.


This could mean using speaking labels. It could also mean superimposing a speaking, keyboard accessible grid.

2.16. Include a way to turn background music and sounds off.


These can make audio prompts hard to hear.

2.17. Make all screen help spoken and traversable by keyboard.


2.18. End spoken sentences and prompts with periods or other punctuation.


Screen readers and speech synthesizers both rely on punctuation for speech inflection. It sounds funny without punctuation.

Go to top

Screen Reader Feature Checklist

Screen readers are most often used on Windows-based PCs. The Mac doesn't need them. They don't run on consoles or smartphones.

For more on screen readers and games, click here.

3.1. Program mnemonics and hot-keys should not conflict with those used by screen readers.


Each screen reader vendor uses a different set of control keys, though there are common keys. If your game uses those keys, then a screen reader may misbehave.

3.2. Ensure all controls display text.


Mechanisms that give controls user-understandable text identification to screen readers could include:
  • Text on button faces
  • Tool tips
  • Labels associated with text edit fields or drop downs
  • Titled borders surrounding a control.
Assign logical names to controls, even if the name is not visible on the screen. Some screen readers can access this information and use it to describe the type and function of the control on the screen.

3.3. Define tools in tool-bars, palettes, and menus as separate items.


Do not create single graphics containing multiple objects.

By keeping tools and other objects separate, the screen reader is better able to identify and name each tool for the user.

3.4. Ensure that all images tell screen readers what they are.


There could be text on the screen that describes an image. Or you could use a tooltip. Some languages let you send screen readers text that is not on the screen.

3.5. Tables should have column headers that are readable by screen readers.

These headers should identify themselves as headers to screen readers.

3.6. Track the system cursor with the mouse, even if the cursor is invisible.


3.7. Avoid the use of "help" balloons that disappear whenever the hot spot, or focus of the mouse changes.


Try instead to lock the "help" balloon in place so that the user can move the cursor and continue to read the balloon. This allows the screen reading software to detect the mouse position when customized highlighting or focusing techniques are in use.

Balloons also may overlap text areas. Another reason not to use them.

3.8. For block text, use single column text whenever possible.


Avoid non-text menu items when possible.


Or at least incorporate visible or invisible text cues to accompany these items. Screen readers can see text even if that text is written to the screen invisibly.

3.9. Canvas controls should be navigable by screen readers.


This could mean using screen reader accessible labels. It could also mean superimposing a screen reader accessible grid.

3.10. Underlined text might not be readable by screen readers.


3.11. If possible, ensure that the cursor is visible.


Some screen readers require that the blinking cursor be visible somewhere on your application's display.

Go to top

Self Voicing Feature Checklist

Both Windows, with its SAPI interface, and the Mac, with its Voiceover interface self-voice. Some of this automatically happens. But mostly it requires code in your games.

For more on self voicing and games, click here.

4.1. If your program can use both self voicing and screen readers, ensure that self voicing can be turned off.


4.2. Ensure the user can change the speed of self voicing.


This is possible with speech synthesis such as SAPI. It may not be possible with sound clips like WAV files.

4.3. Ensure the user can abort self voicing.


Go to top

Suggested Feature Checklist

These suggestions generally apply on all platforms.

5.1. Tell the user when they enter and exit a dialog box, what screen they have returned to, and when the program starts and exits. .


5.2. Provide a control that summarizes a screen.


For example, a way to tell a screen reader to speak all of the controls on a properties tab.

5.3. Provide audio feedback for player actions.


If a player action causes a value in a summary table to change, speak that change.
If the cursor gets to the end of a grid or play area, play a sound.

5.4. Ensure that keystrokes are spoken.


5.5. Provide a prompt that tells the user what to do next when they enter a screen or dialog box.


5.6. Provide the user with some audio confirmation of selections, such as from lists.


5.7. Provide audio progress bars and splash screens.


5.8. Provide entertaining sounds.


Sighted folks like eye candy. People who are blind like ear candy.

5.9. Provide a means to slow down time-dependent features, such as timeouts or actions in a game.


Go to top

Subtle Factors

These issues generally apply on all platforms.

6.1. It takes longer to hear text than to read it.


Users of screen readers and self voicing compensate by increasing words per minute spoken by the screen reader.

6.2. Audio output is linear.


Sighted people scan text for the parts important to them. Screen readers must traverse the entire text. Consider this when composing text.

6.3. Screen readers and self voicing may mangle non-English text.


If your game uses non-English, it may sound funny.
Consider this when localizing as well.

6.4. Keyboard control is faster than mouse control.


A blind gamer may have an advantage over a sighted gamer.

6.5. Third party components or operating system components may or may not be accessible to screen readers.


6.6. Rendering help and similar text output in HTML may facilitate screen reading.


6.7. Screen readers are used by people who are not blind.


This includes people with vision impairments such as macular degeneration, and people with cognitive impairments such as dyslexia.

Go to top

In Depth


These guidelines are intended to be brief.

For more specific solutions, see our How To articles on this Web site.

John Bannick
Chief Technical Officer
7-128 Software

jbannick@7128.com