Keyboard Accessibility

All content must be operable using the keyboard

Keyboard accessibility means that all interactive content can be reached and operated using only the keyboard (for example, with the Tab, Enter, and arrow keys). Many people use a keyboard instead of a mouse, including users of screen readers, switch devices, and alternative input tools. Under the CSU Accessible Technology Initiative (ATI), the ADA, Section 504, and the ADA Title II web and mobile accessibility rule, web content at AVÀÇ must conform to WCAG 2.1 Level AA, which includes keyboard accessibility requirements.

Quick checklist

  • Every interactive element (links, buttons, form controls, menus, dialogs) can be reached using the Tab key and activated using the keyboard.
  • There is a visible focus indicator that shows where the keyboard focus is on the page.
  • The tab order is logical and follows the visual reading order of the page.
  • There are no keyboard traps (users can always move focus forward and backward or exit components such as dialogs).
  • All functionality that can be done with a mouse or touch can also be done with the keyboard.

Keyboard focus and interactive elements

Most native HTML elements are keyboard accessible by default:

  • <a href="..."> links
  • <button> elements
  • Form controls such as <input>, <select>, and <textarea>

These elements will receive keyboard focus in the normal tab order as long as they are not disabled or removed from the tab sequence.

Custom controls and tabindex

  • Whenever possible, use native HTML elements (for example, a <button> instead of a clickable <div>).
  • If you create a custom control, make sure it can receive focus using tabindex="0" and that it responds to keyboard events such as Enter and Space.
  • Avoid using positive tabindex values (for example, tabindex="1", tabindex="2") because they create confusing tab orders. Keep the natural document order whenever possible.
  • Do not remove focus from interactive elements using tabindex="-1" unless you are intentionally managing focus (for example, in modals) and providing an alternate path.

Onclick, hover, and focus effects

Interactive behaviors are often implemented using JavaScript and HTML attributes.

  • Click activation: If you use an onclick handler on an element, make sure the element is a keyboard-focusable control (such as a <button>) so users can activate it with the keyboard as well as the mouse.
  • Hover vs. focus: Effects that occur on onmouseover (for example, showing a menu on hover) should have an equivalent behavior for keyboard users using onfocus or standard focus/blur events. Do not rely only on hover.
  • Pointer-specific interactions: If you implement drag-and-drop or other pointer-specific interactions, provide an equivalent way to perform the same task using the keyboard (for example, move items up or down using buttons or keyboard commands).

Equivalency for complex interactions

Some interactions, such as drag-and-drop interfaces, may not be practical to make directly keyboard accessible. In these situations:

  • Provide an alternative method that offers the same result (for example, “Move up” / “Move down” buttons that reorder items).
  • Ensure that keyboard users can access all information and complete all tasks, even if the method is slightly different from the mouse or touch interaction.

Avoiding keyboard traps

A keyboard trap occurs when users can move focus into a component (such as an embedded widget, iframe, or dialog) but cannot move focus back out again. Keyboard traps violate WCAG and can prevent users from navigating or leaving a page.

  • Ensure that users can always move forward and backward through focusable elements using Tab and Shift+Tab.
  • For modals and dialogs, manage focus carefully:
    • Move focus into the dialog when it opens.
    • Keep focus within the dialog while it is open.
    • Return focus to a logical control (for example, the button that opened the dialog) when it closes.
  • Test any embedded content (for example, videos or external widgets) to confirm that focus can enter and exit without getting stuck.

Keyboard testing tips

You can quickly check keyboard accessibility by testing with only the keyboard.

  • Unplug or do not use your mouse or trackpad.
  • Use Tab to move forward through interactive elements and Shift+Tab to move backward.
  • Use Enter and Space to activate links, buttons, and controls.
  • Use arrow keys to move within menus, radio button groups, and other widgets that support arrow key navigation.
  • Confirm that:
    • The skip link works and moves focus to the main content.
    • All buttons, links, and form controls receive focus in a logical order.
    • Menus, accordions, tabs, and dialogs can be opened and closed with the keyboard.
    • A visible focus indicator is always present and easy to see.

Related WCAG 2.1 criteria

  • 2.1.1 Keyboard (Level A) – All functionality of the content is operable through a keyboard interface.
  • 2.1.2 No Keyboard Trap (Level A) – If keyboard focus can be moved to a component, focus can be moved away using the keyboard.
  • 2.4.3 Focus Order (Level A) – Focusable components receive focus in an order that preserves meaning and operability.
  • 2.4.7 Focus Visible (Level AA) – Any keyboard-operable user interface has a mode of operation where the keyboard focus indicator is visible.

Before you publish

  • Review the page with the keyboard only to make sure all functionality is available and no traps exist.
  • Confirm that focus order follows the logical reading order of the page.
  • Ensure custom controls are focusable and respond to keyboard events (Enter and Space).
  • Verify that there is a visible focus indicator for all interactive elements.

Last updated: December 2025