Chaque média temporel et non temporel est-il compatible avec les technologies d’assistance (hors cas particuliers) ?
Un utilisateur de lecteur d’écran arrive sur une page avec un lecteur vidéo personnalisé. Les boutons « Lecture », « Pause » et « Volume » sont des <div> cliquables. Visuellement : parfait. Pour les technologies d’assistance : silence total. Pas de rôle, pas de nom, pas d’état. Le critère 4.13 exige que les composants d’interface d’un lecteur média soient lisibles par une API d’accessibilité.
Concrètement, chaque contrôle du lecteur — bouton Lecture/Pause, barre de progression, sélecteur de volume, activation des sous-titres — doit exposer son nom, son rôle, sa valeur et ses changements d’état via l’API d’accessibilité du navigateur. Le bouton Lecture doit avoir un rôle « button », un nom accessible, et signaler son changement d’état quand la lecture démarre. La barre de progression doit indiquer sa valeur courante en pourcentage ou en temps.
L’alternative est aussi valide. Si le lecteur intégré ne peut pas être rendu compatible, proposez un lecteur de remplacement accessible — à condition qu’il soit joignable immédiatement : adjacent dans le code, accessible via un lien ou bouton adjacent, ou disponible via un mécanisme de remplacement. C’est ce que vérifie le test 4.13.2.
En 2026, ce critère vise quasi exclusivement les lecteurs vidéo et audio personnalisés. Les médias non temporels au sens du RGAA (Flash, Silverlight, visites 3D propriétaires) ont disparu des navigateurs modernes. L’enjeu réel : vos contrôles vidéo maison.
2 tests pour s'assurer de la compatibilité des médias avec les technologies d'assistance
Compatibilité des médias avec les technologies d'assistance
- Repérez tous les médias temporels (
<video>,<audio>,<object>) et non temporels (lecteurs propriétaires, animations non-HTML) dans la page. - Pour chaque lecteur, inspectez ses composants d’interface (boutons Lecture/Pause, barre de progression, volume, sous-titres, plein écran). Vérifiez l’une des deux conditions suivantes :
- Les composants exposent leur nom, rôle, valeur, paramétrage et changements d’état via l’API d’accessibilité. Testez avec un lecteur d’écran : le bouton est-il annoncé comme « bouton » ? Son état change-t-il à l’activation ? Les zones dynamiques (durée, statut) sont-elles restituées ?
- Ou une alternative fonctionnelle compatible avec les technologies d’assistance est disponible et offre les mêmes fonctionnalités que le lecteur original.
- Si chaque média satisfait l’une des deux conditions, le test est validé.
Accessibilité de l'alternative compatible au média
Ce test ne s’applique qu’aux médias dont la conformité au test 4.13.1 repose sur une alternative (pas sur la compatibilité directe du lecteur lui-même).
- Repérez les médias pour lesquels une alternative accessible a été fournie.
- Pour chaque média, vérifiez que l’alternative est joignable selon l’une de ces trois modalités :
- Elle est placée immédiatement avant ou après le média dans le code (adjacente) ;
- Un lien ou un bouton adjacent pointe directement vers elle ;
- Un mécanisme intégré à la page permet de remplacer le lecteur inaccessible par l’alternative accessible.
- Si chaque alternative respecte l’une de ces conditions, le test est validé.
Exemples
❌ Non conforme : Lecteur vidéo avec contrôles en <div> — non accessible
<div class="player">
<video id="ma-video" src="presentation.mp4"></video>
<div class="controls">
<div class="btn-play" onclick="togglePlay()">▶</div>
<div class="progress-bar">
<div class="progress" style="width: 0%"></div>
</div>
<div class="btn-volume" onclick="toggleMute()">🔊</div>
<div class="btn-fs" onclick="toggleFullscreen()">⛶</div>
</div>
</div>Les <div> n’ont ni rôle, ni nom accessible, ni état. Un lecteur d’écran ne voit pas de bouton : il lit du texte brut ou rien. L’utilisateur ne peut ni lancer la vidéo, ni ajuster le volume, ni passer en plein écran. La barre de progression est invisible pour les technologies d’assistance. Pourtant, visuellement, ce lecteur peut sembler parfaitement fonctionnel.
✅ Conforme : Lecteur vidéo avec contrôles accessibles via éléments natifs et ARIA
<div class="player">
<video id="ma-video" src="presentation.mp4"
aria-label="Présentation produit — 3 min 42"></video>
<div class="controls" role="group" aria-label="Contrôles vidéo">
<button id="btn-play"
aria-label="Lecture"
aria-pressed="false"
onclick="togglePlay(this)">
<svg aria-hidden="true" focusable="false"><use href="#icon-play"/></svg>
</button>
<div role="progressbar"
aria-label="Progression de la vidéo"
aria-valuenow="0"
aria-valuemin="0"
aria-valuemax="100"
aria-valuetext="0 seconde sur 3 minutes 42 secondes"
tabindex="0">
</div>
<button id="btn-mute"
aria-label="Couper le son"
aria-pressed="false"
onclick="toggleMute(this)">
<svg aria-hidden="true" focusable="false"><use href="#icon-volume"/></svg>
</button>
</div>
<div aria-live="polite" aria-atomic="true" class="sr-only" id="player-status">
<!-- Mise à jour JS : « Lecture en cours », « Vidéo en pause », « Fin de la vidéo » -->
</div>
</div>Chaque contrôle est un <button> natif : rôle et comportement clavier sont acquis sans ARIA supplémentaire. aria-pressed indique l’état activé/désactivé du bouton bascule. role="progressbar" avec ses attributs aria-value* expose la position courante. La zone aria-live="polite" restitue les changements d’état significatifs sans interrompre la lecture en cours. Un lecteur d’écran annonce « Lecture, bouton non activé », puis « Lecture en cours » après activation.
✅ Conforme : Alternative accessible via bouton adjacent
<div class="media-wrapper">
<!-- Lecteur tiers intégré en iframe, contrôles non accessibles -->
<iframe src="https://lecteur-proprietaire.exemple/embed/42"
title="Webinaire accessibilité numérique"
width="640" height="360"
allowfullscreen></iframe>
<!-- Alternative accessible adjacente -->
<p>
<a href="/webinaire-42/lecteur-accessible">
Accéder au lecteur accessible pour ce webinaire
</a>
</p>
</div>Quand le lecteur tiers ne peut pas être rendu compatible, un lien adjacent vers un lecteur alternatif valide le test 4.13.1 (alternative disponible) et le test 4.13.2 (alternative accessible via un lien adjacent). Le lien doit être immédiatement après le média dans le code — pas enfoui dans le pied de page ou dans une page d’aide.
Astuces et pièges
⚠️ L’attribut controls sur <video> ne dispense pas de vérification
<video controls> délègue les contrôles au navigateur, ce qui est généralement accessible. Mais dès que vous créez vos propres contrôles pour respecter une charte graphique — ce que fait quasi chaque équipe front-end — vous reprenez entièrement la responsabilité de leur accessibilité. C’est là que 90 % des lecteurs vidéo échouent en audit RGAA.
⚠️ aria-label du bouton Lecture ne change pas automatiquement
Erreur fréquente en audit : le bouton conserve aria-label="Lecture" même quand la vidéo est en cours. L’utilisateur de lecteur d’écran n’entend jamais « Pause ». Utilisez soit aria-pressed sur un bouton bascule unique, soit deux boutons distincts affichés alternativement via JavaScript, soit aria-label mis à jour dynamiquement. Les trois approches sont valides ; choisissez selon votre implémentation.
💡 Les zones dynamiques : aria-live avec parcimonie
Le compteur de temps restant (« 02 :47 » mis à jour chaque seconde) ne doit pas porter aria-live : ce serait illisible. Réservez aria-live="polite" aux changements d’état significatifs : début/fin de lecture, mise en pause, activation des sous-titres. La progression reste accessible via role="progressbar" sans annonce automatique.
⚠️ Les médias non temporels ont quasi disparu
Le critère couvre aussi les médias non temporels au sens RGAA : technologies propriétaires comme Flash, Silverlight, visites 3D non-HTML. En 2026, ces formats ne sont plus supportés par les navigateurs modernes. En pratique, ce critère s’applique exclusivement aux lecteurs vidéo et audio avec des contrôles personnalisés. Si vous croisez un plugin propriétaire sur un site patrimonial, appliquez le même raisonnement : API d’accessibilité ou alternative adjacent.
⚠️ Cas particuliers officiels du thème Multimédia
Le critère s’applique « hors cas particuliers ». Les exemptions reconnues par le RGAA incluent les contenus dont la conformité est techniquement impossible à l’état de l’art. Consultez la note officielle sur les cas particuliers du thème 4 avant de conclure à une exemption : le périmètre est strictement défini et ne couvre pas le simple confort de développement.
Questions fréquentes
Dans quelles conditions un <video controls> HTML natif satisfait-il le critère RGAA 4.13 ?
Oui, dans la grande majorité des cas. Les contrôles natifs sont exposés via l’API d’accessibilité du système sans configuration supplémentaire. Testez tout de même avec NVDA + Firefox et VoiceOver + Safari, car certaines combinaisons anciennes présentent des lacunes. L’attribut controls est indispensable : un <video> sans cet attribut n’affiche aucun contrôle et ne peut pas être opéré.
Comment auditer concrètement la compatibilité des médias selon le critère RGAA 4.13 ?
Naviguez au clavier dans le lecteur : chaque contrôle doit être atteignable par Tab et activable par Entrée ou Espace. Activez ensuite un lecteur d’écran (NVDA, VoiceOver, JAWS) et parcourez les contrôles : il doit annoncer le nom, le rôle et l’état de chaque élément, et restituer les changements dynamiques. Complétez avec le panneau Accessibilité des DevTools Chrome pour inspecter l’arbre d’accessibilité de chaque composant.
Comment compenser un lecteur vidéo tiers inaccessible pour satisfaire le critère RGAA 4.13 ?
Sous conditions, oui. Le lien doit être adjacent au lecteur défaillant, clairement identifié, et pointer vers une page où le contenu est accessible. Ce n’est pas une solution universelle : rediriger l’utilisateur hors de la page n’est pas toujours acceptable selon le contexte. Si le lecteur embarqué est central à un parcours utilisateur, une alternative locale est préférable.
Quand le critère RGAA 4.13 s'applique-t-il aux animations CSS ou SVG animées ?
Les animations CSS pures sans contrôle interactif ne sont pas des médias au sens du critère 4.13. En revanche, si une animation embarque des contrôles utilisateur (bouton pause, curseur), ces contrôles entrent dans le périmètre : ils doivent exposer nom, rôle et état via l’API d’accessibilité. Le critère 13.8 sur le contrôle des animations complète ce cadre.