Keyboard-accessible UI lets people reach and operate functionality through a keyboard interface, with logical focus order and a visible focus indicator. Prefer native elements and established interaction patterns, specify focus behavior for overlays and dynamic content, and prevent traps. WCAG criteria define outcomes; passing one keyboard walkthrough does not establish complete conformance.
Who this is for: Designers and frontend teams specifying interactive software for people who navigate and operate it without a pointer.
- Use native controls and familiar keyboard patterns before inventing custom interaction behavior.
- Design a logical focus sequence, visible indicator, overlay entry and return, and escape from every region.
- Test every action, state, error, scroll position, and responsive layout with keyboard-only operation.
Map functionality and semantics
List every pointer action, including menus, drag operations, hover content, sorting, resizing, dismissing, and revealing details. Define a keyboard-operable equivalent that preserves the same outcome. WCAG 2.2 criterion 2.1.1 addresses keyboard operation, with an exception for functions whose underlying input depends on movement path.
Prefer links for navigation, buttons for actions, and native form controls for selection and entry. Native semantics provide expected focus and keyboard behavior that custom elements must recreate carefully. A clickable div with a tab stop is not equivalent if role, state, activation keys, or disabled behavior remains missing.
Design focus order and movement
Focus order should follow a meaningful sequence that preserves operation and understanding. Visual rearrangement across responsive layouts can diverge from source order, so inspect both. Avoid positive tab-index values that create a second hidden ordering system and become difficult to maintain as content changes.
Composite widgets such as tabs, menus, and grids may use arrow-key patterns with a managed tab stop. Follow established platform and accessibility conventions for the chosen widget rather than making every child a separate tab stop. Document keys, selection behavior, wrapping, and disabled items for implementation and testing.
Make focus visible and stable
WCAG 2.2 criterion 2.4.7 requires a visible focus indicator for a keyboard-operable interface. Criterion 2.4.11 requires the focused component not be entirely hidden by author-created content at Level AA. Test sticky headers, cookie banners, drawers, virtual keyboards, and scrolling containers that can obscure focus.
Do not remove the browser outline without a replacement that remains perceivable across surfaces and states. When a dialog opens, place focus at a sensible location, contain it while modal behavior applies, and return it to the invoking control or another logical point after close. Avoid moving focus merely to announce routine updates.
Test complete operation
Start at the browser controls and use Tab, Shift+Tab, Enter, Space, arrows, Escape, and widget-specific keys as appropriate. Verify activation, state changes, errors, recovery, overlays, asynchronous updates, and return after deletion. Ensure there is no keyboard trap and that shortcuts do not conflict with text entry.
Repeat testing at supported responsive sizes, zoom, and content lengths. Automated tools can identify some semantic and focus issues but cannot judge whether order makes sense or every operation is practical. Include manual review and feedback from relevant users, then track regressions at component and workflow level.
Specify a hypothetical filter drawer
Hypothetical mobile dashboard opens filters in a modal drawer and updates results after application.
- Use a button with an accessible name and state, then define focus placement on the drawer heading or first useful control.
- Set logical tab order through hypothetical filter fields, Clear, Apply, and Close, with Escape behavior documented.
- Keep focus contained while modal, show a visible indicator, and prevent sticky content from obscuring focused controls.
- After Apply, close the drawer, return focus to the trigger, and expose the changed result status appropriately.
Keyboard interaction specification
Use this alongside visual states for every interactive pattern.
- Element, purpose, native semantic choice, accessible name, state, disabled behavior, and pointer equivalent.
- Tab entry, internal arrow keys, activation, Escape, Home or End where applicable, and tab exit.
- Source order, responsive visual order, dynamic insertion, deletion, focus destination, and return behavior.
- Focus indicator, surface contrast review, clipping, sticky overlays, scrolling, zoom, and obscuration check.
- Keyboard walkthrough, browser coverage, assistive-technology check, automated scan, user evidence, and owner.
Common mistakes
- Adding tabindex to a custom clickable element without implementing the expected role, keys, states, and semantics.
- Removing visible focus styling because it conflicts with the visual design and offering no equivalent indicator.
- Opening a modal without managing focus entry, containment, close behavior, and return to the invoking control.
Try one
A drag-and-drop board works with a mouse but not a keyboard. What must the team provide?
A strong answer specifies a keyboard-operable way to select an item, identify valid destinations, move it, cancel, and confirm the result, with programmatic state and visible focus. The exact pattern depends on the board and platform conventions. The team should test order, announcements, scrolling, errors, and recovery rather than adding tab stops to draggable cards alone.
Sources
- W3C WCAG 2.2 keyboard criterionCriterion 2.1.1 guidance for making functionality operable through a keyboard interface.
- W3C WCAG 2.2 focus visible criterionCriterion 2.4.7 guidance requiring a visible keyboard focus indicator.
- W3C WCAG 2.2 focus not obscured criterionCriterion 2.4.11 guidance for keeping the focused component at least partially visible.