agentsclimarketplace
Sign in

Keyboard navigation

Skill Amey-Thakur/AI-SKILLS/skills/accessibility/keyboard-navigation

Make interfaces fully keyboard-operable with logical focus order, no traps, skip links, and roving tabindex where needed. Use when building interactive UI or auditing keyboard accessibility.From its SKILL.md

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill keyboard-navigation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.7 KB, as published. Nobody here has run it

Keyboard navigation

Everything a mouse can do, a keyboard must do: this is the baseline for users who cannot use a pointer (motor disabilities, screen-reader users, power users). Keyboard access is also the foundation screen readers build on, so getting it right serves multiple needs at once.

Method

  1. Make every interactive element focusable and operable. Native interactive elements (<button>, <a>, form controls) are keyboard-operable for free; custom ones (see aria-usage) need tabindex="0" plus key handlers (Enter/Space activate buttons, arrow keys navigate composite widgets). If a mouse user can click it, a keyboard user must be able to reach and activate it: a click handler on a <div> with no keyboard equivalent is the classic exclusion.
  2. Keep focus order logical. Tab order follows the visual/reading order (top to bottom, left to right in most locales): driven by DOM order, not by positive tabindex values (which create maintenance nightmares and confusing jumps). If the visual order and DOM order diverge (CSS reordering), fix the DOM order or the layout; a tab order that jumps around the screen disorients.
  3. Never trap focus unintentionally. Focus must be able to leave every component via keyboard; a widget that captures Tab and never releases it strands keyboard users (a real, common bug in custom modals and embeds). The one intentional trap is a modal dialog, which should trap focus within it while open and return focus on close (see focus-management): deliberate and reversible, never accidental and permanent.
  4. Provide skip links. A "skip to main content" link as the first focusable element lets keyboard and screen-reader users bypass repeated navigation (tabbing through fifty nav links on every page is exhausting): visible on focus, jumping focus to the main content. This small addition dramatically improves the experience for keyboard users on content-heavy sites.
  5. Use roving tabindex for composite widgets. In widgets like menus, toolbars, and grids, the whole widget is one tab stop, and arrow keys move within it (roving tabindex: one child has tabindex="0", others tabindex="-1", updated as focus moves): so users tab past the widget quickly and explore inside with arrows, matching the ARIA patterns (see aria-usage). Making every menu item a tab stop makes navigation tedious.
  6. Make focus visible, always. A clear visible focus indicator (never outline: none without a replacement: see focus-management) so keyboard users can see where they are: an interface that is keyboard-operable but shows no focus is unusable, because the user is navigating blind. Style the focus indicator to be obvious, honoring :focus-visible.

Boundaries

  • Keyboard navigation is necessary but not sufficient for accessibility; it pairs with screen-reader semantics (see screen-reader-testing, aria-usage) and visible focus (see focus-management). All three together make an interface accessible.
  • Test by actually navigating with only the keyboard (unplug the mouse): automated tools miss focus-order and trap issues that only manual keyboard testing reveals.
  • Custom keyboard shortcuts (single-key access) can conflict with assistive tech and browser shortcuts; follow established patterns and make custom shortcuts configurable or scoped (see the shortcut cautions in mobile-input-ux's desktop cousin).

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 3 of the 12 instructions most accessibility skills give

Counted across 360 of the 378 authors here whose files we hold, read 2026-09-06

  • Respect prefers-reduced-motionin 49 of 360, across 41 files
  • Add alt text to every imagein 47 of 360, across 40 files
  • Make every interactive element keyboard operablehere, and in 46 of 360, across 37 files
  • Keep focus indicators visiblehere, and in 42 of 360, across 37 files
  • Associate every form input with a labelin 42 of 360, across 35 files
  • Ensure 4.5:1 contrast for normal textin 38 of 360, across 32 files
  • Trap focus in modals and restore it on closehere, and in 37 of 360, across 25 files
  • Prefer native HTML elements over ARIAin 37 of 360, across 33 files
  • Add aria-label to icon-only buttonsin 24 of 360, across 13 files
  • Announce dynamic content updates with aria-livein 24 of 360, across 16 files
  • Use ARIA only when native HTML is insufficientin 23 of 360, across 15 files
  • Meet WCAG AA contrast ratiosin 23 of 360

Said here and by no other author read

  • Add tabindex and key handlers to custom widgets
  • Follow DOM order for tab order
  • Fix DOM order when CSS reorders layout
  • Use roving tabindex for composite widgets
  • Honor :focus-visible when styling focus
  • Make custom shortcuts configurable or scoped

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 626,045. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.