Keyboard accessibility ensures that all functionality is available via keyboard alone. This is not a feature – it is a fundamental requirement for web accessibility. Many people cannot use a mouse due to motor disabilities, visual impairments, or personal preference.
Overview
Keyboard accessibility ensures that all functionality is available via keyboard alone. This is not a feature – it is a fundamental requirement for web accessibility. Many people cannot use a mouse due to motor disabilities, visual impairments, or personal preference. Screen reader users and power users alike depend on keyboard navigation to efficiently access digital content and services.
Why this matters
Keyboard accessibility is foundational. Many assistive technologies (screen readers, switch devices, voice control) ultimately interact with web content through the keyboard interface. If something isn’t keyboard accessible, it’s likely inaccessible to many AT users. When you make your website keyboard accessible, you are ensuring that:
- All interactive elements are reachable via keyboard navigation
- All interactive elements can be operated via keyboard
- Users never encounter keyboard traps where they cannot escape using only the keyboard
- Focus is visibly indicated so users know which element has keyboard focus
Who Relies on Keyboard Accessibility?
- Users with motor disabilities who cannot use a mouse
- Blind and low-vision users who rely on screen readers and keyboard navigation
- Users with tremors or arthritis who find precise mouse movements difficult
- Power users who prefer keyboard navigation for efficiency
- Users in touch-screen environments where keyboards are the primary input method
Testing Keyboard Accessibility
Testing keyboard accessibility does not require special tools. You can use your keyboard right now to evaluate your website. Here is how to conduct basic keyboard accessibility testing:
Step-by-Step Testing Process
- Disable your mouse or trackpad, or simply avoid using it
- Open your website in a web browser
- Use only the keyboard to navigate and interact with all content and functionality
- Follow the keyboard interaction patterns described below
- Verify that you can reach every interactive element and operate every function
- Check that focus indicators are clearly visible at all times
- Ensure you never get stuck in a keyboard trap
Common Keyboard Interactions to Test
- Tab to move forward through focusable elements
- Shift+Tab to move backward through focusable elements
- Enter to activate buttons and submit forms
- Space to activate buttons and toggle checkboxes
- Arrow keys to navigate within custom widgets like menus, tabs, radio groups, and sliders
- Escape to close dialogs, menus, and popups
Common Keyboard Shortcuts and Keystrokes Reference
Below is a comprehensive reference of standard keyboard shortcuts and keystrokes used in web accessibility. These are conventions that users expect to work consistently across different websites and applications.
Navigation Shortcuts
- Tab – Move to the next focusable element in tab order
- Shift+Tab – Move to the previous focusable element in tab order
- Home – Jump to the beginning of a list or text field
- End – Jump to the end of a list or text field
- Page Up – Scroll up by one page
- Page Down – Scroll down by one page
Activation and Selection Shortcuts
- Enter – Activate buttons, links, and submit forms
- Space – Activate buttons, toggle checkboxes, activate radio buttons, and scroll the page
- Arrow Keys (Up/Down/Left/Right) – Navigate within composite widgets such as menus, tabs, radio groups, sliders, and tree structures
Dialog and Menu Shortcuts
- Escape – Close modal dialogs, dropdowns, menus, and popups
- Alt+Down Arrow – Open a dropdown or select menu (in some applications)
Creating Keyboard-Accessible Content
Building keyboard-accessible websites requires following a few key principles. The good news is that semantic HTML provides keyboard accessibility by default. When you use the right elements for the right purpose, keyboard support comes built-in.
Use Semantic HTML Elements
Semantic HTML elements like <button>, <a>, and <input> provide keyboard support automatically. Never use <div> or <span> for interactive elements unless you add proper ARIA roles and implement keyboard event handlers.
- Use <button> for buttons
- Use <a> for links
- Use <input type=”checkbox”> for checkboxes
- Use <input type=”radio”> for radio buttons
- Use <select> for dropdown lists
- Use <textarea> for multi-line text input
- Use <label> to associate labels with form inputs
Managing Focus with tabindex
The tabindex attribute controls whether an element can receive keyboard focus. Use it thoughtfully:
- tabindex=”0″ – Makes a non-focusable element focusable in the normal tab order. Use this to make custom interactive elements keyboard accessible.
- tabindex=”-1″ – Makes an element focusable programmatically but not via keyboard Tab. Use this for elements you want to focus with JavaScript, like modals or popups that should not be in the tab order initially.
- Positive tabindex values (1, 2, 3, etc.) – NEVER use these. They disrupt the natural tab order and confuse users. Always use tabindex=”0″ or tabindex=”-1″ instead.
Follow WAI-ARIA Authoring Practices
For custom interactive widgets, follow the WAI-ARIA Authoring Practices guide. This guide documents the keyboard behaviors expected for common patterns like:
- Dropdown menus
- Modal dialogs
- Tabs and tab panels
- Toolbars
- Sliders
- Autocomplete widgets
- Tree structures
Provide Skip Navigation Links
Skip navigation links allow keyboard users to bypass repetitive content like navigation menus. Include a link at the very beginning of your page that says “Skip to main content” and jumps directly to your main content area.
The skip link should be:
- The first focusable element on the page
- Visible when focused (use :focus styles, not visibility:hidden)
- Linked to the main content area with an anchor (#main-content)
Ensure Dropdowns and Modals Are Keyboard Operable
Dropdown menus, autocomplete fields, and modal dialogs must be fully operable with the keyboard:
- Opening: Enter or Space (depending on the widget type)
- Navigation: Arrow keys to move through options
- Selection: Enter or Space to select an option
- Closing: Escape to close the menu or dialog
- Focus management: When closing a modal, return focus to the button that opened it
Focus Indicators and Visual Feedback
A focus indicator shows which element currently has keyboard focus. This is essential for keyboard users to know where they are in the document. Never remove focus indicators without providing a custom replacement.
The Default Browser Focus Outline
Most browsers display a default focus outline (usually a blue ring or border) around focused elements. This outline is visible and provides necessary feedback to keyboard users. While you may customize this outline to match your design, removing it entirely is a common accessibility failure.
CSS Rules for Focus Styles
If you customize focus indicators, follow these rules:
- Never use outline: none without providing an alternative focus style
- Ensure sufficient contrast: focus indicators must have at least 3:1 contrast ratio per WCAG 2.4.11
- Make focus visible: use at least a 2px outline or border
- Use :focus-visible for keyboard-only focus styles (recommended best practice)
Best Practice: :focus-visible Pseudo-class
Modern browsers support the :focus-visible pseudo-class, which applies focus styles only when keyboard navigation is detected. This allows you to show focus indicators for keyboard users while removing them for mouse users who see the :hover state instead.
WCAG Accessibility Criteria
Keyboard accessibility is addressed by several WCAG 2.1 Level A and Level AA criteria. Meeting these criteria is a legal requirement for many organizations and ensures compliance with accessibility standards.
WCAG 2.1.1: Keyboard (Level A)
All functionality of the content is operable at a minimum through a keyboard interface without requiring specific timings for individual keystrokes.
WCAG 2.1.2: No Keyboard Trap (Level A)
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
WCAG 2.1.4: Character Key Shortcuts (Level A)
If a keyboard shortcut is implemented in content using only letter (including uppercase and lowercase), punctuation, number, or symbol characters, then at least one of the following is true: (a) the shortcut can be turned off, (b) the shortcut can be remapped to use one or more non-printable keyboard characters, or (c) the shortcut is only active when that UI component is focused.
WCAG 2.4.7: Focus Visible (Level AA)
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
Implementation Best Practices
Logical Tab Order
The tab order should follow the logical reading order of your page. Generally, this happens automatically if you use semantic HTML and avoid positive tabindex values. Test tab order by:
- Opening your page in a browser
- Pressing Tab repeatedly
- Ensuring focus moves from left to right, top to bottom
- Checking that focus skips hidden or disabled elements
Custom Keyboard Handlers
When building custom widgets, implement keyboard event handlers to respond to the expected keystrokes. For example:
- Menu buttons should open on Enter or Space
- Menu items should navigate with arrow keys
- Dialogs should close on Escape
- Comboboxes should filter options as users type
Testing with Assistive Technologies
Test your keyboard accessibility with actual screen readers and keyboard-only navigation:
- Windows: NVDA (free) or JAWS
- Mac: VoiceOver (built-in)
- Test with keyboard only (no mouse) to ensure all functions are accessible
Common Mistakes to Avoid
- Removing focus outlines with outline: none CSS without providing a replacement
- Using positive tabindex values (tabindex=”1″, tabindex=”2″, etc.) which breaks natural tab order
- Creating keyboard traps where users cannot escape with Tab or Escape
- Using onClick handlers on non-button elements (like divs) without implementing keyboard support
- Hiding skip navigation links with display: none (they should be hidden visually but still focusable)
- Not providing keyboard support for custom dropdowns, tabs, and sliders
- Using auto-advancing focus (like tab-ahead) without warning users
- Requiring mouse hover to reveal content (keyboard users cannot hover – use focus instead)
Related Resources
Keyboard accessibility is one part of a comprehensive accessibility strategy. For more information, see:
Getting help
If you have questions or need assistance, the Digital Accessibility Services Hub (DASH) is available to support colleges, schools, and administrative units as they build sustainable accessibility practices.
- Contact DASH at [email protected] for consultations, training, or technical assistance.
Accessibility is a shared responsibility, and every step you take makes UGA’s digital environment more inclusive.