Accessibility Test Cases

A11Y-KBD-003

No keyboard trap

Generated file current Authoring: Content complete
What file status means

This status reports only whether the generated procedure matches the current controlled source hash. It is not independent content verification, regulatory approval, product evidence or a conformance decision.

Recorded standards review: No optional specialist review recorded. Next review: Not scheduled.

MethodKeyboard journey
TesterGeneral QA tester
Indicative effort40–58 min small scope

Move keyboard focus into and out of each component, including documented non-standard exit methods.

Available formats

Use this test in the format you need

The HTML procedure includes the working worksheet. JSON provides the structured source data. Editable Markdown files are delivered inside package downloads.

Purpose

What this test checks

Move keyboard focus into and out of each component, including documented non-standard exit methods.

What this result means: This No keyboard trap procedure determines whether the recorded targets meet WCAG 2.1.2 on web-desktop-cross-browser in the tested states. A broader conformance decision must also account for every applicable target in the declared scope, complete processes, accessibility-supported use and the other WCAG conformance requirements.

Why it matters

Detect components that trap keyboard focus or fail to tell users how to leave with the keyboard. People most likely affected: people who use a keyboard, switch control, voice input or another keyboard-interface device. A trapped user may be unable to reach later content, return to earlier content or complete the task. In the recorded web-desktop-cross-browser environment, prioritise modal layers, composite widgets, validation and recovery paths, where unreachable controls, an illogical focus sequence or a keyboard trap can stop task completion.

When to use it

Apply when keyboard focus can enter a component. Test both forward and reverse entry and every mode that changes the exit method.

Confirm before starting

Mark it not applicable only when

Exceptions

Non-standard exit method is advised

Decision condition
Focus can be moved away using the keyboard, but doing so requires more than unmodified arrow or Tab keys or another standard exit method; the user is advised of the method before or when the component receives focus.
Evidence needed
Exact exit keys, successful exit sequence, and the programmatically and visibly available instruction with its timing.
Common error
A hidden help page, undocumented Escape key or pointer-only close control does not satisfy the condition.
Scope
Only the component and mode requiring the non-standard exit method.

Prepare

What you need

  • The product area and test targets are agreed before testing starts.
  • The operating system, browser, viewport and input method are recorded.
  • Test data is safe to use and does not expose unnecessary personal information.

Targets and required variations

  • Each component boundary entered by keyboard, including dialogs, embedded content, editors, menus, composite widgets and media players.
  • Forward and reverse entry.
  • Default, open, editing, full-screen, validation, interruption and recovery modes that can change focus containment.

Clean state

  • Complete a known-good calibration in the same environment before product testing.
  • Start from a recorded clean or known state and preserve any prior preferences, extensions, cache or profile settings that can affect output.

Effort estimate

Setup
12 min
Per target
12 min
Evidence
8 min
Technical review
8 min

Assumptions: one short journey with up to ten focusable controls; complex widgets and dialogs add separate scenario runs

Variation: Add a new per-target execution and evidence allowance for each additional target class or state that could produce a different result. Add setup time for each distinct environment.

Excluded: Client coordination, inaccessible-environment recovery, recruitment, legal review, remediation implementation and waiting time unless the procedure states otherwise.

Execute

Test steps

Follow each action in order. The expected result is always visible; open the guidance when you need setup, tool, evidence, decision or repeat details. Step-level recording is optional while work is in progress and required only to export a completed execution.

Step 1

Define one component boundary and exit contract

Purpose: Select one component and document how keyboard users are expected to enter and leave it.

User impact: Unclear boundaries make traps difficult to reproduce and can hide loss of navigation control.

Record the component identifier, trigger, first internal focus target, expected standard exit keys and any documented non-standard exit sequence.

Expected result

One reproducible component/state and its exit contract are recorded.

Failure observation

The tester groups unrelated components together or cannot identify an entry and expected exit path.

Setup, evidence and decision guidance
Target
One dialog, embedded frame, editor, menu, composite widget, media player or full-screen component.
Required state
Closed/default state plus the exact open or editing state to be tested.
Tool or command
Keyboard-only inventory; component documentation where a non-standard exit is designed.
Record
Component ID, route, trigger, state, entry point and expected exit method.
Pass
The selected boundary and expected exit are unambiguous.
Fail
The boundary or exit contract cannot be identified from product behaviour or supplied instructions.
Not applicable
No component in the agreed sample accepts keyboard focus internally.
Blocked
The component cannot be reached in the authorised build or state.
Repeat or recover
Restore the component to its closed state and repeat one boundary at a time.
Limitations
This preparation scenario does not by itself show that a keyboard trap exists.
If you are new to this test
Restore the component to its closed state and repeat one boundary at a time.
Record this step

Step 2

Enter the component with forward navigation

Purpose: Verify forward sequential navigation crosses into the selected boundary predictably.

User impact: Unexpected entry can disorient keyboard and switch users.

Move focus forward until it enters the component. Record the first internal focus target and every key pressed.

Expected result

Focus enters the expected first target without an unrelated context change.

Failure observation

Focus skips the component, enters an unexpected internal target, disappears or triggers an unrequested change.

Setup, evidence and decision guidance
Target
The component selected in S1.
Required state
Focus on the immediately preceding focusable control; component in its recorded start state.
Tool or command
Physical keyboard; press Tab or the platform's recorded forward-navigation key once at a time.
Record
Key sequence, start target, first internal target and focus indicator capture.
Pass
Focus enters predictably and remains perceivable.
Fail
Entry itself is broken; record separately from an exit trap.
Not applicable
The component is intentionally not part of sequential focus and has another documented keyboard entry method.
Blocked
A platform or product error prevents reaching the preceding control.
Repeat or recover
Reload, restore the recorded start state and retry once; if still blocked preserve the last reachable focus target.
Limitations
This scenario assesses forward entry only, not reverse entry or exit.
If you are new to this test
Reload, restore the recorded start state and retry once; if still blocked preserve the last reachable focus target.
Record this step

Step 3

Leave the component with forward navigation

Purpose: Verify the standard forward method can move focus beyond the boundary.

User impact: A user trapped inside a component cannot reach later content or finish the journey.

Navigate through the component and continue forward using its standard keyboard interaction until focus reaches the next external control.

Expected result

Focus reaches a predictable control outside the component without pointer input.

Failure observation

Focus cycles indefinitely, disappears, returns to the same internal targets or requires an undocumented pointer action.

Setup, evidence and decision guidance
Target
The same component in the same mode used in S2.
Required state
Focus on the first internal target after successful forward entry.
Tool or command
Physical keyboard; use only documented in-component keys and Tab until focus should leave.
Record
Full key sequence, internal focus sequence, expected next control, actual final focus and video or focus log when permitted.
Pass
Focus leaves with a standard or timely documented method.
Fail
Focus cannot leave using the permitted keyboard method.
Not applicable
The component contains no internal keyboard focus after S1 review.
Blocked
The environment crashes or the next external target is unavailable because of unrelated build failure.
Repeat or recover
Try the documented cancellation or completion path once; do not use developer tools or a pointer to manufacture an exit.
Limitations
A modal dialog may intentionally contain focus while open; it passes only if a keyboard method closes it and restores focus appropriately.
If you are new to this test
Try the documented cancellation or completion path once; do not use developer tools or a pointer to manufacture an exit.
Record this step

Step 4

Enter the component with reverse navigation

Purpose: Check that approaching the same boundary from the following control does not expose a direction-specific trap.

User impact: Reverse navigation is essential for users who overshoot or review previous controls.

Move focus backward until it enters the component. Record the first internal target reached from this direction.

Expected result

Reverse navigation enters at a predictable boundary target.

Failure observation

Focus disappears, skips required content or enters an internal loop before the boundary can be understood.

Setup, evidence and decision guidance
Target
The component selected in S1.
Required state
Focus on the immediately following external control; component in its recorded start state.
Tool or command
Physical keyboard; Shift+Tab or the recorded reverse-navigation command.
Record
Reverse key sequence, start target, first internal target and state.
Pass
Reverse entry is predictable.
Fail
Reverse entry exposes a broken path that prevents subsequent exit.
Not applicable
No following focusable control exists and the component cannot be approached in reverse within the journey.
Blocked
The following control cannot be reached because of an unrelated blocker.
Repeat or recover
Use a safe deep link or prior journey step only if it is part of the approved test plan; record any alternative setup.
Limitations
A not-applicable reverse path does not override a failed forward exit.
If you are new to this test
Use a safe deep link or prior journey step only if it is part of the approved test plan; record any alternative setup.
Record this step

Step 5

Leave the component with reverse navigation

Purpose: Verify reverse sequential navigation can cross back out of the boundary.

User impact: Direction-specific loops can strand users who navigate backward.

Navigate backward using permitted keys until focus reaches the preceding external control.

Expected result

Focus leaves the component and lands predictably outside it.

Failure observation

Focus loops internally, disappears or requires pointer input or an undisclosed key sequence.

Setup, evidence and decision guidance
Target
The same component after successful reverse entry.
Required state
Focus on the first internal target reached in S4.
Tool or command
Physical keyboard; Shift+Tab or the component's documented reverse/cancel command.
Record
Key sequence, internal focus order and actual external landing target.
Pass
Focus leaves predictably in reverse.
Fail
Focus cannot leave by the permitted keyboard path.
Not applicable
Reverse entry was legitimately not applicable in S4.
Blocked
The state becomes unavailable for reasons unrelated to keyboard operation.
Repeat or recover
Restore and repeat from S4 once; retain both runs if behaviour is intermittent.
Limitations
This scenario covers reverse exit only.
If you are new to this test
Restore and repeat from S4 once; retain both runs if behaviour is intermittent.
Record this step

Step 6

Verify any non-standard exit instruction

Purpose: Ensure a required non-standard escape sequence is disclosed before it is needed and actually works.

User impact: Undisclosed commands leave users trapped even when a technical escape exists.

Locate the exit instruction before entry or when focus enters. Confirm it names the exact command, is programmatically available, then execute it once.

Expected result

The timely instruction is understandable and the exact command moves focus outside.

Failure observation

The instruction is absent, appears only after a failed attempt, is not programmatically associated, names the wrong command or the command does not exit.

Setup, evidence and decision guidance
Target
A component whose designed exit is not a standard platform keyboard method.
Required state
Before focus enters, and again while focus is inside the component.
Tool or command
Keyboard plus accessibility-tree or DOM inspection for the instruction relationship.
Record
Instruction text and relationship, timing, command used and resulting focus target.
Pass
Instruction is timely, available and effective.
Fail
Any instruction or command requirement is unmet.
Not applicable
The selected component uses only standard keyboard exit methods.
Blocked
The instruction cannot be exposed because the build or inspection environment is unavailable.
Repeat or recover
Do not guess hidden shortcuts; request the documented interaction contract and mark blocked until available.
Limitations
Passing this scenario does not excuse a trap in another component state or direction.
If you are new to this test
Do not guess hidden shortcuts; request the documented interaction contract and mark blocked until available.
Record this step

Decide

How to decide

Passed

Keyboard focus can be moved away from the component using only a keyboard interface; when a non-standard exit method is required, the user is advised of that method before or when focus enters.

Failed

Keyboard focus enters the component but cannot leave using a keyboard interface, or a non-standard exit method works but is not advised at the required time.

Not applicable
No selected component accepts internal keyboard focus.
Cannot tell
The component's standard interaction contract or actual focus location cannot be determined after reasonable investigation.
Not tested
The target is applicable, but a required state, environment, action or evidence item was not completed.
Aggregation and reporting boundaries

Aggregation: Preserve one result per component, entry direction and material mode. Any failure prevents a passed aggregate; cantTell and untested remain unresolved.

WCAG decision: This atomic check can fully address its target condition, but a WCAG 2.1.2 decision still depends on complete scope coverage and WCAG conformance requirements.

Automation: Automation may identify focusable elements but cannot prove that a user can leave every component mode or that non-standard instructions are timely.

Record

Record the result

Record the target, state and observed behaviour. Add evidence or technical details only when needed.

Choose the option that best matches what happened to this target.

Describe the actual behaviour and why it supports the selected result.

When more than one target is recorded, the overall procedure result is calculated from all target results.

Environment: Not set.
Add evidence or details

Choose only the group needed for this record. These fields remain optional for a working draft.

Evidence references

Enter one file name, issue ID or evidence reference per line. Files stay on your device.

Test environment

Save a named profile once to reuse the same product, platform and environment details on other procedures in this browser.

Engagement and tester identifiers

WCAG report decisions

These report-level decisions are separate from the target outcome and require complete declared-scope evidence.

Formal completion and limitations

Identify the frozen list or sampling record used to select every target represented by this execution.

Choose a final result before marking the execution complete. Completed records require the full environment, step, evidence and method-specific information.

Data management

Export before clearing if the record must be retained. Apply the engagement retention schedule and delete browser data when it is no longer needed.

Saved drafts stay in this browser and are not uploaded. Do not enter credentials, secrets or unnecessary personal data.

Reference

Supporting information

Standards and requirement mappings
  • W3C-WCAG22 · 2.1.2 conformance · full

    This atomic check does not establish that every function is keyboard operable under WCAG 2.1.1 or that focus order is meaningful under WCAG 2.4.3.

  • W3C-ARIA-APG · W3C-ARIA-APG advisory · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

  • MICROSOFT-EDGE-A11Y · MICROSOFT-EDGE-A11Y advisory · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

  • W3C-WCAG22-TECHNIQUES · W3C-WCAG22-TECHNIQUES advisory · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

Supporting and advisory guidance

Supporting sources are identified in the mappings and source register. They do not add conformance requirements.

Evidence specification
  • Component inventory

    Component, mode, entry directions and expected exit method.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Focus sequence

    Exact keystrokes, focus sequence, exit target and pointer-free result.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Instruction evidence

    Non-standard exit instruction, timing and programmatic exposure where used.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Execution state

    Any operational block, affected scope, alternative environment and remaining requirement.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

Worked example and outcome calibration

A11Y-KBD-003-WORKED-001: representative worked example

Context: Synthetic Civic Benefits Portal eligibility-help modal on the claim form.

Inspected: Forward and reverse entry/exit in the open modal with only Tab, Shift+Tab and Escape.

Observed output: After the last link, Tab cycled to the close button as intended. Escape closed the modal and restored focus. Shift+Tab from the first control also cycled within the modal until Escape was used; the on-screen instruction named Escape.

Evidence:

  • EVD-REF-004 focus sequence log
  • EVD-REF-005 video with focus indicator
  • EVD-REF-006 instruction/accessibility-tree extract

Tester reasoning: Focus containment is appropriate while the modal is open because an available, disclosed keyboard command closes it and restores focus. The internal loop alone is not a trap.

Decision: passed

Finding: OBS-REF-001 — Modal keyboard containment works as documented. Keyboard users can close the modal and return to the triggering control.

Remediation: Retain the visible and programmatically available Escape instruction and the focus-restoration regression test.

Reviewer feedback: Reviewer removed a false failure based solely on focus being contained inside an open modal and required evidence that Escape was disclosed before use.

Final client wording: No keyboard trap was found in the sampled eligibility-help modal. Escape was disclosed, closed the modal and returned focus to the Help trigger in both forward and reverse navigation checks.

Retest: RT-REF-002: no code change required; repeat on build CBP-2026.08.2 produced the same passing focus sequence.

Boundary: This is a representative, synthetic worked example for training and calibration. It is not evidence from a client product, participant or real assistive-technology execution.

Outcome calibration

Passed
Focus enters a rich editor; a programmatically exposed instruction says “Press Control+M to leave editor”, and that command moves focus to the following control.

The non-standard advised-exit condition is met.

Failed
Tab and Shift+Tab cycle inside an embedded player, Escape has no effect, and no keyboard exit is available.

Focus entered and cannot leave by keyboard.

Not applicable
The selected static view has no component that accepts internal keyboard focus.

No component target matches applicability.

Cannot tell
A remote desktop layer obscures the actual focus location and platform key interception cannot be isolated.

The focus result cannot be determined defensibly.

Not tested
Default dialog mode was tested, but its selected full-screen editor mode was not entered.

A required component mode remains untested.

Sampling, complete processes and platform limitations

Run each selected critical journey from start to finish, including its main error and recovery paths. Record which journeys and states were included.

If this check is part of a user journey, test the selected journey from start to finish, including relevant errors and recovery. Record any path that was not tested.

  • This keyboard journey does not establish compatibility with every switch device or speech-input system.
  • Check relevant browser, tool or assistive-technology release notes before assigning unexpected behaviour to the product.
  • If responsibility is unclear, record the reproducible behaviour and use cannot tell until it is resolved.
Related procedures
  • A11Y-WCAG-022
ACT rules and WCAG technique traceability

This is a project-authored manual procedure, not a W3C Approved ACT Rule. An ACT result can support only the part of this procedure covered by that rule. It does not replace the remaining manual or assistive-technology checks.

No supporting W3C Approved ACT Rule is selected for this procedure.

  • Understanding SC 2.1.2. Techniques are examples, not extra requirements. Record any technique or common failure used, but decide the result against the success criterion.
Review history and source register
  1. 2026.08.27-rc.9 — Reworked for plain language, case-focused steps, scoped evidence and transparent draft review status.
  2. 2026.08.27-rc.9 — Migrated to professional catalogue schema v3 with separated outcomes, structured authority, applicability, evidence, decision and review records.
  3. 2026.08.27-rc.9 — Specialist procedure mapped to its task family and current first-party platform guidance and checked for internal consistency; competent review and real execution remain separate.
  4. 2026.08.27-rc.9 — Replaced migrated boilerplate with a case-specific reference implementation and completed generated-file integrity review.
  5. 2026.08.27-rc.9 — Rewritten as an atomic professional-delivery flagship with component effort guidance and a complete representative worked example.
  6. 2026.08.27-rc.9 — Procedure guidance and presentation simplified without changing draft governance status.

Review decision: pending. Open issues: Independent method and standards review and keyboard calibration execution remain required before status promotion.

Source historyReport an accuracy issue
WCAG
SC 2.1.2
Execution
Manual test with tool support
Catalogue version
2026.08.27-rc.9