Lumen Learning Analysis of Utility Simulation

Owned by Jonathan Hung
Last updated: Apr 12, 2017
9 min read

Introduction

The Floe Project assisted Lumen Learning by performing an analysis of some of the interactive assessments and learning tools within their platform. Floe provided Lumen short-term and long-term recommendations to help improve accessibility and inclusion. From this partnership, Floe created the "(Inclusive) Web Games and Simulations" entry in the Inclusive Learning Design Handbook as a resource to help other organizations.

The following is an analysis of the 'Utility Simulation'. The findings below are not exhaustive - rather it provides examples of the kinds of issues to be aware of. Where appropriate, recommendations, resources, and possible solutions are given.

Also see Inclusivity and Accessibility of Interactive Web Games and Simulations for additional resources and guidance on creating accessible and inclusive interactive content.


Table of Contents


Significant Issues

IssueReccomendation

For students who are more willing to explore and experiment, this simulation works well for them. If a student is more cautious or likes to understand things before acting, this simulation is unforgiving. Many times the learner is:

  • forced into advancing even though they may not be ready
  • unable to go back and choose different options
  • not given opportunity to review concepts
  • Give more options for users to retry and review.
  • Change wording of choices as to not make the student feel they have failed to understand.

Screen readers offer higher degree of control of navigation than just conventional keyboard interaction. This unfortunately allows a screen reader user to get into states which break the experience of the simulation:

  • items which are supposed to be non-interactative and hidden are focusable by the screen reader and are read out loud
  • inconsistent focus order
  • Elements which are supposed to be completely hidden to users, including screen readers, should follow established techniques.
  • Improving document structure through use of HTML semantic elements, and WAI-ARIA should help improve screen reader navigation and focus order.
  • Focus order should go from top to bottom and left to right in most cases.
  • Test with users of screen readers and keyboard users to further identify issues.
Important visuals (like graphs and tables) are background images which are inaccessible to screen readers. These images also lack any text descriptions.
  • Use W3C recommended technique for describing complex graphics.
  • Background images are for cosmetic purposes only. Graphs should have appropriate use of <figure> and <img> elements.
  • Graphs should have data tables (possible implementation described later in this document)
  • Tables should be HTML <table> and not images.

Choices

Issue

  • Some screens only have 1 option and forces the player forward.

  • Sometimes offer more choices or opportunities to seek out further explanation.

  • Example: in the definition of margin, the choices are either “Got it” or “Grumble”. In both cases it assumes the learner understood what margin meant which may not be the case.

  • Example: on the node that says “Let’s take our little animal example and apply a few economist tools to it”, the user is forced to advance. Perhaps give choices for users to review topics like margin and utility.

Recommendation

  • Change the wording to be more accommodating.
  • Also see "Interface Vocabulary" below.
  • Provide opportunities for users to review, revisit, or retry before proceeding.

Issue

  • Sometimes it is unclear what some choices mean.

  • “Say that in English”

    • implies that there is "something wrong" for not understanding it

    • What is the outcome? The words are already in English.

    • Users need to be familiar with this colloquial language.

  • “Say that as an economist might say it”

    • Unclear what this means and what the outcome is.

Recommendation

  • Change the wording to make it clear what the outcome would be.
  • See "Interface Vocabulary" below for recommendation on changes.

Issue:

  • There is a lack of closure on after going through the Marginal Utility per Hour sim (choosing between Apples and Berries). It just ends rather abruptly.
  • Feedback (i.e. "Great" / "Excellent") wasn't enough to offset the feeling that you could have made better choices.

Recommendation:

  • Add a reflection / summary at the end to recap what you should have learned.
  • Feels like there are multiple paths through the MU sim, but there's no way to go and explore those options. Give users the opportunity to retry parts of the sim to learn something new.


Interface Vocabulary

While the overall tone of the simulation is humorous, there are instances where the vocabulary used may be at odds with the state of the player. This creates a disconnect between the player and the game - especially for users who may be having a hard time understanding the concepts.

For example, a number of times the interface only gives the player the option to advance by selecting "Got it", "I agree" etc. when in fact the player may not "get it" or even understand enough to "agree".

In these cases it may be more appropriate to assume a more accommodating tone.

 

Current PhraseExample Revision
Got it.Okay. Let's continue.
Say it in English.Can you say that more simply?
Say that as an economist might say it.How would you say that in more technical terms?
Go back one.Go back to previous screen.
The "utility" - the value - of water...The "utility" (value) of water ...
Hold on there, cowboy What do you mean...Hold on there. What do you mean ...
I agree. Let's move on.Okay. Let's move on.
If we must.Okay, if we must.
I'm getting bored. What else?That's a pretty graph. What's next?
Makes sense.Alright, what's next?
Grumble. This is why people don't like Econ classes.

Grumble. This is why people don't take Economics classes.

Apples. (4 hours)Apples. (Takes 4 hours)

Grammatical Errors

For screen readers, punctuation helps control flow of speech and there are a few cases of missing punctuation.

Examples:

PhraseError
Hold on there, cowboy What do you mean by "at the margin"?Missing period
The "utility' -the value - of water ...Mis-matched quote. Use either a single quote, or double quote.
Economists don't like terms like "very thirsty" or "not very hungry."
Period should be placed after last quote.

 

Keyboard Navigation and Mouse Interaction

  • There is an invisible focusable link to branchtrack.com in the top-right corner.
  • If it is important for this to the the first focusable item, make sure it is visible on screen.
  • Otherwise if it isn't important, consider putting the link visually lower on the screen and have it last in the tab order
  • Can't keyboard focus the "Continue" button.

Nodes and Progress


Issue

 

 

  • Previous choice indicator on top-left: Possibly confusing what the extra bubble at top-left is. It looks like a choice, but it isn’t.

  • What would this bubble sound like to a screen reader? Right now a screen reader would say: “Three Stay in Bed”. Without context it is confusing.

  • It is the first thing to be read by a screen reader after the invisible link in the top-right (see "Keyboard Navigation and Mouse Interaction" above)

Recommendation:

    • remove this to avoid confusion.
    • instead, offer opportunities to review, revisit, and retry parts of the simulation
  • Some nodes have “Go back one” choice.
  • This is potentially very useful to many users - give the player the freedom to review prior nodes more often.

 Cognitive Load

  • There’s no indicator of how many steps are left or how far they have come.

    • it is helpful for users to gauge their progress and orient themselves in the simulation.

  • At various points of the simulation, the user is sometimes required to mentally recall the choices they made in the past in order to understand the content that is in front of them. This creates a cognitive burden for users.

  • Example: When giving the number value of utility for the 2nd drink of water, player needs to be able to recall the scenario to provide an appropriate answer.

  • In general, simplifying and reducing cognitive load is desirable.
  • Resource: Designing interfaces to meet the needs of users with cognitive disabilities

Content Accessibility / Screen Readers

Image showing Apple VoiceOver screen reader navigating to elements which are visually hidden, but accessible to screen readers.

Issue:

  • Using screen reader's navigation, you are able to focus on things you're not supposed to which breaks the interaction.
    • Example:
      • There is an invisible list of all the node content which can be accessed through a screen reader. It reads back all the content from other screens.
      • There is a hidden "smiley face" slider off screen. Using a screen reader you can access this.
  • Screen reader keyboard navigation is inconsistent
    • Tab order breaks - sometimes you can't focus on the choices, sometimes you can focus on the "previous choice"
    • navigating using keyboard with screen reader had inconsistent content ordering. Some times it would focus on choices first and never on the content, other times it would focus on the content first then choices.
    • Note: Screen reader keyboard navigation is different from typical tab focusing.


Choices Section

Choices should be grouped within a <section> element and have an <h1> to label it:

 <section>
	<h1>Choose a response:</h1>
	<ol>
		<li><a href=...>Go back one.</a><li>
		<li><a href=...>What about price?</a><li>
	</ol>
</section>

Punctuation

Some missing punctuation. 

Example: At the end of the animal gathering scenario, it says: “Hold on there, cowboy  What do you mean by "at the margin"?  What margin? I didn't see any margin.” Missing a period.

Colours and Contrast

 

Charts

Water vs. Food line Chart

  • The chart is a background image and lacks alt-text

Recommendation:

  • Make the chart an image and use <figure> element as suggested here:  http://www.w3.org/WAI/tutorials/images/complex/
  • Give a good text description on screen and as alt text
  • Add a "Show Data Table" / "Hide Data Table" button to provide a text alternative. See below for an example.


Excerpt page from the Design Sketch showing accessibility changes.

 

Marginal Utility Chart showing apples and berries:

 

  • The chart is a background image. Background images are not accessible to screen readers

  • Ideally this should be an HTML table: http://webaim.org/techniques/tables/

  • Using <del>...</del> or <strike>...</strike> (deprecated) is not recommended here as it would create a jolted, confusing experience for screen reader users:

Recommendation:

  • Break into two charts: Apples and Berries.

  • Delete column "Apples from Tree" and make a row headers instead.

  • When an apple / berry has been eaten, change the text in the row header to convey this new state.
 Marginal Utility
Apple Tree 1 - Eaten20
Apple Tree 219


Excerpt page from the Design Sketch showing accessibility changes.

 

Data Table Hide Show Data Table Button

Approach: Following the <figure> structure documented at W3C, coupled with Aria and Javascript.

 

Before "Show Data Table" button press:
<figure role="group">
    <img
        src="chart.png"
        alt="Bar chart showing monthly and total visitors for the first quarter 2014 for sites 1 to 3">
    <figcaption>
		<p class="button">
			<button id="button1" class="buttonControl" aria-controls="t1"><span>Show</span>Show Data Table</button>
		</p>
    </figcaption>
</figure>

After "Show Data Table" button press:
<figure role="group">
    <img
        src="chart.png"
        alt="Bar chart showing monthly and total visitors for the first quarter 2014 for sites 1 to 3">
    <figcaption>
		<table>
			<caption>Possible combinations of water and food gathered in a 5 hour period.</caption>
			<tr> 
				... 
			</tr>
		</table>
		<p class="button">
			<button id="button1" class="buttonControl" aria-controls="t1"><span>Show</span>Hide Data Table</button>
		</p>
    </figcaption>
</figure>

 

Math

Some nodes have some basic math notation. Ensure that screen reader has the expected behaviour.

Design Sketch with Accessibility and Inclusivity Changes

The following is a design sketch showing some possible improvements that improve accessibility, inclusiveness, and usability. The sketch incorporates some of the suggested improvements documented above.


Download the PDF version