Dans le premier article de cette rubrique, j'ai raconté comment une question m'était tombée dessus en produisant un podcast sur la santé mentale au travail : quelqu'un qui n'entend pas, il en fait quoi, sans transcription ?

Je n'y avais pas répondu. Voici la réponse, et elle est plus courte qu'on ne croit.

Ce que la norme exige vraiment

Un podcast, au sens du RGAA, est un média temporel pré-enregistré. Il relève de la thématique 4, et l'essentiel tient en un critère.

Le critère 4.1 demande une transcription textuelle. Pas un résumé, pas les « points clés » : le contenu de ce qui est dit, dans l'ordre où c'est dit. Le critère 4.2 ajoute qu'elle doit être pertinente, c'est-à-dire complète, avec l'identification des locuteurs et la mention des éléments sonores qui portent du sens. Un rire, un silence, une musique qui annonce une rubrique : si ça informe l'auditeur, ça doit figurer dans la transcription.

Trois autres critères passent inaperçus et tombent pourtant à chaque audit.

  • 4.7 : le média doit être clairement identifiable. Un lecteur audio noyé dans une page, sans titre ni indication de ce qu'il contient, échoue.
  • 4.10 : aucun son ne se déclenche tout seul sans contrôle. L'autoplay reste une plaie sur les sites de radios.
  • 4.11 : la consultation doit être contrôlable au clavier et au pointeur comme la souris. Lecture, pause, volume, déplacement dans la piste. C'est là que la majorité des lecteurs personnalisés s'effondrent : ils sont beaux, ils sont pilotables à la souris, et la barre de progression n'est atteignable par aucune touche.

Et 4.13 : le tout doit rester compatible avec les technologies d'assistance.

Voilà la conformité. C'est faisable en une après-midi pour une association.

Ce que la norme n'exige pas, et qui change tout

Le chapitrage ne figure dans aucun critère.

Il est pourtant ce qui sépare un podcast consultable d'un podcast qu'on subit. Une transcription de quarante minutes sans repères, c'est un mur de texte. Avec des chapitres horodatés, elle devient un document dans lequel on navigue : on retrouve l'intervention qu'on cherchait, on saute la chronique qui ne nous intéresse pas, on revient sur une phrase.

Qui en a besoin ? Une personne qui navigue au clavier et n'a pas envie de traverser quarante minutes pour atteindre la dernière rubrique. Une personne avec des troubles de l'attention, pour qui un contenu long sans structure est un contenu inaccessible. Et tout le monde, en réalité — c'est la définition même d'une bonne conception.

C'est exactement la frontière dont je parlais dans « Conforme, oui. Utilisable par tout le monde, vraiment ? ». Le chapitrage est hors norme et indispensable.

Le lecteur, angle mort du podcast

Un dernier point, appris en regardant des sites de radios associatives, la nôtre comprise.

La plupart des plateformes d'hébergement fournissent un lecteur intégrable. Certains sont corrects, d'autres sont des catastrophes clavier. Avant d'en choisir un, deux tests de trente secondes : parcourez-le à la touche Tab pour voir si chaque commande est atteignable et annoncée, puis essayez de vous déplacer dans la piste sans souris. Si vous n'y arrivez pas, votre auditeur non plus.

Un lecteur HTML natif, avec l'élément audio et ses contrôles par défaut, échoue rarement à ces deux tests. Ce n'est pas le plus élégant. Il fonctionne.

Ce que ça donne concrètement

Pour une radio associative comme la nôtre, le programme tient en trois lignes : une transcription par émission, des chapitres horodatés, un lecteur testé au clavier.

Aucune de ces trois choses ne demande de budget. Elles demandent qu'on décide de les faire — et c'est bien là que ça coince, dans les radios comme dans les grandes organisations.