Can each time-based medium be operated, where necessary, with the keyboard and any pointing device?
A user navigating exclusively by keyboard arrives at a training video. They see it start, but cannot pause it: the player buttons only respond to clicks. The video continues. They leave the page.
This criterion imposes two cumulative requirements. First, the minimal control functionalities must be present: play, pause, or stop. If the media broadcasts sound, a mute button is mandatory. If subtitles are available, a button to show or hide them. If an audio description exists, a dedicated control. Without these elements, test 4.11.1 fails, regardless of keyboard accessibility.
Second, each functionality must be both accessible and activatable by keyboard. Accessible means the focus can reach the button via Tab. Activatable means pressing Enter or Space actually triggers the action. A button that receives focus but ignores keyboard input passes test 4.11.2 and fails 4.11.3. The two tests are distinct and both mandatory.
The simplest solution: native <button> elements. They are focusable and activatable without a single line of extra JavaScript. If design requires non-interactive elements (<div>, <span>), add tabindex="0", role="button" and keydown handlers for Enter and Space.
3 tests to confirm that temporal media is keyboard controllable
Presence of control features of temporal media
For each video, audio, or temporal media present on the page:
- Verify that a play button and a pause or stop button are present.
- If the media has an audio track: verify that a mute/unmute button exists.
- If the media offers subtitles: verify that a button to activate/deactivate subtitles is present.
- If the media offers audio description: verify that a button to activate/deactivate audio description is present.
Result: if any of these mandatory functionalities is missing from a media that should have it, the test fails.
Keyboard accessibility of temporal media controls
For each temporal medium with control functionalities:
- Navigate using only the keyboard (Tab, Shift+Tab) and verify that focus can reach each player button.
- Test the same controls with a mouse or pointing device.
- If a button is not keyboard focusable, verify that an equivalent keyboard-accessible alternative exists elsewhere on the page.
Result: if a control is neither focusable by keyboard nor replaced by an accessible alternative, the test fails.
Keyboard activatability of temporal media controls
For each temporal medium with control functionalities:
- Place focus on each player button via Tab.
- Press Enter. Verify that the action triggers (play, pause, mute, etc.).
- Repeat with the Space key on each button.
- Test the same actions with a mouse.
- If a button receives focus but responds to neither Enter nor Space, verify that a keyboard-activatable alternative is available on the page.
Result: if a control is focusable but not activatable by keyboard, without an alternative, the test fails.
Examples
❌ Non-compliant : Video player with keyboard-inaccessible controls
<div class="player">
<video src="presentation.mp4" id="vid"></video>
<div class="controls">
<div class="btn" onclick="document.getElementById('vid').play()">▶ Play</div>
<div class="btn" onclick="document.getElementById('vid').pause()">⏸ Pause</div>
<div class="btn" onclick="document.getElementById('vid').muted = !document.getElementById('vid').muted">🔇 Sound</div>
</div>
</div>The buttons are <div> elements without tabindex or role="button". The keyboard cannot reach them: Tab passes directly from the video to the next element on the page. Even if tabindex="0" is added afterward, the onclick event will not trigger with Enter or Space. Tests 4.11.2 and 4.11.3 fail.
✅ Compliant : Video player with keyboard-accessible native controls
<div class="player">
<video src="presentation.mp4"
id="video-main"
aria-label="Product presentation"></video>
<div class="controls" role="group" aria-label="Video controls">
<button type="button"
aria-label="Play video"
onclick="document.getElementById('video-main').play()">
▶
</button>
<button type="button"
aria-label="Pause"
onclick="document.getElementById('video-main').pause()">
⏸
</button>
<button type="button"
aria-label="Mute sound"
aria-pressed="false"
onclick="toggleMute(this, 'video-main')">
🔇
</button>
<button type="button"
aria-label="Enable subtitles"
aria-pressed="false"
onclick="toggleCaptions(this, 'video-main')">
CC
</button>
</div>
</div>Native <button> elements are focusable and keyboard-activatable without additional configuration: Tab reaches each button, Enter and Space trigger the action. aria-pressed on the Sound and CC buttons indicates to screen readers the current state (activated or not). Tests 4.11.1, 4.11.2, and 4.11.3 pass.
Tips and pitfalls
⚠️ Focusable is not activatable: the classic <div> error
This is the most frequent error in multimedia audits. Adding tabindex="0" to a <div> makes it focusable (test 4.11.2 passes), but the onclick event does not trigger with Enter or Space (test 4.11.3 fails). You must explicitly handle keydown with event.key === 'Enter' and event.key === ' '. Two lines of JavaScript you would not need to write with a <button>.
⚠️ Player keyboard shortcuts without documentation
Some custom players intercept arrow keys to advance or rewind, or the Space key for pause. If these shortcuts capture standard browser keys without the ability to disable them, they create a keyboard trap in the sense of WCAG 2.1.2. Any player-specific keyboard shortcut must be documented in immediate proximity to the component.
💡 The native controls attribute is underused
On a <video controls>, modern browsers generate native controls that are fully keyboard-accessible: play, pause, volume, fullscreen. Chrome, Firefox, and Safari expose them correctly to assistive technologies. For a project without strong styling constraints on the player, this is the most robust and least costly solution to maintain.
⚠️ Players embedded via <iframe> (YouTube, Vimeo)
A player integrated via <iframe> falls outside the RGAA scope if the page does not control its source code. YouTube and Vimeo manage the accessibility of their players themselves. However, the principle of non-interference applies: if the <iframe> creates a keyboard trap, a skip link allowing it to be bypassed is necessary in the host page.
⚠️ When the criterion does not apply
The phrasing "if necessary" suggests that some media could be exempted. In practice, as soon as a medium carries content (information, narration, demonstration), controls are necessary. Real exemption cases concern only purely decorative media, without information and without sound.
Frequently asked questions
What is the concrete difference between test 4.11.2 and test 4.11.3?
4.11.2 tests accessibility: can keyboard focus reach the button? 4.11.3 tests activatability: once focused, does the button respond to Enter and Space? A <div tabindex="0"> with only an onclick passes the first and fails the second. The two tests are independent and must be verified separately.
How can I audit RGAA criterion 4.11 for keyboard control without specialized tools?
Unplug your mouse. Navigate using only the keyboard: Tab must reach each player button, Enter and Space must trigger the action. Test play, pause, mute, subtitles, and audio description. Then verify there is no trap: Tab must allow you to exit the player without blocking. Count less than two minutes per player for a complete manual audit.
What is the difference between text transcript and keyboard control in the context of RGAA 4.11?
None. The transcript is an alternative to the media content (criteria 4.1 and 4.3). It does not replace keyboard controls. Both are independent requirements: even with a perfect transcript, the player must remain keyboard-controllable.
How does RGAA criterion 4.11 apply to autoplay videos?
Yes. An autoplay video must have a pause button accessible by keyboard. This is all the more critical as autoplay disturbs screen reader users as soon as the video contains sound. If the video lasts more than 3 seconds with sound and launches automatically without user control, this is also an issue under RGAA criterion 4.10.
When does a media player with documented keyboard shortcuts satisfy RGAA criterion 4.11?
Yes, provided that the shortcuts are documented in immediate proximity to the player and the documentation itself is keyboard-accessible. Test 4.11.2 allows that a keyboard-accessible alternative may be "present on the page" rather than directly on the control. Documentation of shortcuts constitutes this alternative. In practice, visible buttons remain preferable because they also benefit users of non-standard pointing devices.