How to test accessibility manually with a keyboard

Purpose Heading link

The purpose of keyboard testing is to identify accessibility errors and verify all mouse actions can be replicated with key presses. Keyboard testing involves using only a keyboard; some users are unable to use mouse input devices, so this process will help replicate this use case. Please note that this is not the same thing as screen reader testing, which requires a keyboard and screen reader software. Remember: if you can click on it with your mouse, you must be able to interact with it using only your keyboard.

What to look for Heading link

  • Tab order
    • Tab order must follow a logical and intuitive sequence: from left to right, top to bottom. When you press the TAB key, the browser focus should move to the next focusable ("clickable") element on the page.
  • Readability
    • Text must be readable when resized to 200% (by pressing ⌘ +) without loss of content or functionality.
  • Interactive Elements
    • All focusable interactive elements (links, buttons, form fields, etc.) must receive working input controls from the keyboard. The site should be completely usable without a mouse or other non-keyboard input device.
    • Visible focus indicators (such as a border or outline) around the focused elements should be present. If an element can receive focus, its focus indicator must be clearly distinguishable from the surrounding content.
    • Users require the ability to easily escape keyboard traps (e.g., dropdown menus, modals) by pressing the "Escape" key or using other clear exit mechanisms.
  • Navigation
    • A "skip to content" link should be present at the beginning of the page to allow users to go directly to the main content. When this link is activated, the main content area should receive focus; if you press the TAB key from here, the focus should then move forward to the next clickable area in the main content area.
    • Main navigation must have an intuitive structure and follow a logical sequence.
  • Modal dialogs and alerts
    • Verify that modal dialogs can be opened, closed, and navigated using the keyboard input.

Method Heading link

Using the cheat sheet reference below, use your keyboard to interact with the site. The TAB key, which advances your web browser's focus to the next logically-ordered clickable item, will be your primary means of input. If a key does not operate correctly on an interactive element, the element is inaccessible. For more details, consult the "Expected behavior" table in the next section.

Keyboard navigation controls

Key Action
Tab Navigate forward through links, buttons, form controls, any element that can receive focus. Exit a group of radio buttons. Enter/Exit a group of tabs.
Shift + Tab Navigate backward
Enter Activate buttons or focused elements
Spacebar Select the currently focused option, e.g. checkbox, radio button. Activate button. Scroll down page if if not focused on an interactive element.
Shift + Spacebar Scroll up page if not focused on an interactive element.
← ↑ → ↓ Scroll vertically/horizontally through page if permitted. Navigate menus, lists, grouped radio buttons or tabs, or other elements with directional interfaces.
Esc Close dialogs, menus, or expanded elements.

Expected behavior (keyboard) Heading link

Below is a table of how common interactive elements should behave when using only a keyboard as a means of input. These are fundamental expectations for keyboard accessibility. If more than one key is listed (e.g. "Enter or Spacebar to activate"), each key should execute the command on its own.

Element Keys When activated: Relevant WCAG & APG
Skip to content link
  • Enter to activate
 Focus should move directly to an anchor in the main content area.
Link
  • Enter to activate
 Links should open in the browser when activated.
Button
  • Enter or Spacebar to activate
 Action associated with button is triggered. Focus expectation after button activation is dependent on action type.
Navigation menu button
  • Enter or Spacebar to activate
 Reveal hidden dropdown menu if in mobile view. Focus should move to the first list item in the menu and should return to the button when the menu is closed. This also applies to dropdown submenu nav buttons.

NOTE: for regular menu buttons and menubars (not used for navigation), focus expectation is largely dependent on context.
Navigation menubar
  • Enter or Spacebar to activate
  • ← ↑ → ↓ to navigate
  • Esc to close when in mobile view
 All menu links should open in the browser when activated. If activating a submenu button, the hidden dropdown submenu should be revealed and focus should move to the first item in the list. Dropdown submenu activated by a button should close when list items are no longer in focus.

NOTE: for regular menu buttons and menubars (not used for navigation), focus expectation is largely dependent on context.
Form input elements
  • Enter to submit
 When submit button or text input field is in focus, pressing the Enter key should submit the form. If submission is unsuccessful, any errors should be highlighted and focus should move to the problem field, depending on context. Similarly, if submission is successful, focus expectation is dependent on post-submission action type.
Checkboxes
  • ← ↑ → ↓ to navigate items
  • Spacebar to check/uncheck focused items
 Cannot be activated. Checkboxes can only be selected.
Radio buttons
  • ← ↑ → ↓ to navigate items
  • Tab to exit the group of buttons
  • Spacebar to select the focused option
 Cannot be activated. Radio buttons can only be selected.
Dropdown (Select/Combobox) menu
  • Spacebar to open the dropdown
  • ↑ ↓ to navigate dropdown items
  • Enter or Esc to select focused option and close the dropdown
 Cannot be activated. Dropdown menu items can only be selected.
Modal/Dialog
  • Esc to close
 Modal should close. Focus should return to the element that triggered the modal.