Requires that every function can be operated from a keyboard, without needing specific timings for individual keystrokes.
Many people never use a mouse or a touch screen. Screen reader users, people with motor disabilities, people with tremors and anyone who uses a switch, a sip-and-puff device or voice control all rely on the keyboard or on something that behaves like one. If a function works only with a pointer, they cannot use it.
This criterion requires that all functionality is operable through a keyboard interface, without requiring specific timings for individual keystrokes. The exception is functionality that depends on the path of the movement, such as freehand drawing, not just on its end points.
TRa, button, input, select and textarea are keyboard accessible by default. Custom controls must reproduce their behavior.Screen reader users, who navigate with the keyboard. People with motor disabilities who cannot use a mouse. People who use switches, eye trackers, voice control or on-screen keyboards. People with tremors. Power users who prefer the keyboard.
The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Operability by keyboard is part of "operable".
The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.1.1 by reference and turns it into separate clauses for each kind of ICT.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.2.1.1 | Web pages | Web content must satisfy WCAG success criterion 2.1.1. |
| 10.2.1.1 | Non-web documents (PDF, Office files) | Documents must be operable through a keyboard interface where the standard applies the criterion to them. |
| 11.2.1.1 | Non-web software (native mobile apps) | Software must be operable through a keyboard interface (for native apps: a hardware keyboard, switch or similar). |
Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.
Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.1.1 is the same in WCAG 2.1 and 2.2.
A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.
Directive (EU) 2019/882, EUR-Lex, opens in a new tab
A div with a click handler is not focusable and does not react to Enter or Space.
<div class="btn" onclick="save()">Save</div><button type="button" onclick="save()">Save</button>Give it a role, make it focusable and handle Enter and Space.
<span onclick="toggle()">Menu</span><span role="button" tabindex="0" onclick="toggle()"
onkeydown="if (event.key === 'Enter' || event.key === ' ') {
event.preventDefault(); toggle();
}">Menu</span>An anchor without an href is not focusable.
<a onclick="openPage()">Pricing</a><a href="/pricing">Pricing</a>Show the submenu on focus as well as on hover.
.nav li:hover > ul { display: block; }.nav li:hover > ul,
.nav li:focus-within > ul { display: block; }A region that scrolls but contains no focusable content cannot be scrolled with the keyboard in some browsers. Make it focusable.
<div class="log" style="overflow:auto; height:200px">…</div><div class="log" style="overflow:auto; height:200px"
tabindex="0" role="region" aria-label="Activity log">…</div>Offer buttons or keys that do the same thing.
<li draggable="true">Item</li> <!-- only draggable --><li>
Item
<button aria-label="Move item up">↑</button>
<button aria-label="Move item down">↓</button>
</li>Native apps are operated with external keyboards, switch control and full keyboard access. Use standard controls so they work with these inputs, and avoid gestures with no equivalent action.
import SwiftUI
struct SaveRow: View {
var body: some View {
// Avoid: a tap gesture on a Text is not reachable with Full Keyboard Access
// Text("Save").onTapGesture { save() }
// Use a Button: focusable, activatable with Space and VoiceOver
Button("Save") { save() }
// For custom gestures, add an equivalent action
Text("Archive")
.onTapGesture { archive() }
.accessibilityAddTraits(.isButton)
.accessibilityAction(named: "Archive") { archive() }
}
}import androidx.compose.foundation.clickable
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.Role
@Composable
fun SaveRow() {
// Avoid: pointerInput { detectTapGestures { ... } } on a Text,
// which a keyboard or switch cannot trigger
// Use a Button, or clickable with a role: focusable and activated with Enter/Space
Button(onClick = { save() }) { Text("Save") }
Text(
"Archive",
modifier = Modifier.clickable(role = Role.Button) { archive() }
)
}div and span elements: The most frequent failure of this criterion.href: Not focusable.tabindex values above 0: They scramble the focus order.Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
