Une vidéo diffuse des informations visuelles et sonores qui échappent à certains publics. Pour y remédier, alignez votre démarche sur l’accessibilité vidéo et fournissez une alternative textuelle pertinente, testée, mesurable.
Les contraintes techniques des lecteurs et des navigateurs imposent des solutions combinées, pas une recette unique. Visez un equivalent balise alt crédible, via descriptions, transcriptions et sous-titres coordonnés. Ancrez vos choix dans des bonnes pratiques html documentées et une conformité wcag vérifiable par tests réels, sinon l’expérience s’effondre.
Pourquoi l’attribut alt n’existe pas pour l’élément video en HTML ?
Le HTML traite différemment les médias statiques et temporels, car une vidéo possède une durée, des pistes et des états. Par contraste, l’attribut alt cible une image qui ne change pas pendant l’affichage. C’est ce décalage technique qui a guidé la spécification vers d’autres mécanismes.
Au-delà de l’image fixe, une vidéo mêle son, mouvement et texte incrusté, d’où une vraie complexité multimédia. Résumer un tel contenu audiovisuel en un court libellé serait trompeur, voire réducteur. Les pistes <track> (sous-titres, descriptions), les attributs ARIA et les transcriptions répondent mieux aux limites de l’attribut alt, car ils couvrent les dialogues, l’action et la chronologie avec précision.
Quand fournir une alternative textuelle à une vidéo ?
Un texte est utile lorsque la vidéo ne peut pas être vue ou entendue, temporairement ou durablement. Il doit refléter le contexte d’usage et s’aligner sur les besoins utilisateurs, afin de préserver les informations essentielles. Voici des situations courantes où une alternative s’impose :
- Lecture en sourdine ou bruit ambiant élevé
- Utilisation d’un lecteur d’écran
- Connexion limitée ou interdiction d’autoplay
- Visionnage en formation ou support technique
Les obligations diffèrent selon les juridictions, mais l’accessibilité légale encadre la diffusion de médias et favorise une expérience inclusive pour tous les publics.
Prévoyez a minima des sous-titres et une transcription, puis ajoutez une description quand l’image apporte du sens.
Fournir une courte description avec ARIA : aria-label et aria-labelledby
Pour donner un libellé court à une vidéo, vous pouvez nommer l’élément <video> ou un bouton Play personnalisé via ARIA. Cette méthode rend l’élément identifiable et facilite la navigation clavier pour tous. Elle doit rester concise, factuelle, et refléter la finalité de la vidéo, par exemple le sujet, la date, ou la source éditoriale dans son libellé court.
Pour un repère efficace, combinez des libellés courts avec des éléments visibles proches. Ajoutez un attribut aria-label sur le composant de contrôle, ou reliez un titre voisin via une association aria-labelledby robuste. Dans tous les cas, visez un nom accessible clair qui reste cohérent entre les vues. Vous améliorerez la découverte et la lecture par lecteur d’écran lors du focus, du survol et des annonces de boutons.
Lier une description détaillée avec aria-describedby
Certaines vidéos transmettent des informations que l’audio seul ne couvre pas, comme des schémas animés ou des gestes clés. Dans ces cas, liez la vidéo à un bloc de texte détaillé grâce à aria-describedby, pour offrir un contexte lisible. Ce bloc sert de texte associé aux technologies d’assistance et complète les sous-titres.
Placez ce contenu près de la vidéo ou dans une section dédiée, avec un lien d’ancrage clair. Structurez une description enrichie avec des titres, listes et minutage pour permettre une consultation rapide. Si le texte est long, vous pouvez pointer une référence externe interne à la page, contenant un contenu descriptif mis à jour, puis référencer son identifiant via l’attribut ARIA.
Tirer parti du contenu de remplacement dans la balise video
Le contenu de remplacement à l’intérieur de <video> sert d’ancre quand le média échoue ou n’est pas supporté. Il peut afficher une description courte, une image ou des commandes HTML. Intégrez, au besoin, un lecteur de secours ou un message de disponibilité. Cette approche améliore la compatibilité des navigateurs et garde du sens, même sans flux multimédia. Elle complète le concept de fallback HTML pour vos contenus.
Pour un meilleur repérage, ajoutez un paragraphe alternatif décrivant l’objectif de la séquence et les actions clés. Proposez aussi un lien vers la transcription afin d’accéder au texte des dialogues, des descriptions et des métadonnées. En cas d’erreur de codec, remplacez la vidéo par un lien de téléchargement, ou par une version plus légère qui démarre sur mobile.
Sous-titres et transcription : le socle d’accessibilité pour la vidéo en ligne
Des pistes sous-titrées et une version textuelle forment la base d’une vidéo inclusive. Après l’encodage, fournissez des sous-titres synchronisés lisibles et bien contrastés. Pour cadrer le travail, utilisez cette checklist minimale :
- Fichier VTT ou SRT valide
- Positionnement qui évite d’occulter l’action
- Respect de la casse et de la ponctuation
- Horodatage précis et révisions éditoriales
Une page de texte fournit une transcription complète avec dialogues, descriptions visuelles et repères. Pensez à l’identification des locuteurs et aux bruitages pertinents pour clarifier l’action hors champ. Ce duo sous-titres + transcription améliore l’indexation, la révision et l’accessibilité audio pour tous les publics, y compris ceux qui consultent sans son ou avec des appareils d’assistance.
Audiodescription et pistes de description : quand et comment les utiliser
Certaines vidéos transmettent des éléments clés par l’image seule : actions silencieuses, textes en surimpression, schémas, transitions significatives. Dans ces cas, le public non voyant perd une partie du récit. Pour y remédier, prévoyez soit une audiodescription intégrée au fichier final, soit une piste de description distincte, afin de verbaliser les informations visuelles qui ne sont pas couvertes par les dialogues.
Sur le web, reliez un fichier WebVTT via <track kind="descriptions" srclang="fr"> et cadencez les segments entre les répliques. Une voix neutre, des phrases courtes et des verbes précis aident la compréhension non visuelle sans écraser le mixage sonore. Pour les œuvres d’action, proposez une version “AD” dédiée quand les silences sont trop rares pour placer une narration claire.
Astuce : s’il n’y a pas d’espace pour décrire, publiez une seconde version avec pauses allongées et description synchronisée.
Lecteurs vidéo accessibles et contrôles clavier : ce qu’il faut proposer
Un bon lecteur doit fonctionner sans souris, avec un ordre de tabulation cohérent et un focus visible. Dès la conception, testez la navigation au clavier pour lecture, pause, volume, sous-titres et plein écran, puis vérifiez la compatibilité lecteurs d’écran (NVDA, JAWS, VoiceOver) en exposant des contrôles accessibles dotés d’intitulés ARIA clairs et d’états annoncés correctement.
Documentez des raccourcis lecteurs pour jouer/mettre en pause, avancer, reculer, couper le son et régler la vitesse. Pour un socle pérenne, privilégiez des lecteurs open source maintenus, auditables et extensibles, capables de charger des sous-titres VTT, des chapitres et des pistes de descriptions, tout en restant performants sur mobile et desktop.
| Lecteur | Licence | Raccourcis clavier | Sous-titres (VTT) | Pistes descriptions | Vitesse variable | Focus visible | Annonces ARIA | Observations |
|---|---|---|---|---|---|---|---|---|
| Able Player | MIT | Oui | Oui | Oui (track descriptions) | Oui | Oui | Oui (états et rôles) | Très complet pour accessibilité web |
| Video.js | Apache-2.0 | Oui (plugins) | Oui | Selon plugin/navigateur | Oui | Personnalisable | Variable selon thèmes | Écosystème large d’extensions |
| Plyr | MIT | Oui | Oui | Dépend du support natif | Oui | Oui | Bonne | Léger, intégration simple |
Attribut poster : image d’aperçu et texte associé
L’attribut poster affiche une image avant lecture, sans fournir de texte lisible par un lecteur d’écran. Pour nommer le média, associez un titre clair via aria-label sur video ou placez une légende adjacente. Si l’image d’aperçu de la vidéo porte une information, expliquez-la brièvement pour situer le contexte visuel du contenu. Un exemple concret : « Démonstration de l’application X, écran d’accueil avec boutons Profil et Rechercher », ce qui donne un repère rapide aux personnes non-voyantes.
Évitez d’attribuer un alt directement au poster, car il n’est pas exposé comme image autonome. Préférez un texte alternatif de l’image à proximité, ou un libellé ARIA sur le lecteur. Pour les contrôles personnalisés, nommez le bouton Play afin de guider le lancement de la lecture par clavier et lecteurs d’écran, y compris sur mobile et TV.
Gérer les vidéos décoratives : role= »presentation » et aria-hidden
Une vidéo d’arrière-plan peut être purement esthétique. Dans ce cas, signalez-la comme contenu décoratif pour qu’elle reste silencieuse côté accessibilité. Combinez le rôle presentation et aria-hidden="true" sur la balise video, en ajoutant muted et playsinline si elle démarre en silence, afin d’éviter des contrôles superflus pour les aides techniques.
Ne laissez pas le focus capturer un élément caché : supprimez les contrôles natifs et gérez le masquage aria-hidden sur tout wrapper interactif. Offrez un mécanisme Pause quand le mouvement peut distraire, ce qui favorise la réduction du bruit visuel et auditif. Tenez compte de prefers-reduced-motion pour couper l’animation de manière respectueuse des préférences.
Se conformer aux critères WCAG 2.2 pour la vidéo
WCAG 2.2 encadre la vidéo en imposant alternatives textuelles, pistes et contrôles utilisables au clavier. Les critères 1.2 couvrent les médias synchronisés, avec des obligations graduées selon le niveau aa pour les sites grand public. Préparez des sous-titres synchronisés, alignés sur les exigences sous-titres, y compris bruits pertinents et changements d’interlocuteur.
Quand des informations ne passent que par l’image, ajoutez une piste dédiée ; cela répond aux exigences audiodescription et facilite la compréhension. Pour les organismes soumis à la loi accessibilité, alignez vos procédures, politiques et contrats avec la conformité réglementaire, en documentant les responsabilités d’édition, les délais de mise en ligne et la vérification qualité.
Tests avec lecteurs d’écran et pièges de compatibilité à anticiper
Élaborez un plan de test couvrant clavier, focus visible et annonces vocales sur plusieurs systèmes. Programmez des sessions avec tests nvda jaws et validez VoiceOver sur macOS pour comparer la restitution des contrôles média. Prenez en compte la variabilité navigateur qui modifie la lecture des boutons, des curseurs de volume et de la barre de progression.
Vérifiez l’ordre de tabulation, les états des boutons Lecture/Pause et la présence d’étiquettes pour chaque contrôle. Uniformisez les libellés accessibles entre l’icône, le titre et l’annonce du lecteur, afin d’éviter des malentendus. Tenez un journal des problèmes d’implémentation par version, puis corrigez via ARIA, DOM plus simple et fallbacks sans script.
FAQ à propos de l’équivalent de la balise alt pour video en HTML
Non. L’élément video ne possède pas d’attribut alt natif, à la différence des images. Pour obtenir un équivalent balise alt sur les videos, on utilise principalement aria-label ou aria-describedby, un contenu de remplacement à l’intérieur de la balise video, ainsi que des sous-titres et une transcription. Cette combinaison couvre les besoins des lecteurs d’écran et des utilisateurs sans son. On parle alors de balise alt video html par extension, via ARIA et contenus associés.
Le trio le plus fiable réunit aria-label pour une courte description, aria-describedby pour pointer vers une description détaillée ou une transcription, et un paragraphe de remplacement entre les balises video. Des tests relèvent des écarts selon les lecteurs d’écran, d’où l’intérêt de combiner ces approches avec des pistes de sous-titres. Ainsi, un utilisateur obtient une identification claire de la vidéo, puis un accès à un contenu textuel complet si besoin.
Visez une phrase concise qui résume l’objet et l’action principale de la vidéo, par exemple le sujet, la démonstration et le public visé. Évitez les détails superflus et gardez les précisions (chapitres, données chiffrées, scènes clés) dans une description liée via aria-describedby ou une page de transcription. Mentionner durée et langue peut aider. Objectif : permettre à un lecteur d’écran d’annoncer rapidement de quoi traite la vidéo.
Pour des vidéos préenregistrées, fournissez des sous-titres synchronisés pour tout l’audio pertinent, une transcription complète et, quand l’image apporte une information non dite, une audiodescription. Cette base répond aux exigences de niveaux A et AA sur les alternatives temporelles. Reliez la transcription via un lien proche du lecteur ou aria-describedby. Cette approche améliore aussi l’expérience mobile, l’indexation sémantique et la réutilisation du contenu, en plus de la conformité.
Marquez la vidéo comme décorative avec role=presentation et aria-hidden=true. Utilisez muted et loop pour éviter les surprises sonores, et retirez-la de l’ordre de tabulation. Respectez les préférences de mouvement réduit via prefers-reduced-motion en offrant un arrêt automatique ou un visuel statique. Fournir un contrôle Pause dans l’interface aide les personnes sensibles au mouvement. Aucune description ARIA n’est requise si la vidéo n’apporte pas d’information.
Le poster sert d’aperçu visuel, mais ne dispose pas d’un alt propre au sein de la balise video. Pour une annonce adaptée aux lecteurs d’écran, ajoutez un aria-label au lecteur vidéo décrivant le contenu et l’action attendue, par exemple Aperçu de… appuyer pour lancer la vidéo. Si l’aperçu est utilisé ailleurs comme image, prévoyez un alt pour cette instance. Évitez de dupliquer des textes trop longs dans le label.