Table of Contents
|Table of Contents||excludeTable of Contents|
Interactive games can provide rich learning experiences for students - but for some, these games are not accessible. Designing an educational game which can be enjoyed by a broad spectrum of users can be a challenge.
This guide aims at giving some practical techniques to help improve the inclusiveness and accessibility of interactive content whether retrofitting existing content or creating a new game from scratch.
Building Interactive Games with an Accessible Parallel DOM
Case Study: PhET.
Orienting the User
Regardless of the modality used for interaction, a logical, predictable structure helps users focus on learning and the experience instead of getting stuck on the interaction and wondering "what do I do now?".
Help orient the user by:
- having a consistent structure
- describe the scene and setting so non-visual users can understand their context
- identifying the actors and interactive parts
- giving meaningful and predictable landmarks for the user
- use progress and status indicators as necessary
- try to keep the structure stable. Be mindful about removing items completely from the structure - consider disabling elements rather than removing them.
Player Choices and Controls
Some people make choices easily, while others require more careful thought and investigation before making decisions. Choices in games can be exciting for some, but stressful for others.
If presenting learners with multiple choices that affect the outcome of a game:
- Labels for button and controls should use simple terminology and define any terms if necessary.
- Controls should make it clear what the outcome would be. For example: A choice called "I'm out of here" could be changed to "I'm out of here (quit game)", or simply "Quit".
- If possible, make choices forgiving or give opportunity for users to correct or change their choices.
- Controls that are graphical should have associated descriptive text. If text must be visually hidden, consider using this technique for making invisible content for screen readers: "Invisible Content Just for Screen Reader Users " on WebAim.org.
Content Accessibility / Screen Readers
- Use a good structure and semantic markups:
- Use WAI-ARIA to improve accessibility
Generally, make sure visuals have text equivalents.
- Provide text descriptions for important visuals: images should have alt-text and longer text descriptions if necessary. Use aria-describedby or longdesc as required. See: http://www.w3.org/WAI/tutorials/images/complex/
- Content contained in the background (using background CSS property), :before or :after elements are ignored by screen readers. Do not put important content within these elements. Use standard elements like <image>, <div>, <figure>, etc. as needed.
- Images which are in the background should be cosmetic and not critical to the outcomes. Use <img> and <figure> as necessary for important graphics / images.
Punctuation helps a screen reader know when to pause, give proper emphasis, etc.
- Check for missing punctuation - if periods or commas are missing, screen readers would not know to pause.
- Unicode characters are often omitted by screen readers. Ellipsis (...), arrows, and other characters are ignored.
If there are multiple "speakers", you may need a way to identify the different speakers to a screen reader.
- Consider adding a prefix to the dialog like: "Susan asks", "Mark replies" etc.
- You may visually hide these prefixes so they are accessible to screen readers, but not rendered on screen.
- See this article for additional details about accessible visually hidden content:
Note: that hiding content for any modality should be done with care. You should ask yourself if hiding is necessary and if other users would find the hidden content useful.
- Instructions should be clear and concise. Buttons should have labels.
- Make help readily available.
- Avoid really dense content and interactions. Group using <section> elements with proper <h1> headings.
- Do not rely on colour to convey meaning. If this is unavoidable, provide a text label or text descriptions.
- Avoid using transition / animation effects on content that is critical to the outcomes of the game. These effects may be missed or misunderstood.
- Use opacity, transparency, alpha channels with caution. These effects may make it more difficult for some users to distinguish content from the background.
Keyboard / Keypad / Single-switch Interaction
- Tab order should be consistent with existing user experiences. i.e. top to bottom, left to right.
- Interactables should have:
- a keyboard equivalent
- focus styling so the user knows when they can interact with the item
- You want to get your users into the experience as quickly as possible:
- avoid loading navigation, link to home, about, etc up front - the user will need to tab through all of this to get to the interesting parts.
- consider adding a skip link: http://webaim.org/techniques/skipnav/
- Tab order should properly "cycle around" when tabbing through. Watch for focus traps or hidden elements which may break the game for users.
Images, Symbols, Math, Icons, and Glyphs
Make sure that symbols, math notation, and other glyphs have the desired textual output. For example: ½ should read as “one half” and not “one slash two”.
If using Unicode characters, something like this would be helpful:
<span aria-labelledby="left-arrow">←</span><span id="left-arrow" class="hidden">Left arrow</span>