Validate access paths, not only the default path

945. Lesson identity

Module

2.15 — Accessibility

Lesson

Validate access paths, not only the default path

Academic type

Workflow

Schema type

Mixed

Order

Lesson 2 in the module

Estimated time

35–45 minutes, including practice

This lesson turns the contract surface from the previous lesson into an executable validation plan. You will test one bounded interaction through its required access paths and produce evidence that another person can inspect and repeat.

946. Learning objective

After this lesson, you can write and execute an accessibility validation plan for one bounded interaction. The plan will define observable outcomes, supported routes, test configurations, presentation signals, timing conditions, feedback, recovery, cross-path stability, evidence dispositions, and follow-up decisions.

947. Validation boundary

This bounded developer-run validation produces implementation evidence for the interaction and configuration tested. By itself, it does not prove whole-game accessibility, usability for disabled players, or formal conformance.

948. Why this matters

A default-path test shows only that an interaction worked through one route under one configuration. It does not establish that a required alternate input works, that state and error information remain perceivable, that the supported timing behavior is sufficient, or that recovery works after a blocked attempt.

A validation record must therefore answer two questions separately:

1. What does the interaction contract require?
2. What was observed in a named build and configuration?

A route, timing accommodation, or feedback alternative that the task requires but the implementation does not support is a gap. It cannot be converted into a pass by calling it a scope decision.

949. Prior knowledge

You should already be able to:

• Describe the contract surface of an interaction: required actions, decisions, feedback, and recovery.
• Distinguish a gameplay condition from the signal that communicates it.
• Identify a bounded interaction and its implementation responsibilities.

These capabilities come from 2.15 — Accessibility: Accessibility changes the contract surface.

950. Four evidence dispositions

Assign exactly one disposition to every criterion and required path:

• Pass: The configured test produced the observable result required by the criterion.
• Fail: The test was executed and the observed result did not satisfy the criterion.
• Unresolved: Evidence is missing, the requirement is unclear, the configuration cannot yet be tested, or no documented threshold supports a pass judgment.
• Not applicable: The criterion does not apply to the task, supported contract, or tested configuration, and the record includes a task-based justification.

Do not use not applicable merely because a route is absent. If the task or a documented project or platform requirement calls for an alternate route, timing accommodation, or feedback alternative and it is unsupported, record a fail or unresolved gap. Assign an owner and a follow-up action.

951. Operational acceptance criteria

Terms such as “readable,” “clear,” “important,” or “enough time” are not pass conditions by themselves. For each criterion, record:

1. Requirement source: The relevant documented project or platform requirement, when one exists.
2. Build and version: The exact build, revision, or configuration identifier tested.
3. Device and input route: The device, control method, remapping, switch route, keyboard route, controller route, or other supported route actually used.
4. Relevant settings: Enabled accessibility, presentation, audio, control, timing, or difficulty settings.
5. Starting state: The state from which the test begins.
6. Action: The exact player action or sequence.
7. Expected signal and state: The observable presentation, feedback, and resulting state required for a pass.
8. Timing condition: A documented limit, measured window, pause state, retry condition, or a statement that no timing threshold applies to this task.
9. Observed result: What actually occurred, including signals, state transitions, timing, and recovery.
10. Disposition: Pass, fail, unresolved, or not applicable.
11. Owner and follow-up: Required for every fail or unresolved item.

Where a documented threshold exists, use it. Where none exists, do not invent one. Record the judgment as unresolved until an authorized requirement or observable criterion is established.

952. The PATHS check

Use the PATHS check for each criterion:

The final immediate retest of the default route is a cross-path stability or state-isolation check. It can reveal shared-state contamination, cross-path interference, or an existing defect. Reserve regression testing for repeating the recorded test after an implementation, configuration, or build change.

953. Example criterion

For a bounded interaction in which a player confirms a selected item, a testable criterion could state:

Starting from the documented selection state in the named build and configuration, each required supported confirmation route changes the selected item to the active state. The active, unavailable, and error states produce the documented text, icon, audio, or other supported signals. The interaction satisfies the documented timing requirement, and a blocked attempt exposes and completes the supported recovery action.

The record must then identify:

• The build and configuration.
• The default and alternate routes required by the task.
• The settings enabled for each run.
• The expected signals for action, status, success, and error.
• The documented timing condition, if any.
• The expected recovery result.
• The observable pass condition for each route.

If the task requires an alternate confirmation route but none is implemented, that route is a gap. Record it as fail or unresolved, assign an owner, and state the next action. If a proposed route genuinely does not apply to the task, use not applicable and explain why in task terms.

954. AI-native workflow

Use AI to challenge the plan, not to declare that execution passed.

1. Draft the interaction requirement and observable criteria without AI.
2. Ask AI to identify ambiguous outcomes, untested required routes, missing configuration fields, unsupported timing assumptions, absent feedback channels, recovery gaps, and state-isolation risks.
3. Compare every suggestion with documented project behavior and applicable requirements.
4. Remove invented controls, settings, channels, and thresholds.
5. Execute the test yourself and record direct observations.
6. Mark missing evidence or unsupported judgments unresolved rather than passed.

A useful prompt is:

Review this validation plan for one bounded interaction. Identify criteria that lack a build, device or input configuration, relevant settings, starting state, expected signal, timing condition, observable pass condition, recovery result, or evidence disposition. Do not invent project behavior or thresholds. Distinguish required-but-unsupported gaps from task-based not-applicable cases.

955. Guided practice

Choose one bounded interaction that you can inspect without redesigning it. Create a validation table with these columns:

Complete the work in this sequence:

1. State the bounded task and its observable successful outcome.
2. List the default route and every alternate route required by the task or applicable documented requirement.
3. Classify each route as supported, required but unsupported, unresolved, or not applicable. Give a task-based justification for every not-applicable entry.
4. Record the build, device or input configuration, relevant settings, and starting state.
5. Define the exact expected state and signals for action, status, success, and error.
6. Record the applicable timing requirement. If no documented threshold exists, do not call an informal judgment a pass; mark it unresolved and identify who must clarify the criterion.
7. Define one blocked or incorrect attempt and the expected recovery result.
8. Execute the default route, a required supported alternate route, and the default route again.
9. Record the immediate final run as a cross-path stability or state-isolation check.
10. Assign pass, fail, unresolved, or not applicable to every criterion. Add an owner and follow-up action for each fail or unresolved item.

956. Evidence record

At least one executed record must contain:

• Build or version.
• Device and input route.
• Relevant accessibility and interaction settings.
• Starting state.
• Action performed.
• Expected state and expected signals.
• Applicable timing condition or documented absence of one.
• Observed presentation and feedback channels.
• Resulting state.
• Recovery result where applicable.
• Cross-path stability result.
• Evidence disposition.
• Owner and follow-up for any fail or unresolved item.

Screenshots, video, logs, or notes can support the record, but an attachment without configuration and observation context is insufficient.

957. Sufficiency criteria

Your work is sufficient when:

• The interaction and observable successful outcome are bounded.
• Every required route has an explicit disposition.
• A required but unsupported route, timing behavior, or feedback alternative is recorded as a gap rather than a scope pass.
• Every pass cites an observable condition and the configuration in which it was observed.
• Every not-applicable judgment has a task-based justification.
• Unsupported thresholds and missing evidence are unresolved.
• Presentation covers the required state, status indicators, success, and error signals.
• Timing is tied to a documented requirement where one exists.
• Feedback channels are evaluated by the information they convey, not merely counted.
• Failure and recovery are executed or explicitly marked unresolved.
• The immediate default-route retest is labeled as cross-path stability or state isolation.
• Fail and unresolved items have owners and follow-up actions.

958. Practical assessment

Complete the attached practical assessment. Submit the validation table and one executed evidence record. The assessment evaluates the observable outcome, supported and required routes, test configuration, presentation, timing, feedback, recovery, cross-path stability, evidence status, and resulting decision.

959. Key takeaways

• Every criterion receives one disposition: pass, fail, unresolved, or not applicable.
• Not applicable requires a task-based justification; it is not a label for missing implementation.
• Required but unsupported routes and alternatives are gaps with owners and follow-up actions.
• A pass requires an observable condition, a named configuration, and direct evidence.
• Immediate retesting across routes checks state isolation; regression testing repeats the record after a change.
• Bounded developer validation is useful implementation evidence, not proof of whole-game accessibility, user usability, or conformance.

960. Next lesson

Carry the completed validation table and evidence record directly into Stage 3 — From game systems to runtime owners. Use the artifact to assign a runtime owner and lifecycle responsibility to each access path, presentation signal, timing behavior, feedback channel, recovery mechanism, cross-path state concern, and evidence record.

961. Knowledge check

962. Knowledge check