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.
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.
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
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.