Hi everyone!
After exploring text alternatives, today we dive into another fundamental accessibility criterion: WCAG 2.1.1 Keyboard. This is a Level A criterion, meaning it's essential for WCAG conformance.
What is WCAG Success Criterion 2.1.1?
This criterion states that:
"All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, unless the underlying function requires path-dependent user input rather than just end-points."
In simple terms, it means that every interactive functionality on your website must be fully and intuitively usable with only a keyboard. This includes links, buttons, form fields, dropdowns, sliders, and any other element a user can interact with.
Why is Keyboard Navigation Crucial?
Many users rely on the keyboard for web navigation, including:
- Screen Reader Users: Often use only the keyboard to move between elements and interact with content.
- Users with Motor Disabilities: May be unable to use a mouse and rely on specialized keyboards, switches, or other keyboard-based input devices.
- Users with Low Vision (not blind): May find it easier to use the keyboard to navigate dense text pages.
- Power Users: Some simply prefer the speed and efficiency of keyboard navigation.
- All Interactive Elements: Every button, link, input field, checkbox, radio button, dropdown menu, etc., must be reachable and activatable via keyboard (usually with Tab, Enter, Space keys).
- Logical Tab Order: The order in which the keyboard moves between elements (tabindex) must be logical and intuitive, following the visual flow of the content.
- No Keyboard Traps: A user must never be "trapped" within a component (e.g., a modal or widget) without being able to exit using only the keyboard.
- Visible Focus State: There must be a clear visual indicator (outline, highlight) on the element that has keyboard focus, so the user knows where they are.
Example 1: Navigation Menus
- Correct: All menu links are reachable with Tab. Submenus open and are navigable with Tab and Arrow keys. Esc closes the submenu. Focus is always visible.
- Incorrect: The dropdown menu only opens on mouse hover. It's not possible to reach submenu links with the keyboard.
- Correct: When a modal opens, focus automatically shifts inside it. Tab navigation is limited only to the interactive elements within the modal. The Esc key closes the modal.
- Incorrect: Keyboard focus remains on the background behind the modal. The modal cannot be closed with Esc.
The simplest way to test is to use only your keyboard!
- Start from the top of the page (or after reloading the page).
- Repeatedly press the Tab key to move through all interactive elements.
- Verify that you can reach and activate every link, button, and form field.
- Check that the tab order is logical.
- Ensure there are no "traps" (elements from which you cannot exit with Tab).
- Verify that the visual focus is always clear.
What are the biggest challenges you face in ensuring keyboard accessibility? Have you encountered any particular keyboard traps or innovative solutions? Share your experiences and tips!
Warm regards,
Michele (wcgadmfrm)
WCAG Plus Forum Team