932. Lesson identity
933. Learning objective
After this lesson, you can annotate a system map with accessibility requirements for input, timing, text, color, audio, and feedback, linking each relevant constraint to an implementation owner and at least one observable acceptance criterion while preserving gameplay ownership boundaries.
934. Why this matters
Accessibility is not a cosmetic pass applied after a system is complete. It changes what the system must accept, communicate, and make observable. A mechanic that depends on rapid input, a color distinction, or an audio cue has a contract with the player; accessibility requirements may expand that contract with alternatives, adjustable timing, or redundant feedback. When those requirements are recorded on the system map with an owner and observable criterion, they can guide implementation without transferring gameplay decisions to presentation or input systems.
935. Prior knowledge
You should be able to describe system boundaries, gameplay events, presentation channels, and interruption or priority decisions from Modules 2.1–2.14. In particular, you should be able to distinguish a gameplay rule from the way that rule is presented to the player.
936. Core concept
Accessibility changes the contract surface of a system.
The contract surface is the set of conditions a player must be able to meet and the signals the game must provide for the player to act, decide, and recover. Accessibility work examines each boundary:
- Input: What actions can the player perform, and are alternatives available when a method is difficult or unavailable?
- Timing: Does success depend on reaction speed, sustained input, or a narrow timing window? Can the requirement be adjusted or replaced?
- Text: Are instructions, state changes, and consequences readable, translatable, and available without relying on visual styling alone?
- Color: Does a player need to distinguish colors to identify a state, target, or warning? What non-color signal carries the same meaning?
- Audio: Does a sound communicate a required event? Is the event also exposed through text, visual change, vibration, or another channel?
- Feedback: Can the player tell what happened, why it happened, and what action is available next?
For each relevant constraint, the system map should identify an implementation owner and an observable acceptance criterion. Ownership makes the boundary actionable; the criterion makes the requirement inspectable. The gameplay owner retains responsibility for the rule, state change, consequence, and difficulty contract. Input and presentation owners adapt how the player performs or perceives that contract; they do not silently redefine the gameplay outcome.
The design goal is not to duplicate every signal everywhere. The goal is to identify information and actions that are required by the game contract, assign each accessibility requirement to the boundary that can implement it, and provide an appropriate accessible path to it.
937. Mental model
Use the Boundary → Requirement → Alternative → Owner → Evidence model:
| Step | Question | Example output |
|---|---|---|
| Boundary | Where does the player meet the system? | Hold a button while a threat approaches |
| Requirement | What must the player perceive or do? | Notice the threat and sustain input for two seconds |
| Alternative | What other path preserves the intended meaning or action? | Toggle input, adjustable timing, and a visual threat indicator |
| Owner | Which implementation boundary is responsible, and what remains gameplay-owned? | Input owner handles toggle; presentation owner handles indicator; gameplay owner keeps the threat rule and consequence |
| Evidence | What observable condition shows that the requirement works? | Without audio, the player can see the threat, complete the action, and identify its result |
Apply the model separately to input and presentation. An alternate input method does not automatically solve an inaccessible output signal, and an additional visual cue does not solve an action that still requires an unavailable control pattern. When assigning ownership, preserve the gameplay boundary: adapters may change access to a rule, but they should not decide whether the rule succeeds or what consequence follows.
938. Concrete example
Imagine a checkpoint interaction in which the player must stop a moving cursor over a target. The original design may depend on three conditions:
- The player sees a color-coded target.
- The player hears a short tone when the cursor enters the target.
- The player presses a button during a narrow timing window.
Annotate the contract surface rather than jumping directly to a UI solution:
| Boundary | Original dependency | Accessibility requirement | Possible alternative or observation | Implementation owner | Observable acceptance criterion |
|---|---|---|---|---|---|
| Presentation | Target is identified by color | Color cannot be the only state signal | Add a shape, label, pattern, or explicit state text | Presentation owner | With color differences removed, the player can identify the target from the non-color signal |
| Audio feedback | Tone indicates target entry | The event must be available without audio | Add a visible state change and optional vibration | Presentation or feedback owner | With audio muted, target entry produces a visible state change the player can identify |
| Timing | Success requires a narrow window | Reaction speed may be a barrier | Offer adjustable timing, a pause, or a non-timed interaction | Gameplay owner, with input support | The selected timing option changes the allowed window without changing which target counts as correct |
| Input | One button confirms the action | The action must not depend on one control pattern | Permit remapping or an alternate confirmation method | Input owner | The remapped or alternate control produces the same confirmation event as the original control |
The gameplay owner remains responsible for the rule that determines whether the target is correct and what consequence follows. Input and presentation owners provide accessible ways to perform or perceive that rule. Each alternative must still be checked for clarity and for unintended effects on difficulty or progression.
939. Common mistake
A common mistake is to treat accessibility as a list of settings detached from system design or to assign every requirement to the interface owner. For example, adding subtitles may expose spoken dialogue, but it does not necessarily expose a sound that warns the player about an approaching threat. Similarly, allowing button remapping does not help if success still depends on an unadjustable reaction window. Trace each required piece of information and each required action to its boundary, assign an owner, and state an observable criterion. Keep the gameplay rule, state change, and consequence with the gameplay owner unless the design explicitly changes them.
940. Guided practice
Create an accessibility annotation for one small interaction from your system map. Use a checkpoint, warning, menu action, or combat response; do not redesign the whole game.
- Write the intended player decision in one sentence.
- List every input, timing, text, color, audio, and feedback dependency involved in that decision. Mark categories that do not apply as “none identified.”
- For each relevant dependency, record the boundary where it occurs: input, rule/state, or presentation.
- Add at least one requirement or risk for each relevant category.
- Propose one alternative or redundant signal for the highest-risk dependency.
- Assign each relevant accessibility constraint to an implementation owner. Use the gameplay owner for the rule, state change, consequence, or difficulty contract; use input or presentation owners only for access and communication responsibilities that belong to those boundaries.
- Write at least one observable acceptance criterion for every relevant constraint. State what a player can perceive or perform, under the specified constraint, and what result remains the same.
- State what the player should be able to perceive, do, and confirm if the alternative is working.
Required design decision: Choose which dependency is highest risk and justify the choice using player action, required information, and consequence of failure. Do not choose an alternative merely because it is easy to implement. Also explain why the assigned owner can implement the requirement without taking ownership of the gameplay rule or consequence.
941. Validation / evidence
Your annotation is sufficient when it contains:
- One clearly stated player decision.
- A boundary for every identified dependency.
- Separate treatment of input and presentation requirements.
- An implementation owner for every relevant accessibility constraint.
- At least one observable acceptance criterion for every relevant accessibility constraint.
- Acceptance criteria that describe player-observable perception or action and preserve the intended gameplay result.
- Explicit gameplay ownership for the rule, state change, consequence, or difficulty contract, where applicable.
- At least one alternative input path, timing adjustment, or redundant presentation signal where relevant.
- A justification for the highest-risk dependency that refers to the game contract rather than implementation convenience.
A peer or future tester should be able to point to each constraint, its owner, and its criterion, then ask, “What must remain possible, and how will we know the player received the necessary information without changing who owns the gameplay decision?”
942. Key takeaways
- Accessibility requirements belong on the system boundary, not only in a later interface checklist.
- Input, timing, text, color, audio, and feedback are distinct dependencies that require separate inspection.
- Every relevant constraint needs an implementation owner and an observable acceptance criterion.
- Input and presentation owners can change access and communication without taking ownership of the gameplay rule, state change, or consequence.
- An alternative should preserve the intended action or information, not merely add another presentation effect.
943. Next lesson
Continue to 2.15 L2 — Validate access paths, not only the default path.
944. Knowledge check
Answer these items for yourself before reading the answers.
What does the contract surface describe?
Show answer and feedback
Answer: The conditions the player must meet and the signals the game provides for action, decision, and recovery
Why: The contract surface includes both what the player must perceive or do and what the game must communicate so those actions and decisions remain possible.
Why should input and presentation be annotated separately?
Show answer and feedback
Answer: An alternate input method does not automatically make required output information accessible
Why: A player may be able to perform an action through an alternate control while still missing the information needed to decide when or why to perform it.
Which annotation provides the strongest accessibility evidence?
Show answer and feedback
Answer: “Without audio, the player sees the warning, can pause the response window, and can confirm what caused the state change.”
Why: Strong evidence states what the player must be able to perceive, perform, and confirm under the relevant constraint.
Which option correctly distinguishes a gameplay-owned rule or consequence from an input or presentation accessibility requirement?
Show answer and feedback
Answer: Gameplay owns whether the target is correct and what consequence follows; input or presentation owns remapping the action or adding a non-color signal for that same result
Why: The gameplay boundary owns the rule, state change, consequence, and difficulty contract. Input and presentation boundaries can change how the player performs or perceives that contract without silently changing its outcome.