WCAG 2.2 et version audio : ce que le standard exige, et ce qu'il n'exige pas
Les WCAG sont la référence internationale d'accessibilité web, reprise par le RGAA et la norme européenne. Une version audio n'y est pas un critère. Voici où elle croise vraiment le standard, et surtout comment un lecteur mal intégré peut faire baisser une note.
Les WCAG (Web Content Accessibility Guidelines) sont la référence internationale de l'accessibilité web, publiées par le W3C. La version 2.2 date d'octobre 2023, et c'est elle que reprennent le RGAA français en préparation de sa version 5, la norme européenne EN 301 549, et la plupart des cadres nationaux. Autour de la version audio, une confusion revient sans cesse : proposer la lecture de ses articles ferait « gagner des points » d'accessibilité. C'est faux, et le dire clairement évite deux erreurs opposées. Voici où une version audio croise réellement les WCAG, et où elle ne les croise pas du tout.
Trois niveaux, une logique de critères
Les WCAG sont organisées en critères de succès, chacun rattaché à un niveau : A (le socle), AA (le niveau visé par la plupart des réglementations, dont l'European Accessibility Act et la directive secteur public), et AAA (un niveau exigeant, rarement imposé à un site entier). La conformité se mesure critère par critère sur des pages réelles, pas à l'impression générale. Cette mécanique du taux et de l'échantillon, nous l'avons détaillée du côté français dans notre article sur le RGAA et le calcul d'un taux de conformité : elle vaut, dans son principe, pour les WCAG dont le RGAA dérive.
La version 2.2 a ajouté neuf critères par rapport à la 2.1, surtout autour de la navigation, du focus et de l'authentification (par exemple la taille des cibles, l'aide cohérente, ou l'authentification accessible), et retiré un ancien critère devenu inutile. Aucun de ces ajouts ne concerne la lecture audio d'un contenu. C'est un premier indice : le standard ne se préoccupe pas de savoir si vos articles sont écoutables, il se préoccupe de savoir si votre site est utilisable avec les outils d'assistance.
Le seul critère qui parle d'audio, et pourquoi il ne vous coûte rien
Un critère mentionne bien l'audio : le 1.2.1, « Contenu seulement audio et seulement vidéo (préenregistré) », de niveau A. Il demande qu'un contenu uniquement sonore soit accompagné d'une alternative textuelle qui en restitue l'information. Or une version audio d'article se trouve dans la situation inverse la plus confortable qui soit : l'alternative textuelle, c'est l'article lui-même, présent sur la page. Le texte est la source, l'audio en est le rendu parlé. Le critère 1.2.1 est donc satisfait par construction, sans effort supplémentaire, à condition que le texte reste bien présent et lisible à côté du lecteur.
Ce point mérite d'être compris dans le bon sens : votre version audio n'a pas besoin d'une transcription, puisqu'elle est déjà la lecture d'un texte affiché. C'est exactement pour cette raison qu'elle ne fait pas non plus monter une note : elle ne comble aucun manque, elle double un contenu déjà accessible sur le plan textuel.
Où l'audio aide vraiment, au-delà du standard
Si l'audio ne coche pas de case, à quoi sert-il en accessibilité ? À atteindre des publics que la grille de critères ne couvre pas. Les personnes dyslexiques, pour qui le décodage est coûteux alors que la compréhension orale est intacte, sujet que nous traitons à part dans l'audio et la dyslexie. Les personnes âgées dont la vue baisse sans qu'un outil d'assistance soit adapté. Les personnes en situation d'illettrisme, qu'aucun critère technique ne mentionne. Les personnes dont le français n'est pas la langue première. Aucune de ces situations n'apparaît telle quelle dans les WCAG, et toutes apparaissent dans la population qu'un site public ou un titre de presse est censé servir. C'est un registre complémentaire, pas un registre de conformité, et c'est déjà beaucoup.
Il faut aussi éviter un contresens fréquent : une version audio ne remplace pas un lecteur d'écran. Les deux répondent à des besoins différents, et nous avons consacré un article entier à cette distinction, version audio ou lecteur d'écran.
Le vrai risque : un lecteur qui casse des critères
Voici le point que l'enthousiasme fait souvent oublier. L'audio n'améliore pas votre note, mais un lecteur mal intégré peut la dégrader, et sur des critères de niveau A, les plus graves. Trois pièges reviennent.
Le premier est le clavier (critère 2.1.1, niveau A) : les boutons lecture, pause et la barre de progression doivent être atteignables et actionnables sans souris. Un lecteur piloté uniquement à la souris exclut une partie du public et fait tomber ce critère.
Le deuxième est le nom accessible des contrôles (critère 4.1.2, niveau A) : un bouton sans intitulé lisible par un lecteur d'écran est annoncé « bouton », sans plus. Chaque contrôle du lecteur doit porter un nom explicite.
Le troisième est la lecture automatique (critère 2.2.2, niveau A) : un audio qui démarre seul et ne s'arrête pas facilement est un problème d'accessibilité caractérisé. Le bon comportement est simple : la lecture ne démarre jamais toute seule.
À ces trois-là s'ajoute le contraste (critère 1.4.3, niveau AA) des icônes et du texte du lecteur, souvent négligé parce que le composant est petit.
L'ordre de travail qui tient
La conformité d'abord, parce qu'elle est obligatoire : rendre le site utilisable au clavier et avec un lecteur d'écran, corriger les critères bloquants avant les critères cosmétiques, publier une déclaration d'accessibilité datée. Si une version audio est en place, mentionnez-la comme une mesure complémentaire et jamais comme une mesure de conformité, la déclaration d'accessibilité a ses règles propres sur ce point. Et vérifiez le lecteur lui-même au moment de l'intégration, pas au moment de l'audit.
Chez WeDispatch, le lecteur et la transcription sont rendus dans la page, sur votre domaine, avec des contrôles atteignables au clavier et une lecture qui ne démarre jamais seule : les choix d'intégration sont décrits sur la page accessibilité. La qualité de lecture du français, elle, relève d'un autre travail, celui que nous détaillons sur la page text to speech français. Pour juger sur pièces, écoutez le résultat sur un de vos propres contenus.
Sources : WCAG 2.2, W3C, Understanding WCAG 2.2, W3C.
Sonorisez vos articles avec WeDispatch
Ce blog sera lui-même sonorisé par WeDispatch. Envie de voir ce que ça donne sur vos contenus ?
Demandez une démo