Turn Keyboard Test Notes into Accessibility Tickets

Manual keyboard findings are easiest to fix when the ticket records the exact key path, focus movement, blocked user task, and retest criteria.

Use this guide when a test note says something like "keyboard issue in checkout" and you need a ticket a developer can reproduce without seeing the original audit session.

Open this keyboard finding in the generator

What to keep from the raw note

Starting point: where focus is before the problem starts.
Key path: Tab, Shift+Tab, Enter, Space, Escape, arrow keys, or character keys.
Actual focus movement: where focus goes, disappears, loops, or becomes hidden.
Expected focus movement: the next logical control, dialog, error summary, or trigger return.
Blocked task: buying, logging in, applying a filter, recovering from an error, or dismissing a modal.
Environment: browser, viewport, device keyboard, and any sticky header or overlay state that affects focus.

Ticket structure

Title:
[Severity] Flow or component: keyboard user cannot [complete the task]

User impact:
Name the user task that becomes blocked, confusing, or slower.

Evidence:
- Page or flow:
- Browser and viewport:
- Starting focus:
- Key path:
- Actual result:
- Expected result:

Likely WCAG references to verify:
- 2.1.1 Keyboard, when a control cannot be operated by keyboard.
- 2.4.3 Focus Order, when focus moves in an unexpected or illogical order.
- 2.4.7 Focus Visible, when users cannot see current focus.
- 2.4.11 Focus Not Obscured, when sticky UI covers the focused element.
- 2.1.2 No Keyboard Trap, when users cannot leave a component with keyboard.
- 4.1.2 Name, Role, Value, when custom controls do not expose state or operation.

Acceptance criteria:
- The affected task can be completed with keyboard only.
- The original key path no longer reproduces the issue.
- Focus remains visible and moves in a logical order.
- Any custom control exposes the expected name, role, state, and value.
- Retest covers the same browser, viewport, and component state named in the evidence.

Paste your note into the generator when you want this structure drafted from the raw finding.

Example conversion: skipped control

Raw note:
Checkout payment. Gift card Apply button skipped. Tab goes from input to browser bar. Mouse works.

Developer ticket:
[High] Checkout payment: gift card Apply button is skipped by keyboard navigation

User impact:
Keyboard-only shoppers can enter a gift card code but cannot apply it before payment, so the discount flow is blocked.

Evidence:
- Flow: checkout payment step
- Starting focus: gift card input
- Key path: press Tab after entering a code
- Actual result: focus leaves the page instead of reaching the Apply button
- Expected result: focus moves to Apply; Enter activates it; focus remains in the checkout step

Likely WCAG references to verify:
- 2.1.1 Keyboard
- 2.4.3 Focus Order

Acceptance criteria:
- The gift card Apply button is reachable in the normal Tab order.
- Enter or Space activates the Apply button when it has focus.
- After activation, keyboard focus remains in a useful checkout location.
- The gift card flow can be completed with keyboard only.

Example conversion: focus hidden by sticky UI

Raw note:
Mobile menu open, desktop width 1280. Shift+Tab from first menu item sends focus to logo but sticky promo bar covers it.

Developer ticket:
[Medium] Header menu: keyboard focus is hidden under sticky promo bar

User impact:
Keyboard users cannot tell which header control is active when moving backward through the open menu.

Evidence:
- Viewport: 1280px desktop
- Component state: menu open with sticky promo bar visible
- Key path: Shift+Tab from the first menu item
- Actual result: focus moves to the logo link but the focus indicator is covered
- Expected result: focus remains visible and is not obscured by the sticky bar

Likely WCAG references to verify:
- 2.4.7 Focus Visible
- 2.4.11 Focus Not Obscured

Acceptance criteria:
- Header focus indicators are visible in forward and reverse keyboard navigation.
- Sticky bars, overlays, and clipping do not cover the focused element.
- The menu can be opened, navigated, and closed while focus remains visible.

Common keyboard ticket types

Unreachable control: custom buttons, icon controls, file upload triggers, filters, and payment actions.
Wrong activation key: custom controls that respond to click but not Enter, Space, Escape, or arrow keys.
Illogical focus order: focus jumps across columns, enters hidden content, or skips newly opened content.
Missing visible focus: outlines removed, low-contrast indicators, clipped rings, or indicators hidden behind sticky UI.
Dialog or drawer defects: focus does not enter, leaks behind the overlay, cannot reach close, or does not return to the trigger.
Bypass and skip-link issues: repeated navigation cannot be skipped or the skip link target is not focusable.

Paste-ready input for the generator

Manual keyboard finding:
Page or flow:
Component state:
Browser and viewport:
Starting focus:
Key path:
Actual focus movement:
Expected focus movement:
Blocked user task:
Relevant selector or component:
Retest notes:

Open the accessibility ticket generator and paste this structure with the test note.