WCAG 2.1 and Keyboard Accessibility
| Site: | IDWerkz Resources |
| Course: | Keyboard Navigation |
| Book: | WCAG 2.1 and Keyboard Accessibility |
| Printed by: | Guest user |
| Date: | Monday, 29 September 2025, 12:54 AM |
Description
Learn about the WCAG Success Criteria that address keyboard accessibility.
1. Accessibility = WCAG + Usability
The ability to assess anything in life requires a standard by which to measure things. With Keyboard accessibility, there are two essential standards to guide our efforts: WCAG and Usability.
These two standards work together, one leading into the other like a river flows into an ocean.
WCAG tell you how to approach the task of creating and assessing your success, while actual usability reveals the ultimate truth of whether or not your content can truly be used via the keyboard with the same ease and efficiency as other interface input options.
2. WCAG Essentials
WCAG
The WCAG is a topic that extends beyond the scope of this tutorial. We will only cover have time for a general overview and a few criteria directly relevant to keyboard accessibility.
POUR – The Essential Principles of WCAG
POUR is a powerful acronym and convenient way to summarize the scope and intent of the WCAG. POUR stands for:
Perceivable
Operable
Understandable
Robust
Together these four elements of digital content reference the essential aspects of making digital content accessible, and more importantly, usable.
3. WCAG Success Criteria 2.1: Keyboard Accessible
WCAG Success Criteria 2.1 requires that all functionality be available from a keyboard.
Even if your designing content for a device with no keyboard, you must also include functionality for keyboards.
You should still optimize your content for the other input methods your target device supports, while maintaining the capability for keyboard control.
Requiring keyboard accessibility does not prohibit mouse input nor discourage providing mouse and other input methods in addition to keyboard accessibility.
There are several supporting Success Criteria for Keyboard Accessibility:
2.1.1 Keyboard
All functionality of the content is available through a keyboard interface without requiring specific timings for individual keystrokes except where the underlying function requires input that depends on the user’s movement and not just the endpoints.
2.1.2 No Keyboard Trap
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.
2.1.3 Keyboard (No Exception)
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
2.1.4 Character Key Shortcuts
If a keyboard shortcut is implemented, it must allow for modification, and be active only on focus.
2.4.7 Focus Visible
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.