Owl Listener Keyboard Review
A focused review of keyboard accessibility — the single most important interaction requirement. If keyboard doesn't work, screen readers don't work, switch devices don't work, and many motor-impaired users are completely blocked.
Process
Step 1: Tab Through Everything
Starting from the browser address bar, press Tab repeatedly through the entire page. Document:
- Unreachable elements — interactive items that Tab skips
- Wrong order — focus jumps to unexpected locations
- Invisible focus — focus moves but you can't see where it is
- Keyboard traps — focus enters a region and can't leave
Step 2: Test All Components
Using keyboard-navigation, test each component type present:
- Menus: Tab to open, Arrow keys to navigate, Escape to close
- Modals: focus trapped inside, Escape to close, focus returns on close
- Tabs: Arrow keys between tabs, Tab into panel content
- Forms: Tab between fields, Enter to submit
- Custom widgets: appropriate keyboard patterns for the role
Step 3: Test Dynamic Content
When content changes on screen:
- Does focus move to the new content when appropriate?
- Are screen reader users informed of the change?
- When content is removed, does focus move to a logical place?
- Do loading states announce themselves?
Using feedback-and-status, verify all dynamic changes are announced via aria-live regions or focus management.
Step 4: Check Skip Links and Landmarks
- Is "Skip to main content" present and functional?
- Are ARIA landmarks present (banner, navigation, main, contentinfo)?
- Can a keyboard user bypass repeated navigation efficiently?
Output
Deliver a keyboard accessibility report:
- Pass/fail summary — can every task be completed by keyboard?
- Tab order map — the actual focus sequence with issues marked
- Component results — pass/fail for each interactive component
- Dynamic content results — focus management for content changes
- Fix list — prioritised by severity (blocker, major, minor)