Transcriptions pour les utilisateurs de lecteurs d'écran : une mise en forme qui fonctionne

Comment les lecteurs d'écran lisent les transcriptions

L'accessibilité d'une transcription dépend entièrement de sa structure sémantique. Les lecteurs d'écran n'affichent pas les pages visuellement ; ils analysent le HTML sous-jacent et le restituent sous forme de sortie audio ou braille. Un utilisateur aveugle parcourant une transcription de 5 000 mots peut sauter de titre en titre, avancer paragraphe par paragraphe, rechercher du texte ou lire séquentiellement. La rapidité de chacun de ces modes dépend entièrement de la façon dont la transcription a été mise en forme.

Sous-titres et transcriptions sont des outils différents destinés à des utilisateurs différents. Selon la WCAG 1.2.2 (niveau A), les sous-titres sont requis pour la vidéo synchronisée, car ils s'affichent à l'écran en synchronisation avec l'audio. Selon la WCAG 1.2.1 (niveau A), une transcription est requise pour le contenu purement audio préenregistré, car les utilisateurs aveugles ne voient pas le lecteur vidéo et ne peuvent pas bénéficier de sous-titres synchronisés. Pour en savoir plus sur ces distinctions, consultez transcription, sous-titrage et sous-titres.

En pratique : si vous publiez un épisode de podcast, un cours enregistré ou une interview, votre transcription constitue le principal chemin d'accès pour les auditeurs aveugles ou malvoyants. Sa structure est l'interface.

Ce que les utilisateurs de lecteurs d'écran peuvent faire avec une transcription

Un utilisateur de lecteur d'écran dispose de plusieurs modes de navigation :

• Saut par titre : afficher la liste de tous les titres et accéder directement à une section (rapide, le mode privilégié pour les contenus longs)
• Saut de paragraphe : passer au paragraphe suivant à vitesse moyenne
• Saut de phrase : avancer phrase par phrase pour une lecture précise
• Recherche de texte : accéder directement à un mot-clé ou à une expression
• Lecture séquentielle : écouter du début à la fin (lente, utilisée en l'absence de structure)

Pour une transcription d'interview de 90 minutes, la navigation par titres fait toute la différence entre trouver une section en quelques secondes et passer des minutes à écouter le contenu. La présentation visuelle peut prendre n'importe quelle forme. Ce qui compte, c'est la structure sémantique sous-jacente.

Les schémas de mise en forme qui fonctionnent

Utiliser une véritable hiérarchie de titres

Les titres offrent aux utilisateurs de lecteurs d'écran une carte du document. Pour une transcription de podcast ou d'interview :

• H1 : titre de l'épisode ou de l'interview (sur la page, pas dans le corps de la transcription)
• H2 : grandes sections (introduction, sujet principal, questions-réponses, conclusion)
• H3 : sous-sections au sein des grandes sections, si le contenu le justifie

Pour une réunion ou un cours :

• H2 : points de l'ordre du jour ou sections du cours dans l'ordre
• H3 : changements de sujet au sein d'une section, s'ils sont substantiels

Un titre libellé avec le sujet (« Discussion du modèle tarifaire ») permet à l'utilisateur de décider s'il souhaite lire cette section. Un titre libellé uniquement avec un horodatage (« 00:15:30 ») ne fournit aucun contexte avant que l'utilisateur n'y soit déjà arrivé.

Des étiquettes de locuteur en texte à chaque changement

Pour les contenus à plusieurs locuteurs, chaque changement de locuteur nécessite une étiquette textuelle visible. Le schéma qui fonctionne :

**Sarah:** I think we should focus on the second option.

**David:** Agreed, the timeline works better.

**Sarah:** And it costs less in the long run.

Le style gras aide les lecteurs visuels à balayer rapidement. Le nom du locuteur suivi de deux points donne à l'utilisateur du lecteur d'écran l'attribution avant le contenu : « Sarah, I think we should focus… ». Les indices visuels comme l'indentation ou la couleur ne se transfèrent pas à l'audio. Les étiquettes textuelles, si.

Des sauts de paragraphe aux points naturels

Un mur de texte est difficile pour tout le monde, mais pour un utilisateur de lecteur d'écran qui avance paragraphe par paragraphe, un bloc de 600 mots sans coupures signifie écouter tout le bloc pour trouver une seule phrase. Coupez les paragraphes :

• Aux changements de sujet dans le propos d'un même locuteur
• Tous les 100 à 150 mots pour les longs monologues
• Aux pauses naturelles du discours de trois secondes ou plus

Chaque paragraphe doit former une unité cohérente en soi.

Des repères temporels pour la navigation

Pour les transcriptions de plus d'environ 20 minutes, des horodatages périodiques aident les utilisateurs à trouver des moments précis. Intégrez-les dans le texte, avant le passage concerné :

**[00:15:30]** And then we got to the question of pricing...

L'horodatage entre crochets est annoncé par le lecteur d'écran et fournit un point de repère sans rompre le flux de lecture. Pour une transcription de 90 minutes, un repère toutes les cinq à dix minutes convient.

Les sons non verbaux entre crochets

Les sons qui affectent la compréhension ont leur place dans la transcription :

• [Rires du public]
• [La musique de fond s'estompe]
• [Une porte claque]

Ils sont encore plus critiques dans les sous-titres, où ils doivent être synchronisés avec la vidéo. Dans une transcription autonome, ils apportent du contexte aux utilisateurs qui n'ont jamais entendu l'audio.

Épeler les acronymes à la première occurrence

Les lecteurs d'écran lisent souvent les acronymes peu familiers lettre par lettre. « GDPR » sur un lecteur d'écran bien configuré peut sortir sous la forme « G-D-P-R ». « Equal Employment Opportunity Commission (EEOC) » à la première occurrence, puis « EEOC » ensuite, donne à l'utilisateur la forme complète avant que l'abréviation n'apparaisse. Les acronymes courants comme NASA ou FBI sont généralement gérés correctement ; ceux propres à un domaine constituent le risque.

Une ponctuation standard uniquement

Les lecteurs d'écran modernes gèrent correctement les points, les virgules et les points d'interrogation. Ce qui pose problème :

• Les points de suspension excessifs, qui créent des pauses maladroites
• LES MAJUSCULES, lues lettre par lettre sur certains lecteurs d'écran
• Les caractères Unicode décoratifs, dont la prononciation peut manquer de cohérence
• Les guillemets typographiques dans certaines configurations de lecture plus anciennes

Gardez une ponctuation standard et fonctionnelle.

Les schémas qui échouent

Les murs de texte sans locuteurs identifiés sont inaccessibles en pratique. Un bloc de 3 000 mots sans étiquettes de locuteur ni sauts de paragraphe impose une lecture séquentielle sans aucune option de navigation.

Des titres comme seule structure, c'est mieux que rien, mais si chaque H2 couvre 800 mots sans coupures de paragraphe internes, l'utilisateur peut accéder à une section, puis doit tout écouter.

La diffusion en PDF seul est un piège fréquent. L'export en PDF depuis Word ou une page web supprime généralement la structure de balises sémantiques, même lorsque la mise en page visuelle semble correcte. La navigation par titres disparaît. Pour l'accessibilité aux lecteurs d'écran, le HTML sur une page web est le format le plus fiable.

Les commentaires éditoriaux en incise perturbent le flux de lecture séquentielle. Si vous devez ajouter du contexte (« [note : cette section a été coupée faute de temps] »), placez-le dans une remarque ou une note de bas de page clairement identifiée, pas en incise dans le texte du locuteur.

Les titres réduits à un horodatage (« 00:15:30 ») n'ont aucune valeur de navigation. Associez l'horodatage au sujet.

Le contenu multilingue sans balisage de langue est un échec spécifique auquel les lecteurs d'écran ne peuvent rien. Si une transcription inclut des passages en espagnol dans un document en anglais, le lecteur d'écran a besoin d'un attribut lang pour basculer les règles de prononciation. La WCAG 3.1.2 (niveau AA) exige l'identification de la langue pour chaque passage ou expression dans une langue différente de celle par défaut de la page. Sans cela, le texte espagnol est lu avec une phonétique anglaise.

Flux de travail : de la transcription IA au document accessible

À partir d'une transcription générée par IA via l'outil audio vers texte :

Étape 1 : Relecture initiale. Lisez la transcription en écoutant l'audio. Vérifiez l'exactitude et repérez les principaux changements de sujet qui devraient devenir des titres H2.

Étape 2 : Ajouter la structure de titres. Insérez des titres H2 aux principaux changements de sujet. Pour une interview de 60 minutes, cinq à quinze titres constituent une fourchette raisonnable. Nommez chaque titre avec le sujet.

Étape 3 : Vérifier les étiquettes de locuteur. La diarisation par IA est généralement exacte dans 80 à 90 % des cas, mais vérifiez : les chevauchements de parole où les deux locuteurs ont été fusionnés en un seul, les échanges rapides que l'IA a regroupés, et les répliques attribuées à tort.

Étape 4 : Couper les paragraphes. Scindez les longs monologues aux points naturels. Visez des paragraphes de 100 à 200 mots.

Étape 5 : Ajouter des repères temporels. Insérez des horodatages toutes les cinq à dix minutes pour faciliter la navigation.

Étape 6 : Signaler les sons non verbaux. Pour un audio narratif, ajoutez des descriptions sonores entre crochets aux moments pertinents. Pour un dialogue pur (réunions, interviews), c'est généralement inutile.

Étape 7 : Ajouter le balisage de langue. Si une section est dans une autre langue, encapsulez-la dans un attribut lang en HTML, ou signalez explicitement la langue dans les formats texte brut.

Étape 8 : Valider avec un lecteur d'écran. NVDA (gratuit, open source, Windows) et VoiceOver (intégré à macOS et iOS) sont les deux outils les plus pratiques pour cela. Parcourez la transcription au clavier uniquement. Vérifiez que la navigation par titres passe bien d'une grande section à l'autre, que la navigation par paragraphe progresse proprement et que les étiquettes de locuteur sont annoncées avant le texte.

Cette étape de validation détecte des problèmes qu'une relecture visuelle laisse passer.

Où publier la transcription

Pour les plateformes qui suppriment la mise en forme (certains hébergeurs de podcasts, certaines plateformes de formation), publiez la version HTML sur votre propre site et créez un lien vers elle.

Emplacement sur la page

Placez la transcription sur la même page que l'audio, et non derrière un lien séparé. Un utilisateur qui arrive sur votre page d'épisode doit pouvoir faire défiler (ou sauter via les titres) jusqu'à la transcription sans ouvrir une nouvelle URL. Si la transcription est longue, un lien d'évitement en haut du lecteur (« Aller à la transcription ») allège la charge de navigation.

Pour le contenu vidéo, transcriptions et sous-titres servent des utilisateurs différents et les deux peuvent être nécessaires. La transcription a sa place en tant que texte sur la page. Les sous-titres ont leur place en tant que fichier synchronisé sur le lecteur vidéo. Ni l'un ni l'autre ne remplace l'autre. Consultez la transcription pour les personnes sourdes et malentendantes pour une vue d'ensemble des formats répondant à quels besoins d'accès.

Longueur et structure selon le type de contenu

Moins de 15 minutes d'audio : une seule section de prose sans sous-titres est acceptable. Les étiquettes de locuteur et les sauts de paragraphe restent importants.

15 à 60 minutes : des titres H2 toutes les cinq à quinze minutes. Cinq à dix titres pour une interview typique.

60 à 180 minutes : des titres hiérarchisés, H2 pour les grandes sections et H3 pour les changements de sujet au sein des sections.

Contenu multi-sessions ou de plusieurs heures : envisagez de le diviser en pages de transcription distinctes par session ou par sujet. L'objectif de navigation : que n'importe quel utilisateur puisse trouver n'importe quel moment en environ 30 secondes.

Pour le contenu éducatif, les cours accessibles avec transcriptions explique comment la structure de la transcription s'intègre aux plateformes de formation. Pour une vision plus large de la conformité, la conformité WCAG avec les transcriptions détaille quels critères de succès s'appliquent à quels types de médias.

Une liste de contrôle d'accessibilité rapide

Avant de publier une transcription, vérifiez :

1. Un utilisateur de lecteur d'écran peut-il identifier le locuteur à n'importe quel endroit du texte ?
2. Peut-il accéder à une section précise grâce à la navigation par titres ?
3. Peut-il parcourir le contenu paragraphe par paragraphe ?
4. Les passages dans une autre langue sont-ils marqués avec des attributs de langue ?
5. La transcription est-elle sur la même page que l'audio, et non derrière un lien séparé ?
6. Avez-vous testé la navigation avec un vrai lecteur d'écran ?

Si une réponse est non, la transcription n'est pas totalement accessible. Les corrections relèvent de la mise en forme, pas de la réécriture du contenu. Une transcription qui passe ces contrôles sert bien au-delà des utilisateurs de lecteurs d'écran : elle aide quiconque balaye le texte à la recherche d'un mot-clé, lit sur un petit écran ou cherche une citation précise. Le travail structurel qui rend les transcriptions accessibles les rend plus utiles pour tous.

Si vous générez des transcriptions à partir de fichiers audio ou vidéo, ConvertAudioToText produit une sortie texte que vous pouvez coller directement dans votre flux de publication et mettre en forme selon les schémas ci-dessus.

Questions fréquentes

Les utilisateurs aveugles ont-ils besoin de sous-titres ou de transcriptions ?

Les utilisateurs aveugles ont besoin de transcriptions, pas de sous-titres. Les sous-titres sont du texte synchronisé superposé à la vidéo, conçus pour les utilisateurs qui peuvent voir la vidéo mais ne peuvent pas entendre l'audio. Une transcription est un document texte autonome qu'un lecteur d'écran peut parcourir de manière indépendante. La WCAG 1.2.1 (niveau A) exige une transcription pour le contenu purement audio préenregistré ; la WCAG 1.2.2 (niveau A) exige des sous-titres pour la vidéo synchronisée. Les deux peuvent être nécessaires, mais ils servent des objectifs différents et des utilisateurs différents.

Où placer la transcription sur la page ?

Placez la transcription sur la même page que l'audio ou la vidéo, et non derrière un lien de téléchargement séparé. Un utilisateur de lecteur d'écran ne devrait pas avoir à naviguer vers une autre page pour accéder au texte. Si la transcription est longue, placez-la sous le lecteur multimédia avec un titre clair afin que l'utilisateur puisse y accéder depuis la liste des titres. Un lien d'évitement (« Aller à la transcription ») au-dessus du lecteur aide également. Si vous proposez un téléchargement, le HTML est plus fiable que le PDF en matière d'accessibilité.

Comment les titres aident-ils les utilisateurs de lecteurs d'écran à naviguer dans une longue transcription ?

Les lecteurs d'écran permettent aux utilisateurs d'afficher la liste de tous les titres de la page et d'accéder directement à l'un d'entre eux. Dans une transcription de 90 minutes sans titres, l'utilisateur doit lire chaque mot séquentiellement pour trouver une section précise. Avec des titres H2 pour les grands sujets toutes les 10 à 15 minutes, l'utilisateur peut accéder à la bonne section en quelques secondes. Le texte du titre doit décrire le sujet, pas seulement afficher un horodatage : « 00:15:30 : Discussion tarifaire » donne un contexte utile ; « 00:15:30 » seul n'en donne aucun.

Les transcriptions PDF sont-elles accessibles aux lecteurs d'écran ?

Les PDF peuvent être accessibles, mais la plupart ne le sont pas par défaut. Un PDF créé avec « Enregistrer au format PDF » depuis Word ou exporté depuis une page web perd généralement sa structure de balises sémantiques. Les lecteurs d'écran peuvent toujours lire le texte séquentiellement, mais la navigation par titres, la structure des listes et les attributs de langue sont généralement supprimés. Pour une accessibilité fiable aux lecteurs d'écran, le HTML sur une page web est le meilleur format. Si vous devez proposer un PDF, utilisez un outil de création PDF qui exporte des PDF balisés avec des balises explicites de titre, de paragraphe et de langue.

Sources

• W3C WCAG 2.1 Understanding 1.2.1 Audio-only and Video-only (Prerecorded): https://www.w3.org/WAI/WCAG21/Understanding/audio-only-and-video-only-prerecorded.html
• W3C WCAG 2.1 Understanding 1.2.2 Captions (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html
• W3C WCAG Understanding 3.1.2 Language of Parts: https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html
• W3C WAI Transcripts guidance: https://www.w3.org/WAI/media/av/transcripts/
• NV Access NVDA download page: https://www.nvaccess.org/download/
• W3C ARIA Landmarks and screen reader AT examples: https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/at.html