If your website requires a mouse to function properly, WCAG 2.1.1 applies to you. In this WCAG Fix It guide, we’re breaking down one of the most fundamental accessibility requirements: ensuring all functionality is available using only a keyboard.
- No mouse
- No touchscreen
- Just the keyboard
If a user cannot navigate your website without a mouse, your website is not accessible, and fixing this often requires structure, not redesign.
What Is WCAG 2.1.1?
WCAG 2.1.1 – Keyboard requires that all functionality of the content is operable through a keyboard interface. In simple terms, this means if something can be clicked, it must also be accessible using the keyboard. This includes:
- Links
- Buttons
- Menus
- Dropdowns
- Modals
- Forms
- Sliders
- Carousels
- Custom components
Users must be able to navigate with the Tab key, activate controls using Enter or Space, and move through interactive elements logically.
Why Keyboard Accessibility Matters
Many users rely entirely on keyboard navigation, including:
- Screen reader users
- Users with motor impairments
- Users with temporary injuries
- Power users who prefer keyboard shortcuts
If your site traps focus, skips elements, or requires a mouse to activate controls, those users are blocked.
The Human Impact of Poor Keyboard Support
Imagine navigating a website without a mouse. You press Tab, and the focus jumps unpredictably. You reach a dropdown, but it won’t open. You reach a modal, but you can’t close it. You get stuck inside a menu with no way out.
Now imagine relying on that method every day. When websites fail keyboard accessibility, users lose control, and when users lose control, they leave.
Common WCAG 2.1.1 Failures
Here’s what we typically see when scanning websites:
- Clickable <div> elements that aren’t keyboard-accessible
- Custom dropdown menus that don’t open with Enter or Space
- Carousels that require mouse dragging
- Hover-only menus that can’t be accessed via keyboard
- Modals that trap keyboard focus
- Elements removed from the tab order incorrectly
All of these can fail WCAG 2.1.1.
How to Fix Keyboard Accessibility Issues
Several methods are available for fixing keyboard accessibility issues. Here’s how it works:
Use Native HTML Elements
Instead of: <div onclick=”openMenu()”>Menu</div>
Use: <button onclick=”openMenu()”>Menu</button>
Native elements automatically support keyboard interaction. This is the simplest and most effective fix.
Ensure All Interactive Elements Are Focusable
Interactive elements must be reachable using the Tab key.
Avoid: <div class=”button”>Submit</div>
Unless you fully implement keyboard functionality and ARIA roles.
Ensure Controls Respond to Keyboard Events
Buttons should activate on:
- Enter
- Space
Custom components must handle keyboard events appropriately.
Avoid Hover-Only Functionality
If content appears on hover, it must also appear on focus.
Keyboard users do not hover.
How to Test WCAG 2.1.1
The simplest test is to unplug your mouse and try to use your website. During this on-site testing period you should be able to use:
- Tab to move forward
- Shift + Tab to move backward
- Enter to activate
- Space to toggle
When testing WCAG 2.1.1 compliance, you should also be asking:
- Can I reach every interactive element?
- Can I activate everything?
- Can I open and close modals?
- Can I submit forms?
If anything requires a mouse, it fails. Re-run your accessibility scan and confirm 2.1.1 is no longer flagged.
Why WCAG 2.1.1 Matters Beyond Compliance
Keyboard accessibility:
- Improves usability
- Supports assistive technology
- Prevents user frustration
- Improves overall interaction design
- Reduces legal risk
If users can’t operate your website, nothing else matters. Keyboard support is not a “nice to have.” It’s a baseline expectation level A, WCAG compliance.
WCAG 2.1.1 Quick Fix Checklist
We’ve already discussed a wide variety of fixes and best practices for WCAG 2.1.1, so now it’s time to implement. Start making change today with this checklist:
- All functionality accessible via keyboard
- No mouse-only interactions
- Buttons use proper elements
- Custom components support Enter and Space
- No hover-only navigation
- No keyboard traps
- Website tested without a mouse
- Issues re-tested after updates
WCAG 2.1.1 Keyboard FAQs
Looking for a quick recap? Here are answers to some of the most frequently asked questions on this topic:
WCAG 2.1.1 requires that all website functionality can be operated using only a keyboard interface.
Yes. Users must be able to navigate and activate all controls using the keyboard.
Buttons should activate using Enter or Space. Links activate using Enter.
A keyboard trap occurs when a user tabs into a component but cannot tab back out using the keyboard.