Task 8 · Level 1 HCI external

Accessibility in Context — evidence, users, tasks and purpose

Accessibility is not a tally of options. Students trace what an observable interface decision lets a particular user do, in a particular task, and whether that helps the interface fulfil its purpose.

Duration 65 minutes
Level Level 1 HCI external
Mode Model · test · audit · challenge
Evidence A familiar game or non-game interface
Captions and subtitles Colour and contrast Remappable controls Input alternatives Readable scaling Audio and visual cues Difficulty and accessibility options

Learning intentions

  • Analyse an accessibility-related feature through a specific user, task and interface purpose.
  • Select the most precise usability principle when more than one lens could plausibly apply.
  • Make a defensible judgement that includes a counterargument or limitation.

Success criteria

  • I describe what the interface actually does, rather than praising a feature by name.
  • I connect feature → principle → user/task → usability effect → interface purpose.
  • I explain who benefits, what remains difficult, and why my chosen principle is more precise than a plausible alternative.
  • I use two pieces of evidence from an interface I know well.

Non-checklist framing: the seven feature families on this page are places to look, not seven marks to collect. A caption toggle does not prove that captions are accurate; a high-contrast theme does not prove every state is distinguishable; an absent option is not automatically a serious failure for every user and task. The quality of the analysis comes from the relationship among evidence, user, task and purpose.

Before the lesson

Prepare access

Students need the clean audit sheet and access to one familiar interface. A game is welcome but not required: a learning platform, streaming app, map, creative tool or transport interface can yield equally strong evidence.

Prepare a fallback

Have one school-approved interface ready for students who cannot install, sign in to or safely show their first choice. Do not require students to disclose a disability or private accessibility setting.

Test the evidence

Open the settings or access menu on the model interface before class. Record what is observable today; interfaces change, so avoid teaching from a remembered menu.

Position existing resources

Techquity or DTTA material can supply accessible starting examples. This lesson adds the analytical demand: students must test a feature in use and connect it to purpose, not reproduce a list of labels.

The five-link evidence chain

  1. Observable feature What can you point to, switch on, try, compare or reproduce?
  2. Most precise principle Which usability lens best explains this evidence, and what is a plausible second lens?
  3. User and task Who is trying to do what, and under which relevant conditions?
  4. Usability effect What changes in access, errors, effort, efficiency, learning or control?
  5. Effect on purpose Does that change help the interface achieve what it exists to do?

Think-aloud model: captions in a tutorial player

Feature: spoken instructions can be displayed as captions, including meaningful sound cues. Principle: accessibility is the strongest lens; visibility of system status could also matter in one part of the sequence. User/task: a learner who cannot rely on the audio is following the steps while using the tool. Usability effect: the learner can recover the instructions without repeated guessing or replay. Purpose: the player is more able to teach the procedure independently. Limit: the option alone is weak evidence until caption accuracy, timing, coverage and obstruction have been checked.

Observable feature menu

Use these as investigation prompts. Students should select the two pieces of evidence that produce the strongest analysis, rather than trying to mention every category.

Captions and subtitles

Check availability, accuracy, timing, speaker identification and meaningful sound cues. “There is a CC button” is only the beginning of the evidence.

Colour and contrast

Compare text, controls, focus, warnings and selected states. Ask whether meaning is communicated by colour alone and whether the state remains distinguishable.

Remappable controls

Try changing an input, then check tutorials and prompts. A remapped action helps only if the rest of the interface continues to make sense.

Input alternatives

Look for more than one workable input route—keyboard, pointer, touch, controller, switch or voice where supported—and test the full task, not one screen.

Readable scaling

Increase text or interface scale and observe wrapping, clipping, overlap, focus order and whether essential controls remain available.

Audio and visual cues

Find important information conveyed through sound, image, movement or vibration. Ask whether another channel carries the same useful meaning.

Difficulty and accessibility options

Observe what the setting actually changes. A difficulty option may support access in context, but “easier” and “accessible” are not interchangeable definitions.

The missing user question

For every feature, ask: useful for whom, doing which task, and at what cost? Avoid treating one imagined user as representative of everyone.

65-minute lesson sequence

Time Phase Teacher and student action Evidence to notice
0–5 Silent feature hunt Show the settings/access menu of the model interface without commentary. Students record three things they can actually observe and one thing they cannot yet know. Do they distinguish evidence from assumptions?
5–12 Reframe accessibility Introduce the non-checklist statement and the five-link evidence chain. Contrast “it has subtitles, so it is accessible” with a question about a specific user completing a specific task. Students can name why feature presence alone is insufficient.
12–20 Teacher think-aloud Model the tutorial-player caption example. Deliberately name an alternative principle, then explain why accessibility is the more precise lens for the claim being made. Listen for the complete chain through interface purpose.
20–32 Ambiguous cases Pairs analyse the four fictional interfaces on the audit sheet. Require a first choice, a plausible second lens and the evidence that tips the judgement. Share one disagreement rather than racing to unanimity. Alternative answers are supported by evidence, not label association.
32–50 Familiar-interface audit Students select a familiar game or non-game interface, define its user, task and purpose, scan the feature menu, then complete two deep evidence records. Circulate with “show me” and “for whom?” prompts. Two observable features; each traced to a task and purpose.
50–60 Peer challenge Partners challenge one claim: offer a different principle, user, condition or limitation. Writers either revise their judgement or defend it with more precise evidence. A substantive counterargument changes or strengthens the claim.
60–65 Individual exit Students submit their strongest single chain plus one honest limitation. Use this to decide who is ready to compare principles in Task 9. Independent chain reaches purpose and includes a limitation.

Kaiako key: ambiguous cases

Detailed guidance · keep off the student sheet

A · Night Signal: complete subtitles, but an off-screen threat's direction is communicated only by sound

Strongest lens: accessibility through equivalent cues

The subtitles improve access to dialogue and identify that a threat exists, so “partly effective” is stronger than “accessible” or “inaccessible” as a total label. A player who cannot rely on directional audio can detect danger but cannot locate it, increasing search effort and avoidable failure in the navigation task. That weakens the game's purpose of enabling informed play. Visibility of system status is a plausible second lens because threat direction is a system state; accept it if the student explains why that state, rather than disability as a label, is central. A strong limitation notes that adding a visual direction indicator could increase screen clutter, so placement and optionality matter.

B · Studio Sketch: a high-contrast theme, but the selected tool is shown only by a blue/teal outline and toolbar icons have no text labels

Strongest lens depends on the precise claim

For the claim “the theme makes text and panel boundaries easier to distinguish,” accessibility is precise and the effect is positive. For the selected tool, recognition rather than recall or visibility of system status may be equally defensible: the user cannot readily tell which tool is active. The mixed evidence is the point. A student should not award the whole interface an accessibility verdict because one mode exists. The user may read the panels more easily yet still make marks with the wrong tool, undermining the app's creative-production purpose. “High contrast helps everyone” is too broad unless tied to an observed task.

C · Turbo Track: controls can be remapped, but tutorial prompts keep showing the original buttons

Accessibility/flexibility benefit, then a consistency cost

Remapping can make the driving task physically workable or more efficient for a particular player, supporting accessibility and flexibility. After remapping, however, a prompt such as “Press A” no longer matches the player's chosen control. That inconsistency increases memory demand and errors while learning. The strongest lens therefore depends on the sentence being argued: the setting itself is a benefit; the unupdated prompts are a consequential limitation. The best judgement weighs both and recommends dynamic prompts, not removal of remapping.

D · Ako Stream: a 200% text option exists, but the enlarged Continue button overlaps the progress control and cannot be selected

Strongest lens: accessibility/readable scaling has failed in use

The existence of the option is not the outcome. At the tested scale, a user can read the label but cannot complete the next-step task, so operability falls and the learning stream cannot fulfil its purpose. Aesthetic and minimalist design is a plausible secondary lens if a student focuses on crowding, while visibility of system status could apply to the obscured progress control. Neither alternative explains the blocked task as precisely as readable scaling. A useful limitation is that this is evidence from one scale, screen size and task; it does not justify claims about every viewport.

Marking cue: do not require the same principle label when a student has made a different, precise claim. Reward the evidence chain. A strong response identifies the observable behaviour, defines the user and task without stereotype, explains a usability consequence, reaches the interface purpose, and deals honestly with a plausible alternative or limitation.

Student resource

Task 8 accessibility audit

A clean, print-ready evidence sheet with the ambiguous cases, a feature-observation menu, two deep audit records, and a required counterargument.

Open student audit sheet →

Transition management

  • Feature hunt → framing: preserve the “cannot yet know” column. It becomes the evidence for why a menu is not a checklist.
  • Model → ambiguous cases: leave the five-link chain visible, but hide the modelled answer before pairs begin so students cannot substitute its nouns for reasoning.
  • Cases → familiar audit: students must write interface, user, task and purpose before opening settings. This prevents the settings menu from deciding the argument for them.
  • Audit → peer challenge: partners challenge only one claim and return it. A focused counterargument is more useful than swapping and marking whole sheets.
  • Peer challenge → exit: announce two minutes, then one minute. The exit is individual and should use revised reasoning, not a copied partner response.

Teacher reflection

Which students still counted settings rather than testing what happened during a task?

Which ambiguous case generated the most precise disagreement? What evidence helped students decide?

Did students choosing games and students choosing non-game interfaces both reach purpose, or did one group need a different model?

Who can now state a limitation without cancelling their whole argument? What needs a retrieval prompt at the start of Task 9?