Skip to main content

Keyboard, Pointer and Touch

Principle​

All interactive functionality must be fully usable with a keyboard. Keyboard users must be able to reach, operate and exit every interactive element in a predictable and consistent way.

Focusable Elements​

Guidance​

  • All interactive elements must be reachable using Tab (forward) and Shift+Tab (backward).
  • Prefer native interactive elements (<button>, <a>, <input>, <select>, <textarea>) — these are automatically focusable and provide correct keyboard behavior.
  • Avoid making non-interactive elements focusable (e.g., adding tabindex="0" to a <div>) unless implementing a fully accessible custom widget following the ARIA Authoring Practices Guide (APG).
  • Do not use tabindex="-1" to hide elements from keyboard navigation unless focus is intentionally moved there programmatically (for example, when moving focus into a dialog or to an error message).
  • Never use positive tabindex values (tabindex="1", 2, …). They break natural focus order and violate predictable navigation.

WCAG Reference​

Keyboard Interaction Patterns​

Principle​

Custom widgets must behave consistently with native controls and follow the interaction patterns defined in the ARIA Authoring Practices Guide (APG).

Buttons​

  • Enter and Space activate the button.
  • Button must receive focus via Tab.
  • Enter activates navigation.
  • Do not trigger navigation on Space (Space scrolls the page).

Checkboxes​

  • Tab moves focus to the checkbox.
  • Space toggles the checked state.
  • Checkboxes inside a group remain individually tabbable.

Radio Groups​

  • Tab moves focus into and out of the group.
  • Arrow keys move selection between radio buttons.
  • Space selects the focused option.
  • Use the roving tabindex pattern so only the selected radio button is tabbable.

Tabs (Tablists)​

  • Use roving tabindex: only the selected tab button has tabindex="0"; all other tabs have tabindex="-1".
  • Left / Right Arrow moves focus between tab buttons.
  • Moving focus between tabs may either:
    • automatically display the associated tab panel, or
    • require Enter or Space to display the panel.
  • If panels are displayed automatically on focus, the change should happen without noticeable delay.
  • Only the currently displayed tab panel should be visible and reachable by keyboard navigation.

Dropdowns / Menus / Select-like widgets​

  • Enter or Space opens the menu.
  • Up / Down Arrow moves between options.
  • Enter selects an option.
  • Escape closes the menu.
  • When closed, focus returns to the triggering element.
  • Menu options must not be reachable by Tab. Tab should exit the entire widget.

Accordions​

  • Accordion headers must be reachable using the standard Tab order.
  • Enter or Space toggles the expanded/collapsed state.
  • Down / Up Arrow may move focus between accordion headers.
  • Home / End may move focus to the first or last accordion header.

Listboxes​

  • Tab moves focus into and out of the widget.
  • Up / Down Arrow moves focus between options.
  • In single-select listboxes, moving focus may also select the focused option.
  • In multi-select listboxes, Space should toggle the selection state of the focused option.
  • Home / End moves focus to the first or last option.
  • Keyboard navigation inside the widget should not require tabbing through every option.
  • Listboxes may use either the roving tabindex pattern or aria-activedescendant to manage keyboard focus.

Range Sliders (value selectors)​

  • The slider control must be reachable using Tab.
  • Left / Down Arrow decreases the value.
  • Right / Up Arrow increases the value.
  • Home sets the minimum value; End sets the maximum value.
  • Page Up / Page Down may change the value in larger steps.
  • Custom sliders must expose their current value and limits using ARIA (aria-valuemin, aria-valuemax, aria-valuenow).

Dialogs / Modals​

  • When opened, focus must move into the dialog, typically to the first focusable element.
  • Tab and Shift+Tab must keep focus inside the dialog while it is open (focus trap).
  • Escape should close the dialog unless the interaction intentionally requires another action.
  • When closed, focus should return to the triggering element.

WCAG Reference​

Focus Visibility​

Guidance​

  • Every interactive element must display a clear and visible focus indicator when focused.
  • Do not remove or suppress the native focus outline unless it is replaced with a custom focus indicator that is equally or more visible.
  • Focus indicators must have a minimum contrast ratio of 3:1 against adjacent colors and remain visible across all themes (light/dark) and component states.
  • Focus indicators must not be obscured, clipped, or hidden by overflow: hidden, border radius, shadows, transforms, or overlapping elements.
  • Ensure that all custom interactive components (dialogs, popovers, tabs, dropdowns, sliders, etc.) provide a visible focus state for their active and focusable elements.
  • The currently focused element must always be visually distinguishable from surrounding content and nearby interactive elements.

WCAG Reference​

Logical Focus Order​

Guidance​

  • Keyboard focus must follow the same logical order as the visual layout and reading order.
  • The DOM order should match the intended reading and interaction sequence.
  • Do not use CSS reordering (order in flex/grid), absolute positioning, or DOM manipulation in ways that create a mismatch between the visual order and keyboard navigation order.
  • Avoid unexpected focus jumps. Moving through content with Tab and Shift+Tab must feel predictable and consistent.
  • Related controls and actions should appear close together in both the visual layout and focus order.
  • Consider keyboard navigation when placing important actions. Users should not need to tab through large amounts of content unnecessarily (e.g. a “Save” button placed at the top of a long form).

WCAG Reference​

Programmatic Focus Management​

Guidance​

  • Move focus programmatically only when it helps users understand context or continue an interaction.
    • Examples:
      • opening a dialog
      • revealing an error message
      • loading new interactive content
  • Avoid unexpected or automatic focus changes that are not triggered by a user action.
  • Never move focus when background content updates automatically — unexpected focus shifts disrupt navigation and orientation.
  • Ensure any programmatically focused element is currently visible, active, and not disabled.
  • Do not move focus to non-interactive elements unless they intentionally receive programmatic focus using tabindex="-1".

Dialog Focus Management​

  • When opening a dialog, move focus inside the dialog.
  • The initial focus target should depend on the dialog purpose and user context:
    • For simple informational dialogs, focusing the close button can be acceptable because users are likely to dismiss the dialog immediately.
    • For simple or familiar forms (e.g. login), focusing the first input can support faster completion.
    • For complex, long, or unexpected dialogs, focusing the dialog heading or introductory content can help users orient themselves before interacting. Because headings are not focusable by default, apply tabindex="-1" to the heading itself or to a non-interactive container wrapping the introductory content.
    • When the dialog contains potentially destructive actions, focus the least destructive option first (e.g. “Cancel” instead of “Delete”).
  • When closing a dialog or popover, return focus to the element that triggered it.

Dynamic Content Updates​

  • When updating content dynamically, move focus only when it helps users maintain orientation.
    • Examples:
      • after pagination, focus may move to the new content or page heading
      • after “Load more”, focus may move to the first newly added item

WCAG Reference​

Preventing Focus Traps​

Guidance​

  • Standard interactive components must never trap keyboard focus. Users must always be able to leave components using Tab or Shift+Tab.
  • Only components that intentionally block background interaction — such as dialogs or modals — may temporarily trap focus while open.
  • For all other widgets (e.g., dropdowns, accordions, carousels, side panels), focus must continue moving naturally through the page.
  • Scrollable containers must allow keyboard users to move focus out after reaching the beginning or end of the content.

WCAG Reference​

Handling Hidden / Collapsed Content​

Guidance​

  • Elements hidden using display: none, visibility: hidden, or inert must not be focusable or exposed to assistive technologies.
  • Collapsed or inactive content (e.g. hidden accordion panels, inactive tab panels, closed drawers) must remove focusable elements from the tab order until the content becomes active or visible.
  • Do not rely on CSS-only hiding techniques (e.g. opacity: 0, off-screen positioning, transforms) without also updating accessibility and focus states — elements may remain focusable even when visually hidden.
  • When revealing content dynamically, ensure newly visible interactive elements become reachable through normal keyboard navigation.
  • Keep visibility, focusability, and ARIA states synchronized:
    • use aria-expanded on toggle controls
    • use aria-hidden or inert (when supported) for inactive regions
  • Avoid situations where keyboard users can navigate into content that is hidden, visually obscured, or inactive.
  • When dynamically updating or replacing content, ensure focusable elements do not unexpectedly appear, disappear, or reorder in ways that break predictable navigation.

WCAG Reference​

Content on Hover or Focus​

Principle​

Content revealed on hover or focus must be accessible, perceivable, and operable for all users, regardless of input method.

Guidance​

  • Do not rely on hover-only interactions. All revealed content and functionality must also be accessible via keyboard and touch.
  • Avoid hiding important information or interactive controls behind hover or focus states whenever possible.
  • Ensure content is triggered by both hover and focus (e.g. :hover and :focus-visible).
  • Content revealed on hover or focus must remain visible until:
    • the user dismisses it,
    • the trigger loses hover/focus, or
    • the content becomes invalid.
  • Users must be able to move the pointer over revealed content without it disappearing.
  • Provide a mechanism to dismiss additional content without requiring users to move pointer or keyboard focus, unless the content does not obscure other content or represents an input error.
  • Do not place important interactive elements inside content that disappears immediately on blur, mouseout, or similar events.
  • Tooltips or other hover/focus-revealed content should not contain essential information or critical functionality unless all accessibility requirements above are met.

WCAG Reference​

Principle​

Provide mechanisms to bypass repetitive content and move quickly to important page regions.

Guidance​

  • Provide a “Skip to main content” link near the beginning of the page and ensure it is easily reachable using keyboard navigation.
  • Skip links may be visually hidden by default, but they must become visible when focused via keyboard.
  • Additional skip links may be provided where helpful (e.g. “Skip to navigation”, “Skip filters”).
  • Skip links must move focus directly to the target region.
  • Ensure the target region can receive focus when necessary (e.g. using tabindex="-1" on <main>) so keyboard and screen reader users are correctly moved to the destination.

WCAG Reference​

Keyboard Shortcuts​

Principle​

Keyboard shortcuts must not interfere with assistive technologies, browser functionality, or standard keyboard usage.

Guidance​

  • Ensure keyboard shortcuts remain predictable and do not override common platform or assistive technology interactions.
  • Avoid single-character keyboard shortcuts (e.g. F, S, K) because they may conflict with browser or screen reader commands.
  • Single-character shortcuts should only be used when at least one of the following conditions is met:
    • the shortcut is active only while a specific component has focus,
    • users can disable it, or
    • users can remap it.
  • Prefer shortcuts that use modifier keys (e.g. Ctrl, Alt, Cmd).

WCAG Reference​

Pointer and Touch Input​

Principle​

Touch and pointer interactions must be operable without fine motor precision or complex gestures. Actions must be cancellable and targets large enough to avoid accidental activation.

Pointer Gestures​

  • If a feature uses multi-point or path-based gestures (e.g. pinch, drag-to-draw), provide a single-pointer alternative such as buttons, a tap action, or a slider.

Pointer Cancellation​

  • Prefer activating actions on pointer up (release), not pointer down.
  • Allow users to cancel by moving the pointer off the target before releasing.
  • Avoid irreversible actions triggered on pointer down unless absolutely essential.

Target Size​

  • Make interactive targets at least 24 × 24 CSS px.
  • If a target is smaller, apply the spacing exception: a 24 px-diameter circle around the target must not intersect any adjacent target's circle.
  • Visual size and interactive (hit) area are not the same — ensure the interactive area (via padding or invisible box) meets the minimum even when the visible element is smaller.

Dragging Movements​

  • For any drag interaction (e.g. reordering list items, map panning), provide a non-drag alternative such as "Move up / Move down" buttons or directional controls.

WCAG Reference​