a11y-manual-test-scripter

Generates a numbered, step-by-step manual test script covering keyboard navigation and screen-reader (NVDA / VoiceOver) verification for a given component or page, with every test case mapped to its WCAG 2.2 Success Criterion.

When invoked

Inputs the agent requires:

• Component or page name - e.g. "ConfirmDialog", "CheckoutForm", "NavMenu".
• List of interactive widgets present - e.g. modal dialog, combobox, menu button, tabs, text inputs, toggle buttons.
• ARIA roles claimed (optional) - if available from source or design spec.
• Target browser / AT version - defaults to NVDA + Firefox (Windows) and VoiceOver + Safari (macOS).

Step 1 - Identify interactive elements and roles

Read the component source (or design spec) with Read / Grep to list:

1. Every focusable element: native <button>, <a href>, <input>, <select>, <textarea>, plus any tabindex="0" custom elements.
2. ARIA roles on composite widgets (role="dialog", role="combobox", role="menu", role="tab", role="listbox", etc.).
3. Expected ARIA states: aria-expanded, aria-selected, aria-pressed, aria-checked, aria-disabled.
4. Programmatic labels: <label for>, aria-label, aria-labelledby, aria-describedby.

Output a widget inventory table:

Widget	Element / Role	Expected name	Expected states
Open dialog button	<button>	"Open settings"	-
Modal	role="dialog"	"Settings"	-
Close button	<button>	"Close"	-
Email input	<input type="email">	"Email address"	aria-required="true"

Step 2 - Keyboard test cases

One test case per widget, per key behavior. Base every expected behavior on the WAI-ARIA Authoring Practices Guide (APG) pattern for that widget (https://www.w3.org/WAI/ARIA/apg/patterns/, fetched 2026-06-03).

Standard navigation (all widgets)

Per WebAIM keyboard testing, fetched 2026-06-03: Tab navigates forward through focusable elements; Shift+Tab navigates backward. Test these for every interactive element.

WCAG mapping: 2.1.1 Keyboard ("all functionality operable through a keyboard interface"), 2.4.3 Focus Order ("focusable components receive focus in an order that preserves meaning and operability"), 2.4.7 Focus Visible ("keyboard focus indicator is visible") - all from WCAG 2.2, fetched 2026-06-03.

Modal dialog

Per APG Dialog (Modal) pattern, fetched 2026-06-03:

Step	Key	Expected behavior
Open dialog	Enter / Space on trigger button	Dialog appears; focus moves to first tabbable element inside dialog (or dialog heading) - key activation per [apg-button]
Tab inside dialog	Tab	Focus cycles forward through tabbable elements inside dialog; does NOT leave dialog
Shift+Tab inside dialog	Shift+Tab	Focus cycles backward; from first element wraps to last inside dialog
Close via Escape	Escape	Dialog closes; focus returns to triggering element
Close via button	Enter / Space on close button	Dialog closes; focus returns to triggering element

APG specifies: "Tab and Shift + Tab do not move focus outside the dialog" (focus trap). On close, "focus returns to the invoking element."

Menu button

Per APG Menu Button pattern, fetched 2026-06-03:

Step	Key	Expected behavior
Open menu	Enter or Space	Menu opens; focus moves to first menu item
Open menu (alt)	Down Arrow (optional)	Menu opens; focus on first item
Open menu (alt)	Up Arrow (optional)	Menu opens; focus on last item
Navigate items	Down Arrow / Up Arrow	Focus moves through menu items
Close without select	Escape	Menu closes; focus returns to button
Select item	Enter	Item selected; menu closes

Combobox

Per APG Combobox pattern, fetched 2026-06-03:

Step	Key	Expected behavior
Tab to input	Tab	Combobox input receives focus; popup hidden
Open popup	Down Arrow	Focus moves into listbox; first option or autocomplete-suggested option focused
Open popup (alt)	Up Arrow	Focus moves to last option in listbox
Navigate options	Down Arrow / Up Arrow in listbox	Moves focus; selects next / previous option
Accept option	Enter in listbox	Selected value placed in combobox; popup closes
Dismiss popup	Escape	Popup closes; focus returns to combobox input

Text input / form field

Per WebAIM keyboard testing, fetched 2026-06-03: Tab enters and exits; arrow keys navigate within text.

Step	Key	Expected behavior
Tab to field	Tab	Field receives focus; focus indicator visible
Tab away	Tab	Focus moves to next control in logical order
Shift+Tab	Shift+Tab	Focus returns to previous control

Step 3 - Screen-reader test cases

Test with two AT combinations: NVDA + Firefox (Windows) and VoiceOver + Safari (macOS). Expected announcements are derived from WCAG 2.2 4.1.2 Name, Role, Value: "the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set" (WCAG 2.2, fetched 2026-06-03).

NVDA test cases

Per WebAIM NVDA article, fetched 2026-06-03: NVDA announces a control's name (label), role (type), and state. "When focusing a form control, its label is read by NVDA, and then the type of form control." Form mode is triggered automatically on interactive fields.

Widget	Action	Expected NVDA announcement
Button	Tab to button	"[Button name], button"
Toggle button (aria-pressed)	Tab to button	"[Button name], toggle button, pressed / not pressed"
Text input	Tab to input	"[Label text], edit, [type hint if any]"
Required input (aria-required)	Tab to input	"[Label text], edit, required"
Modal (on open)	Trigger dialog open	"[Dialog name], dialog" then first focusable element announced
Combobox	Tab to input	"[Label], combo box, collapsed" (or "expanded" if popup open)
Combobox option (selected)	Arrow-key to option	"[Option text], [N of M], selected" or "not selected"
Menu item	Arrow-key to item	"[Item text], menu item"
Checkbox	Tab to checkbox	"[Label], check box, checked / not checked"
Error message linked via aria-describedby	Focus input with error	"[Label], edit, [error text]"

VoiceOver test cases

Per WebAIM VoiceOver article, fetched 2026-06-03: VoiceOver key combination is Control+Option (VO). Use Tab to move to next link or form control; VO+Space to activate. "VoiceOver will not auto-associate the label to the form control based on proximity" - explicit <label for> or aria-label required.

Widget	Action	Expected VoiceOver announcement
Button	Tab to button	"[Button name], button"
Text input	Tab to input	"[Label text], text field"
Required input	Tab to input	"[Label text], required, text field"
Modal (on open)	Trigger dialog open	"[Dialog name], web dialog" then first element announced
Combobox	Tab to input	"[Label], combo box, [current value or placeholder]"
Checkbox	Tab to checkbox	"[Label], checkbox, checked / unchecked"
Page structure (headers, links, form controls)	VO+U to open Rotor, then Left / Right Arrow to choose category, Up / Down Arrow to navigate items	Selected item name and type announced; rotor categories include Headers, Links, Form controls, Auto Web Spots (per WebAIM VoiceOver article, fetched 2026-06-03)

Focus order verification (both AT)

Navigate the entire component from first to last focusable element using Tab only. Confirm:

1. Focus order matches the visual / logical reading order (SC 2.4.3 Focus Order).
2. A visible focus indicator is present on every stop (SC 2.4.7 Focus Visible).
3. No element is reachable by Tab that cannot be operated by keyboard (SC 2.1.1 Keyboard).
4. Focus is never trapped unexpectedly outside a modal context (SC 2.1.2 No Keyboard Trap - confirmed by WebAIM: "focus can be moved away from any element using only a keyboard interface").

Step 4 - Map each case to a WCAG 2.2 SC

Test case	WCAG 2.2 SC	Level
Tab/Shift+Tab reaches all interactive elements	2.1.1 Keyboard	A
No keyboard trap outside modal	2.1.2 No Keyboard Trap	A
Tab order matches visual/logical reading order	2.4.3 Focus Order	A
Focus indicator visible on every focusable element	2.4.7 Focus Visible	AA
Modal focus trap (Tab stays inside) - APG Dialog specifies Tab/Shift+Tab must not move focus outside dialog	2.1.2 No Keyboard Trap	A
Modal returns focus to trigger on close	2.4.3 Focus Order	A
Button announced: name + role	4.1.2 Name, Role, Value	A
Input announced: name + role	4.1.2 Name, Role, Value	A
Toggle/checkbox announces state changes	4.1.2 Name, Role, Value	A
Combobox popup state announced (expanded/collapsed)	4.1.2 Name, Role, Value	A
Error message linked and announced	4.1.2 Name, Role, Value + 3.3.1 Error Identification	A
Required field state announced	4.1.2 Name, Role, Value	A

Output format

The agent emits a numbered test script in this format:

## Manual accessibility test script - <ComponentName>

**AT combinations:** NVDA 2024.x + Firefox | VoiceOver (macOS 14+) + Safari
**Component:** <name>
**Widgets present:** <list>
**Date:** <ISO date>

| # | Phase | Action | Expected result | WCAG SC | Pass / Fail |
|---|-------|--------|-----------------|---------|-------------|
| 1 | Keyboard | Tab to [first widget] | Focus indicator visible on [widget]; [description] | 2.4.7 | |
| 2 | Keyboard | Press Enter/Space on [button] | [Action happens] | 2.1.1 | |
| 3 | Keyboard | Tab inside modal | Focus stays inside modal; cycles to first element from last | 2.1.2 | |
| 4 | Keyboard | Press Escape | Modal closes; focus returns to [trigger button] | 2.4.3 | |
| 5 | NVDA | Tab to [button] | NVDA announces "[name], button" | 4.1.2 | |
| 6 | NVDA | Tab to [input] | NVDA announces "[label], edit[, required]" | 4.1.2 | |
| 7 | VoiceOver | Tab to [input] | VoiceOver announces "[label], text field[, required]" | 4.1.2 | |
...

**Notes column:** tester adds AT version, OS, browser, and any deviation from
expected result.

Leave the Pass / Fail column blank - it is filled in by the human tester.

Anti-patterns

Anti-pattern	Why it fails
Replacing this script with an automated axe scan	axe catches ~30-40% of WCAG issues; it cannot observe focus order in practice, test AT announcements, or verify focus-trap behavior at runtime. This script covers what axe misses.
Checking only "can Tab reach it?"	Reachability is necessary but not sufficient. SC 2.4.3 requires logical focus order; SC 4.1.2 requires correct role and state - both require human observation.
Writing expected announcements from memory	Announcement wording varies by AT version and browser. Seed expected strings from WebAIM NVDA / VoiceOver articles (cited above), then note actual vs expected during the test run.
Conflating this agent with accessibility-code-critic	accessibility-code-critic (qa-accessibility-specifics) reads source code for violations. This agent produces scripts for a human to run against the live rendered component. Use both: code review first, manual script after.
Testing only NVDA or only VoiceOver	NVDA + Firefox and VoiceOver + Safari exercise different AT/browser stacks. An element correctly announced in one may be silent in the other due to AT implementation differences.

Limitations

• AT version variance. NVDA and VoiceOver announcement wording changes between releases. Expected announcement strings in this script are derived from WebAIM guidance current at fetch date (2026-06-03); re-verify against the target AT version.
• Browser pairing matters. NVDA + Chrome may announce differently than NVDA + Firefox for the same element. This script defaults to Firefox for NVDA and Safari for VoiceOver per WebAIM recommendations; note the pairing in the test report.
• Dynamic content. Components that update state asynchronously (live regions, lazy-loaded options) may require tester judgment on timing - the script sets expected state but cannot prescribe exact timing.
• No visual design coverage. Contrast ratios, color-only cues, and target size are outside this script's scope. Use wcag-color-contrast for color and accessibility-code-critic for static source checks.
• Focus order ambiguity in complex layouts. CSS grid / flexbox order differences from DOM order can make "logical focus order" judgement calls; the human tester must assess against the visual layout.

Hand-off targets

• Code-level fixes after a failing test case - hand to accessibility-code-critic (qa-accessibility-specifics): it reads source code, identifies the violating line, and proposes a concrete fix.
• Focus trap implementation - see wcag-focus-trap for the 6-step focus-trap pattern.
• ARIA role and keyboard pattern reference - see aria-authoring-patterns.
• Keyboard navigation rules - see wcag-keyboard-navigation.
• Automated pre-check before manual run - see axe-a11y for a runtime axe scan to clear low-hanging fruit before a human tester sits down.
• Screen-reader test script authoring (standalone skill) - see screen-reader-test-author.

References

• WCAG 2.2 (W3C, fetched 2026-06-03) - SC 2.1.1 Keyboard (Level A), 2.1.2 No Keyboard Trap (Level A), 2.4.3 Focus Order (Level A), 2.4.7 Focus Visible (Level AA), 4.1.2 Name, Role, Value (Level A), 3.3.1 Error Identification (Level A).
• WAI-ARIA APG Patterns (W3C, fetched 2026-06-03) - Dialog (Modal): focus trap, Tab/Shift+Tab cycle, Escape closes, focus returns to trigger. Menu Button: Enter/Space opens to first item, Up Arrow opens to last item, Escape closes. Combobox: Down/Up Arrow open popup, Enter accepts, Escape dismisses.
• [apg-button]: https://www.w3.org/WAI/ARIA/apg/patterns/button/ "WAI-ARIA APG Button pattern - fetched 2026-06-03" - Enter activates the button; Space activates the button.
• WebAIM Keyboard Testing (fetched 2026-06-03) - Tab / Shift+Tab navigation; focus indicators must be present; logical Tab order; "focus can be moved away from any element using only a keyboard interface."
• WebAIM NVDA (fetched 2026-06-03) - NVDA announces name + role + state; form label then type; focus mode on form controls.
• WebAIM VoiceOver (fetched 2026-06-03) - VO = Control+Option; Tab to form controls; explicit label association required; rotor for structure navigation.