2.1.3 Keyboard (No Exception)

1. What is the goal of this criterion?

For some people, the keyboard is the only way to use the web – as indispensable as their own front door key. While Keyboard already lays a solid foundation for keyboard accessibility, 2.1.3 goes one step further: no exceptions are allowed.

The goal of Success Criterion 2.1.3 is clear: every function of a website must be operable via the keyboard – no ifs or buts. Where 2.1.1 still allows an exception for path-dependent input (such as freehand drawing), 2.1.3 drops it.

2. What exactly does it require?

Specifically, Level AAA requires that all functionality, without exception, is operable through a keyboard interface:

Full keyboard operability without exceptions: every button, every menu, every interactive component must be reachable and operable with the keyboard.

No time-critical keystrokes: nobody may be put under time pressure – so no functions where you have to hold a key for an exact length of time or press it repeatedly very quickly.

Path-dependent functions are covered too: if a function inherently requires path-dependent input (such as freehand drawing), it can’t meet this criterion as long as there is no keyboard alternative. Pages with such functions only meet 2.1.3 if they offer an equivalent keyboard way.

No mouse emulation: features such as the operating system’s MouseKeys don’t count as keyboard operation, because they simulate a mouse pointer rather than using the keyboard interface.

The rule is simple: whatever works with a mouse must also work with a keyboard – full stop.

3. Why does it matter for accessibility?

Imagine wanting to use an online application, but you can’t use a mouse or touchscreen – only a keyboard or a device that produces keyboard input. For people with mobility impairments or blindness, that’s not a thought experiment but everyday life.

Full keyboard operability enables real participation because it:

• Gives people with motor impairments who rely on specialized keyboards, mouth sticks or switch access unrestricted access.
• Supports blind and visually impaired people, whose screen reader use is keyboard-based.
• Helps people with temporary impairments (a broken arm, a broken mouse).
• Appeals to professional users who prefer the keyboard for efficiency.
• Provides the foundation for many assistive technologies that work through the keyboard interface.

And finally, it makes websites more robust for new input methods and assistive tools.

4. How to meet the criterion

Level AAA calls for particular care – here are some proven strategies:

Perfect the basics:

• Use semantic HTML (<button>, <a>, <input>) instead of styled <div> or <span> elements for interactive elements.
• Ensure a logical focus order and thoughtful focus management.
• Make sure all focus states are visible and unambiguous.
• Use ARIA roles and properties correctly – ARIA only describes elements; you have to build the keyboard behavior yourself.

Implement keyboard behavior correctly:

• Native buttons and links respond to Enter automatically (and buttons to Space). You only need your own keydown handlers for custom-built elements.
• Implement arrow key navigation for menus, tabs and lists following established patterns.
• Offer Escape to close dialogs and popups.
• Keep focus inside modal dialogs, but make sure they can be closed with the keyboard (see No Keyboard Trap).

Offer alternatives for complex interactions:

• Complement drag and drop with cut/paste or move buttons.
• Offer input fields or plus/minus buttons for sliders.
• Provide shape templates or coordinate input for drawing features.
• Always add extra controls to gesture-based interactions.

Test and verify:

• Put the mouse away and test the entire website using only the keyboard.
• Check operability with screen readers (NVDA, JAWS, VoiceOver).
• Test with different input aids and assistive technologies.
• Walk through complex workflows step by step.

5. Why this criterion matters for businesses

Level AAA is voluntary, but the case for full keyboard operation is strong:

1. Reach a wider audience

Consistent keyboard support doesn’t just reach people with disabilities – it also appeals to power users and efficiency-minded users. For specialist B2B applications in particular, good keyboard support is a real mark of quality.

2. Be well prepared

If you meet 2.1.3, you automatically meet 2.1.1 – and you’re on the safe side in accessibility audits in this area.

3. Demonstrate technical quality

Full keyboard operability is a hallmark of thoughtful, professional web development. It signals technical competence and user focus – important factors for trust and brand image.

Last but not least: the legal context. Level AAA is not required by the European Accessibility Act or by its German implementation, the Barrierefreiheitsstärkungsgesetz (BFSG) – the benchmark there is WCAG 2.1 Level AA via EN 301 549, and therefore 2.1.1. The W3C also advises against requiring Level AAA as a general policy for entire sites, because not all content can meet it. This section is general information, not legal advice.

6. The success criterion in the W3C’s words

Success Criterion 2.1.3 Keyboard (No Exception) (Level AAA)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

In short: all functionality must be operable by keyboard without specific timing requirements – without the exception for path-dependent input that 2.1.1 still allows.