WCAG A Prestataire Complexe

Les vidéos et éléments multimédias du site fonctionnent-ils correctement avec les logiciels utilisés par les personnes handicapées ?

Critère officiel 4.13 — Chaque média temporel et non temporel est-il compatible avec les technologies d’assistance (hors cas particuliers) ?

Pourquoi c'est important

Certains lecteurs vidéo ou éléments multimédias sont techniquement inaccessibles aux logiciels de lecture d'écran : les commandes ne sont pas annoncées, la progression n'est pas communiquée, ou le contenu est totalement ignoré. La personne aveugle ne sait même pas qu'un média est présent sur la page.

Exemples concrets

Ce qui est conforme

Le lecteur vidéo utilisé sur le site annonce correctement son état au logiciel de lecture : « Vidéo : Séance du conseil municipal — En pause — Durée : 1h23 ». L'utilisateur peut interagir avec les commandes sans confusion.

Ce qui pose problème

Le lecteur vidéo custom intégré par le prestataire n'est pas annoncé par le logiciel de lecture. Celui-ci ignore complètement le lecteur et passe au contenu suivant — l'utilisateur aveugle ne sait même pas qu'une vidéo est disponible.

Comment agir

Pour les vidéos, privilégiez les lecteurs reconnus pour leur accessibilité : le lecteur YouTube natif, le lecteur HTML5 du navigateur, ou des lecteurs open source comme Plyr ou Video.js correctement configurés. Évitez les lecteurs custom sans garantie d'accessibilité. Si vous avez un doute, demandez à votre prestataire de tester avec NVDA (Windows) ou VoiceOver (Mac).

Règles clés

  • Le lecteur natif HTML5 est compatible AT par défaut — à privilégier.
  • Pour lecteurs custom : chaque contrôle doit avoir le bon rôle (button, slider), un nom accessible, et un état (aria-pressed pour play/pause).
  • Tester avec NVDA+Firefox et VoiceOver+Safari.

Erreurs fréquentes

  • Bouton play sans aria-label ni texte visible — annoncé 'bouton' vide
  • Barre de progression sans role='slider' ni aria-valuenow/min/max
  • Indicateur de temps sans valeur accessible

Exemples de code

contrôles sans noms accessibles

✗ Non conforme
<button>▶</button>
<button>⏸</button>
<input type="range">

Icônes sans nom. Le lecteur d'écran annonce 'bouton' vide. Le range sans aria-label est inutilisable.

contrôles accessibles aux AT

✓ Conforme
<div role="group" aria-label="Contrôles de lecture">
  <button type="button"
    aria-label="Lecture" aria-pressed="false">
    <svg aria-hidden="true"><!-- ▶ --></svg>
  </button>
  <input type="range"
    aria-label="Progression"
    aria-valuenow="0"
    aria-valuemin="0"
    aria-valuemax="100"
    aria-valuetext="0 s sur 3 min 24">
</div>

Chaque contrôle a un nom (aria-label) et le bon rôle. aria-pressed communique l'état. aria-valuetext donne une valeur humainement compréhensible.

Référence WCAG : 4.1.2

La lettre de l'Atelier A11Y

Ressources pédagogiques, critères RGAA commentés et retours de terrain : une lettre mensuelle pour progresser sur l'accessibilité numérique, sans jargon.

  • Nouveaux articles et ressources pédagogiques
  • Critères RGAA décortiqués avec des exemples concrets
  • Bonnes pratiques et retours d'expérience terrain
S'abonner à la newsletter (s'ouvre dans un nouvel onglet)

Gratuit. Désabonnement possible à tout moment.