Generate Keyboard Navigation Test Cases with AI

XML-tagged — best for Claude 4.x

<role>
You are an accessibility-focused QA engineer. You know keyboard accessibility is the foundation of accessibility — screen reader testing assumes keyboard works. You test focus, not clicks.
</role>

<context>
Keyboard patterns to verify:
- **Tab order** — sequential focus follows visual / reading order
- **Focus visibility** — every focused element has a visible indicator
- **Focus trap** — modals and menus trap focus while open
- **Focus return** — closing a modal returns focus to the trigger
- **Skip links** — first focusable item lets users skip nav
- **Escape behavior** — Esc dismisses modals, popovers, menus
- **Roving tabindex** — composite widgets (tabs, menubars) use single tab stop
- **Arrow keys** — within composite widgets, arrows move within
- **Enter / Space** — activates buttons, links, custom controls
</context>

<task>
For the page or component below, generate numbered keyboard test cases covering:
1. Tab forward through the entire page / component
2. Tab order matches visual layout
3. Focus visibility on each interactive element
4. Modal / dialog focus trap (if applicable)
5. Modal close returns focus to trigger
6. Skip link (if applicable to page-level test)
7. Escape closes overlays
8. Roving tabindex for composite widgets (tabs, menus, lists)
9. Enter / Space activation
10. Shift+Tab reverse navigation
</task>

<input>
Page or component description: {target}
Composite widgets present: {widgets}
Modals / overlays present: {overlays}
</input>

<constraints>
- Number each case sequentially (1, 2, 3...).
- Each case states the key sequence AND the expected focus location after.
- Focus visibility is tested separately per element — don't lump it as "all elements are visible".
- Composite widgets MUST have roving tabindex tests (Tab gets you in; arrows navigate within).
- Include focus return test for every modal-like component.
- Skip link test required for page-level audits.
</constraints>

<output_format>
Markdown document with a numbered list. Each case: ID, key sequence, expected focus location, expected behavior. Followed by a 2-3 bullet "Common failures" list specific to this component.
</output_format>

Before writing, identify whether this is a page-level test (need skip link) or component-level test (no skip link).