keyboard-navigation
starsforks
How to install keyboard-navigation?
owl-listener/inclusive-design-skills/keyboard-navigation
$npx -y skills add Owl-Listener/inclusive-design-skills --skill keyboard-navigationDesign keyboard navigation and focus management for users who cannot or prefer not to use a mouse or touch screen. Use when designing any interactive interface — forms, menus, modals, tabs, carousels, drag-and-drop, data tables, or custom components. Triggers on: keyboard, focus,
SKILL.md
| 1 | # Keyboard Navigation |
| 2 | |
| 3 | Design interactions so that every task can be completed using only a |
| 4 | keyboard. This is non-negotiable — it's the foundation of all |
| 5 | interaction accessibility. |
| 6 | |
| 7 | ## Who This Is For |
| 8 | |
| 9 | - People with motor disabilities who cannot use a mouse |
| 10 | - People using switch devices or mouth sticks |
| 11 | - Screen reader users (keyboard is their primary input) |
| 12 | - Power users who prefer keyboard for speed |
| 13 | - Anyone with a temporarily injured hand or arm |
| 14 | |
| 15 | ## Core Principles |
| 16 | |
| 17 | ### Everything Must Be Reachable |
| 18 | - Every interactive element must be focusable via Tab key |
| 19 | - Focus order must follow the visual reading order (left to right, |
| 20 | top to bottom in LTR languages) |
| 21 | - No element should be reachable only by mouse hover or click |
| 22 | - Custom components need explicit tabindex and keyboard handlers |
| 23 | |
| 24 | ### Focus Must Be Visible |
| 25 | - Focus indicator must be visible on every interactive element |
| 26 | - Minimum: 2px solid outline with 3:1 contrast against background |
| 27 | - Never use outline: none or outline: 0 without a visible replacement |
| 28 | - Focus style should be consistent across the entire interface |
| 29 | - Test: can you always see which element is focused? |
| 30 | |
| 31 | ### Focus Must Be Managed |
| 32 | - When a modal opens, move focus into the modal |
| 33 | - When a modal closes, return focus to the element that opened it |
| 34 | - When content is deleted, move focus to a logical next element |
| 35 | - When a page section updates dynamically, manage focus appropriately |
| 36 | - Never trap focus unintentionally (only trap inside open modals) |
| 37 | |
| 38 | ## Keyboard Patterns by Component |
| 39 | |
| 40 | ### Navigation Menus |
| 41 | - Tab moves between top-level items |
| 42 | - Arrow keys move within a dropdown |
| 43 | - Enter/Space activates a menu item |
| 44 | - Escape closes an open dropdown and returns focus to trigger |
| 45 | |
| 46 | ### Tabs |
| 47 | - Tab moves to the active tab panel, not through all tabs |
| 48 | - Arrow keys move between tabs |
| 49 | - Enter/Space activates a tab (if not automatic) |
| 50 | |
| 51 | ### Modals / Dialogs |
| 52 | - Focus moves to first focusable element inside modal on open |
| 53 | - Tab cycles only within the modal (focus trap) |
| 54 | - Escape closes the modal |
| 55 | - Focus returns to trigger element on close |
| 56 | |
| 57 | ### Forms |
| 58 | - Tab moves between fields in logical order |
| 59 | - Error messages are focusable or announced |
| 60 | - Submit via Enter key on the last field or a visible button |
| 61 | - Required field indicators are not conveyed by colour alone |
| 62 | |
| 63 | ### Drag and Drop |
| 64 | - Always provide a keyboard alternative (move up/down buttons, |
| 65 | select-and-place, or arrow key reordering) |
| 66 | - Announce the current position and available actions |
| 67 | |
| 68 | ### Carousels / Sliders |
| 69 | - Arrow keys move between items |
| 70 | - Provide visible previous/next buttons |
| 71 | - Pause autoplay on focus or hover |
| 72 | - Announce current position ("Item 2 of 5") |
| 73 | |
| 74 | ## Skip Links |
| 75 | |
| 76 | Every page should have a "Skip to main content" link as the first |
| 77 | focusable element. This lets keyboard users bypass repeated navigation. |
| 78 | |
| 79 | - Visible on focus (can be visually hidden until focused) |
| 80 | - Links to the main content area via an anchor |
| 81 | - Consider additional skip links for long pages ("Skip to search", |
| 82 | "Skip to footer") |
| 83 | |
| 84 | ## Assessment Checklist |
| 85 | |
| 86 | - [ ] Every interactive element is reachable via Tab |
| 87 | - [ ] Focus order matches visual order |
| 88 | - [ ] Focus indicator is visible on every element (2px, 3:1 contrast) |
| 89 | - [ ] Modals trap focus and return it on close |
| 90 | - [ ] All custom components have keyboard handlers |
| 91 | - [ ] Drag-and-drop has a keyboard alternative |
| 92 | - [ ] Skip link is present and functional |
| 93 | - [ ] No keyboard traps exist anywhere in the interface |
| 94 | - [ ] Dynamic content changes manage focus appropriately |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
