Implementation worksheet · 2 min read
A keyboard-accessible product tour acceptance test
Test a product tour without a mouse from entry to dismissal. Verify that the trigger is reachable, the current step is understandable, controls work from the keyboard and focus returns to a sensible place when the tour ends. Choose modal or non-modal behavior deliberately; not every tour should trap focus.
A tour can look clear while being unusable for someone navigating by keyboard or assistive technology. This worksheet focuses on interaction behavior. It complements a broader accessibility review and should be run against the actual product route, including responsive layouts and missing targets.
Put it into practice
1. Define the interaction model
Decide whether the tour blocks interaction with the page. If it behaves as a modal dialog, follow the dialog pattern. If it is a non-modal hint, preserve a usable path between the hint and the underlying page.
2. Start from the keyboard
Reach and activate the tour trigger using keyboard navigation. Check the visible focus indicator and the accessible name. The first step should be announced or discoverable without relying on a spotlight animation.
3. Move between steps
Use next, previous and close controls. Verify labels, focus order and the step context after each change. A route change or hidden target should produce a recoverable state rather than leaving focus on a removed element.
4. Dismiss and return
Close the tour and verify where focus goes. Reopen it and check the resume policy. Ensure dismissal does not require clicking a tiny icon or interacting with an element outside the keyboard sequence.
5. Test layout and motion
Repeat at a narrow viewport and with reduced motion enabled. Confirm text and controls stay visible without covering essential content. Test zoom and long translated labels where the product supports them.
Keyboard acceptance matrix
Copy this structure into your review document and record your observed result for each row.
| State | Expected behavior | Evidence |
|---|---|---|
| Trigger | Reachable and named | Keyboard path |
| Step | Context and controls understandable | Screen reader check |
| Navigation | Predictable focus movement | Step sequence |
| Missing target | Recoverable fallback | Route-change test |
| Close | Focus restored sensibly | Dismissal test |
A failure worth checking
Applying modal semantics to a non-modal tooltip can trap the user away from the task the tooltip describes. Match focus behavior and accessible semantics to the actual interaction instead of adding dialog attributes mechanically.
Common questions
Must every product tour trap focus?
No. Focus containment is appropriate for a true modal dialog. Non-modal guidance needs a different interaction model.
Is a keyboard test a complete accessibility audit?
No. It is one important check. Screen reader behavior, contrast, content, zoom and other requirements also need review.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.