Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

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.

 

Scope of this Guide

This guide deals with interactive games built using standard web technologies such as HTML5, CSS, SVG, and JavaScript. By using established web standards, the content you create has a higher chance of being understood by assistive technologies.

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:

  • Label each button and control. Labels should use simple terminology and define any terms if necessary.
  • Buttons, links, 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".
  • In some cases text where text labels are not visible (example: icon buttons that do not have visible text labels), consider using this technique for making invisible content for screen readers: "Invisible Content Just for Screen Reader Users " on WebAim.org.
  • If possible, make choices forgiving: give opportunity for users to correct or change their choices.
  • Avoid player choices which require decisions within a time limit or provide options to disable such features.

Communicating Events and Actions

Todo

Content Accessibility / Screen Readers

Generally

Visuals

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

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.
  • Acronyms and abbreviations should use the <abbr> element with the relevant aria properties. For example:
    • <abbr role="text" title="kilograms" aria-label="kilograms">kg</abbr>
    • <abbr role="text" title="miles per hour" aria-label="miles per hour">mph</abbr>

Charts and Graphs

Charts and graphs are an excellent way to convey data in a meaningful way. However, charts and graphs typically favour a student who is capable of perceiving the content and can cognitively process the information.

Some methods in providing a more inclusive experience of charts and graphs:

  • Provide alternatives to charts. Give text descriptions and interpretations of the data, give a table of data.

    • A good description identifies:

      • What is being shown (i.e. the purpose of the chart)

      • Describe the values (relative sizes and differences between values).

      • Describe any patterns to may help us understand the data.

      • Summarize the trend / data pattern.

      • Also see PSU’s chart accessibility guide: http://accessibility.psu.edu/images/charts/

    • table of data:

      • Follow best practices for table formatting

      • any math, symbols, units, or acronyms defined

      • keep in mind that tables, particularly large or complex ones can be cumbersome to navigate (like with screen readers, small mobile displays, or screen magnifiers). Separate data tables if possible.
  • Follow W3C's guide on describing complex images: http://www.w3.org/WAI/tutorials/images/complex/

Multiple speakers

If there are multiple "speakers", you may need a way to identify the different speakers to a user of a screen reader.

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.

Cognitive

Information should be presented in a clear concise manner, and where possible starting with general statements first with more detailed information following.

  • Instructions should be clear and concise, using a language that is appropriate.
  • If there is any possibility of confusion, make help readily available.
  • Avoid really dense content and interactions. Leverage semantic markup such as <section> elements with proper <h1> headings to help group content into navigable chunks.
  • Consider presenting information as needed, rather than presenting it all up front.
    • For example: Instead of printing instructions up front in plain text, instructions on how to use a control may be better presented when the user is hovering or focused on that control (like a tooltip). This helps reduce cognitive load and gives information only when it's needed.

For related information, see: Designing interfaces to meet the needs of users with cognitive disabilities.

Visual Perception

 

  • 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:

HTML:
<span aria-labelledby="left-arrow">&larr;</span><span id="left-arrow" class="hidden">Left arrow</span>

CSS:
.hidden {
	position:absolute;
	left:-10000px;
	top:auto;
	width:1px;
	height:1px;
	overflow:hidden;
}

Resources

Table of Contents

  • No labels