La consultation de chaque média temporel est-elle, si nécessaire, contrôlable par le clavier et tout dispositif de pointage ?
Un utilisateur naviguant exclusivement au clavier arrive sur une vidéo de formation. Il la voit démarrer, mais impossible de la mettre en pause : les boutons du lecteur ne répondent qu’au clic. La vidéo continue. Il quitte la page.
Ce critère impose deux exigences cumulatives. D’abord, les fonctionnalités minimales de contrôle doivent être présentes : lecture, pause ou stop. Si le média diffuse du son, un bouton de sourdine est obligatoire. Si des sous-titres sont disponibles, un bouton pour les afficher ou masquer. Si une audiodescription existe, un contrôle dédié. Sans ces éléments, le test 4.11.1 échoue, indépendamment de l’accessibilité clavier.
Ensuite, chaque fonctionnalité doit être à la fois accessible et activable au clavier. Accessible signifie que le focus peut atteindre le bouton via Tab. Activable signifie qu’appuyer sur Entrée ou Espace déclenche réellement l’action. Un bouton qui reçoit le focus mais ignore le clavier satisfait le test 4.11.2 et échoue au 4.11.3. Les deux tests sont distincts et tous deux obligatoires.
La solution la plus simple : des <button> natifs. Ils sont focusables et activables sans une ligne de JavaScript supplémentaire. Si le design impose des éléments non interactifs (<div>, <span>), ajoutez tabindex="0", role="button" et des gestionnaires keydown pour Enter et Space.
3 tests pour confirmer que le média temporel est pilotable au clavier
Présence des fonctionnalités de contrôle d'un média temporel
Pour chaque vidéo, audio ou média temporel présent dans la page :
- Vérifiez qu’un bouton lecture et un bouton pause ou stop sont présents.
- Si le média a une piste audio : vérifiez qu’un bouton de sourdine (mute/unmute) existe.
- Si le média propose des sous-titres : vérifiez qu’un bouton d’activation/désactivation des sous-titres est présent.
- Si le média propose une audiodescription : vérifiez qu’un bouton d’activation/désactivation de l’audiodescription est présent.
Résultat : si l’une de ces fonctionnalités obligatoires est absente sur un média qui devrait l’avoir, le test échoue.
Accessibilité clavier des contrôles d'un média temporel
Pour chaque média temporel disposant de fonctionnalités de contrôle :
- Naviguez uniquement au clavier (Tab, Shift+Tab) et vérifiez que le focus peut atteindre chaque bouton du lecteur.
- Testez les mêmes contrôles avec la souris ou un dispositif de pointage.
- Si un bouton n’est pas focusable au clavier, vérifiez qu’une alternative équivalente accessible au clavier est présente ailleurs dans la page.
Résultat : si un contrôle n’est ni focusable au clavier ni remplacé par une alternative accessible, le test échoue.
Activabilité clavier des contrôles d'un média temporel
Pour chaque média temporel disposant de fonctionnalités de contrôle :
- Placez le focus sur chaque bouton du lecteur via Tab.
- Appuyez sur Entrée. Vérifiez que l’action se déclenche (lecture, pause, sourdine, etc.).
- Recommencez avec la touche Espace sur chaque bouton.
- Testez les mêmes actions avec la souris.
- Si un bouton reçoit le focus mais ne répond ni à Entrée ni à Espace, vérifiez qu’une alternative activable au clavier est disponible dans la page.
Résultat : si un contrôle est focusable mais non activable au clavier, sans alternative, le test échoue.
Exemples
❌ Non conforme : Lecteur vidéo avec contrôles inaccessibles au clavier
<div class="player">
<video src="presentation.mp4" id="vid"></video>
<div class="controls">
<div class="btn" onclick="document.getElementById('vid').play()">▶ Lire</div>
<div class="btn" onclick="document.getElementById('vid').pause()">⏸ Pause</div>
<div class="btn" onclick="document.getElementById('vid').muted = !document.getElementById('vid').muted">🔇 Son</div>
</div>
</div>Les boutons sont des <div> sans tabindex ni role="button". Le clavier ne peut pas les atteindre : Tab passe directement de la vidéo à l’élément suivant dans la page. Même en ajoutant tabindex="0" a posteriori, l’événement onclick ne se déclenchera pas avec Entrée ou Espace. Tests 4.11.2 et 4.11.3 échouent.
✅ Conforme : Lecteur vidéo avec contrôles natifs accessibles
<div class="player">
<video src="presentation.mp4"
id="video-main"
aria-label="Présentation du produit"></video>
<div class="controls" role="group" aria-label="Contrôles de la vidéo">
<button type="button"
aria-label="Lire la vidéo"
onclick="document.getElementById('video-main').play()">
▶
</button>
<button type="button"
aria-label="Mettre en pause"
onclick="document.getElementById('video-main').pause()">
⏸
</button>
<button type="button"
aria-label="Couper le son"
aria-pressed="false"
onclick="toggleMute(this, 'video-main')">
🔇
</button>
<button type="button"
aria-label="Activer les sous-titres"
aria-pressed="false"
onclick="toggleCaptions(this, 'video-main')">
CC
</button>
</div>
</div>Les <button> natifs sont focusables et activables au clavier sans configuration supplémentaire : Tab atteint chaque bouton, Entrée et Espace déclenchent l’action. aria-pressed sur les boutons Son et CC indique aux lecteurs d’écran l’état actuel (activé ou non). Tests 4.11.1, 4.11.2 et 4.11.3 passent.
Astuces et pièges
⚠️ Focusable n’est pas activable : l’erreur classique du <div>
C’est l’erreur la plus fréquente en audit multimédia. Ajouter tabindex="0" sur un <div> le rend focusable (test 4.11.2 passe), mais l’événement onclick ne se déclenche pas avec Entrée ou Espace (test 4.11.3 échoue). Il faut gérer explicitement keydown avec event.key === 'Enter' et event.key === ' '. Deux lignes de JavaScript que vous n’auriez pas à écrire avec un <button>.
⚠️ Raccourcis clavier du lecteur sans documentation
Certains lecteurs personnalisés interceptent les touches fléchées pour avancer ou reculer, ou la touche Espace pour la pause. Si ces raccourcis capturent des touches standard du navigateur sans possibilité de désactivation, ils créent un piège au clavier au sens du WCAG 2.1.2. Tout raccourci clavier propre au lecteur doit être documenté à proximité immédiate du composant.
💡 L’attribut controls natif est sous-utilisé
Sur un <video controls>, les navigateurs modernes génèrent des contrôles natifs entièrement accessibles au clavier : lecture, pause, volume, plein écran. Chrome, Firefox et Safari les exposent correctement aux technologies d’assistance. Pour un projet sans contrainte de style forte sur le lecteur, c’est la solution la plus robuste et la moins coûteuse à maintenir.
⚠️ Lecteurs embarqués via <iframe> (YouTube, Vimeo)
Un lecteur intégré via <iframe> échappe au périmètre RGAA si la page n’en contrôle pas le code source. YouTube et Vimeo gèrent eux-mêmes l’accessibilité de leurs lecteurs. En revanche, le principe de non-interférence s’applique : si l’<iframe> crée un piège au clavier, un lien d’évitement permettant de le contourner est nécessaire dans la page hôte.
⚠️ Quand le critère ne s’applique pas
La formulation « si nécessaire » laisse entendre que certains médias pourraient être exemptés. En pratique, dès qu’un média est porteur de contenu (information, narration, démonstration), les contrôles sont nécessaires. Les cas d’exemption réelle concernent uniquement les médias purement décoratifs, sans information et sans son.
Questions fréquentes
Quelle est la différence concrète entre le test 4.11.2 et le test 4.11.3 ?
4.11.2 teste l’accessibilité : le focus clavier peut-il atteindre le bouton ? 4.11.3 teste l’activabilité : une fois focusé, le bouton réagit-il à Entrée et Espace ? Un <div tabindex="0"> avec seulement un onclick réussit le premier et échoue au second. Les deux tests sont indépendants et doivent être vérifiés séparément.
Comment auditer le critère RGAA 4.11 sur le contrôle clavier sans outil spécialisé ?
Débranchez la souris. Naviguez au clavier uniquement : Tab doit atteindre chaque bouton du lecteur, Entrée et Espace doivent déclencher l’action. Testez lecture, pause, sourdine, sous-titres et audiodescription. Vérifiez ensuite qu’il n’y a pas de piège : la touche Tab doit permettre de sortir du lecteur sans bloquer. Comptez moins de deux minutes par lecteur pour un audit manuel complet.
Quelle différence entre transcription textuelle et contrôle clavier dans le cadre du RGAA 4.11 ?
Non. La transcription est une alternative au contenu du média (critères 4.1 et 4.3). Elle ne remplace pas les contrôles de lecture. Les deux sont des exigences indépendantes : même avec une transcription parfaite, le lecteur doit rester contrôlable au clavier.
Comment le critère RGAA 4.11 s'applique-t-il aux vidéos en lecture automatique ?
Oui. Une vidéo en autoplay doit avoir un bouton de pause accessible au clavier. C’est d’autant plus critique que l’autoplay perturbe les utilisateurs de lecteurs d’écran dès que la vidéo contient du son. Si la vidéo dure plus de 3 secondes avec du son et se lance automatiquement sans contrôle de l’utilisateur, c’est aussi un problème au regard du critère RGAA 4.10.
Quand un lecteur média avec raccourcis clavier documentés satisfait-il au critère RGAA 4.11 ?
Oui, à condition que les raccourcis soient documentés à proximité du lecteur et que la documentation elle-même soit accessible au clavier. Le test 4.11.2 admet qu’une alternative accessible au clavier puisse être « présente dans la page » plutôt que directement sur le contrôle. La documentation des raccourcis constitue cette alternative. En pratique, les boutons visibles restent préférables car ils bénéficient aussi aux utilisateurs de dispositifs de pointage non standard.