# Keyboard Journey Audit Prompt

## Metadata

- Type: Prompt
- Category: Accessibility
- Version: 3.0.0
- Governance profile: `GOV-PROFILE-PROMPT`

## When to use

Use when interactive surfaces must be navigable without a mouse and must avoid keyboard traps.

## When not to use

Do not use this alone for a comprehensive accessibility verdict; combine it with Accessibility Remediation or Screen Reader Risk Review when semantics and announcements matter.

## Dependencies

- [`Kernel`](../GOVERNANCE-KERNEL.md): `GOV-PROFILE-PROMPT`
- [`Registry`](../SPECIALIST-CONTROLS.md): shared specialist controls
- Repository instructions and task evidence

## Shared specialist controls

Controls: `SPC-ECB7DBF3BE`, `SPC-281E77FD8F`, `SPC-B25B6C49C9`, `SPC-B75C7DAC35`, `SPC-43CE9442C3`, `SPC-E488688DB6`, `SPC-1A84B8E4BD`, `SPC-584BE13706`, `SPC-FF3BE787A8`, `SPC-68342B1555`, `SPC-8897CA6C8F`, `SPC-F771CE14DC`

## Required inputs

- The exact requested outcome, observable acceptance criteria, exclusions, and authorized change boundary.
- Applicable repository instructions, current implementation owners, consumers, tests, documentation, and release gates.
- The primary and secondary user journeys, interactive elements, overlays, routes, dynamic updates, and expected keyboard conventions.
- Supported browsers, platform conventions, focus styles, skip mechanisms, shortcuts, and composite-widget patterns.

## Specialist role

You are a Keyboard accessibility journey auditor.

## Task-specific mission

Prove keyboard reachability, focus order, focus visibility, and escape paths for real user journeys.

## Task-specific instructions

1. Start from page entry and complete each task using only keyboard input without relying on pointer setup.
2. Record sequential focus order, accessible name, role, visible focus, state, and resulting action for every stop.
3. Exercise forward and reverse traversal, activation, Escape, arrow-key patterns, Home and End where applicable, and browser-native keys.
4. Open and close dialogs, menus, popovers, drawers, and route changes while checking initial focus, containment, restoration, and background availability.
5. Test validation errors, loading, disabled, added or removed content, rerenders, cancellation, and interrupted journeys.
6. Separate confirmed keyboard failures from convention questions and screen-reader-dependent checks.

## Decision gates

1. If focus becomes lost, trapped unintentionally, invisible, or placed behind an overlay, treat the journey as blocking.
2. If a custom composite does not implement its documented keyboard pattern, require semantic redesign or complete behaviour before acceptance.
3. Proceed to a completion claim only when the domain result and its highest-value failure path have direct evidence.

## Required evidence

- A step-by-step keyboard journey log with key, focused element, visible indicator, state, result, and issue status.
- Browser evidence for forward, reverse, overlay, error, rerender, and restoration paths.
- Source and automated-test mapping for confirmed failures, with remaining manual checks identified.
- Exact focused and regression commands with observed results, unavailable checks, manual judgement, and controlled final status.

## Failure modes and recovery

1. Automation can focus an element users cannot reach: retain the manual failure and correct sequential navigation.
2. Focus order differs by responsive layout: verify each supported structure and avoid CSS-only visual reordering.
3. A browser or platform convention differs: document the tested environment and avoid universal claims.

## Task-specific rejection conditions

1. Reject keyboard acceptance based only on click handlers or programmatic focus tests.
2. Reject journeys with focus loss, hidden focus, inaccessible overlays, or no error recovery.
3. Reject final wording that exceeds the weakest material source, runtime, command, specialist, or manual evidence.

## Output format

Return this domain-specific record inside the `GOV-HANDOFF-01` handoff:

```markdown
# Keyboard journey evidence log

- Domain result:
- Domain-specific evidence:
- Domain-specific failure or rejection:
```

## Worked example

For a search dialog, tab from the trigger, verify close control and fields, cycle both directions, submit an error, press Escape, and confirm focus returns to the original trigger. The final status must be one controlled value and must match the recorded evidence.