orient the user
- progress indicator
- consistent structure
- describe the scene
- identify the actors and interactive parts
- give meaningful and predictable landmarks for the user.
- Use simple terminology and define any terms if necessary.
- Make it clear what the outcome would be. For example: A choice called "I'm out of here" perhaps should be relabelled as "I'm out of here (quit game)".
- If possible, make choices forgiving or give opportunity for users to correct or change their choices.
Content Accessibility / Screen Readers
- Use a good structure and semantic markups:
- Use WAI-ARIA to improve accessibility
- 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.
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.
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>