# Construire un lecteur de podcast accessible pour la presse locale

> Contrôles au clavier, transcription liée, aucune bibliothèque tierce lourde : les étapes pour construire un lecteur audio personnalisé adapté à un site de presse locale.

- Auteur : WordPress Développement
- Publié le : 2023-08-10
- Mis à jour le : 2023-08-10
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/lecteur-podcast-accessible-presse-locale/

## L’essentiel

- L'élément audio natif reste la meilleure base de départ
- Les contrôles personnalisés exigent tous les rôles ARIA du motif slider
- La transcription liée profite à tous, pas seulement aux malentendants

`npm install` n'a jamais été nécessaire pour construire un lecteur de podcast accessible correct : l'élément `<audio>` natif du navigateur fournit déjà l'essentiel des contrôles, avec ses propres raccourcis clavier et sa propre annonce vocale. Le site d'un hebdomadaire de presse locale souhaitait pourtant un habillage visuel personnalisé, cohérent avec sa charte graphique, plutôt que l'interface par défaut du navigateur. Voici la démarche suivie pour construire ce lecteur sur mesure sans perdre les qualités d'accessibilité de l'élément natif.

## Étape 1 : partir de l'élément natif, jamais le remplacer entièrement

La première décision structurante consiste à conserver l'élément `<audio>` natif dans le DOM, simplement masqué visuellement, et à construire les contrôles personnalisés à côté, pilotés par script :

```
<audio id="podcast-source" src="/podcasts/edition-15.mp3" preload="metadata"></audio>

<div class="lecteur-personnalise">
  <button id="bouton-lecture" aria-label="Lecture">▶</button>
  <div id="barre-progression" role="slider"
       aria-label="Progression de l'épisode"
       aria-valuemin="0" aria-valuemax="100" aria-valuenow="0"
       tabindex="0"></div>
</div>
```

Cette approche évite de réimplémenter la logique de décodage audio elle-même, tout en offrant un contrôle total sur l'apparence visuelle des boutons et de la barre de progression.

## Étape 2 : couvrir les cinq contrôles clavier attendus

> L'essentiel à retenir : L'élément audio natif reste la meilleure base de départ ; Les contrôles personnalisés exigent tous les rôles ARIA du motif slider ; La transcription liée profite à tous, pas seulement aux malentendants

Le motif de conception ARIA « slider » impose une liste précise de touches à gérer pour la barre de progression, sans laquelle le composant resterait incomplet au clavier :

```
const barre = document.getElementById('barre-progression');
const audio = document.getElementById('podcast-source');

barre.addEventListener('keydown', (evenement) => {
  const pas = 5; // secondes
  switch (evenement.key) {
    case 'ArrowRight':
      audio.currentTime += pas;
      break;
    case 'ArrowLeft':
      audio.currentTime -= pas;
      break;
    case 'Home':
      audio.currentTime = 0;
      break;
    case 'End':
      audio.currentTime = audio.duration;
      break;
    case ' ':
    case 'Enter':
      audio.paused ? audio.play() : audio.pause();
      break;
  }
  mettreAJourValeurAria();
});

function mettreAJourValeurAria() {
  const pourcentage = Math.round((audio.currentTime / audio.duration) * 100);
  barre.setAttribute('aria-valuenow', pourcentage);
}
```

Les cinq contrôles couverts ici — avancer, reculer, revenir au début, aller à la fin, lecture ou pause — correspondent exactement à ce qu'un utilisateur de lecteur d'écran attend d'un composant portant le rôle `slider`. Un rôle ARIA posé sans son comportement clavier complet reste plus trompeur qu'une absence de rôle, car il annonce une interactivité qui ne répond pas ensuite aux attentes.

## Étape 3 : lier la transcription, pas seulement l'ajouter

Chaque épisode dispose d'une transcription textuelle complète, rédigée par la journaliste responsable du podcast. Le lien entre le lecteur et cette transcription se fait par un attribut `aria-describedby` pointant vers un résumé, complété d'un lien visible et classique vers le texte intégral :

```
<div class="lecteur-personnalise" aria-describedby="resume-episode">
  ...
</div>
<p id="resume-episode" class="masque-visuellement">
  Épisode 15, vingt-trois minutes, entretien avec la présidente de l'association de commerçants.
</p>
<a href="/podcasts/edition-15/transcription">Lire la transcription complète</a>
```

La transcription complète profite très au-delà des seules personnes sourdes ou malentendantes : elle sert aussi à la recherche interne du site, à l'indexation par les moteurs de recherche, et aux lecteurs qui préfèrent simplement lire plutôt qu'écouter, un public souvent sous-estimé sur un site de presse locale.

## Étape 4 : tester avec le clavier seul, puis avec un lecteur d'écran

- Débrancher la souris et parcourir le lecteur uniquement au clavier, du bouton de lecture jusqu'à la barre de progression ;
- Vérifier que chaque valeur de progression est bien annoncée après un déplacement au clavier ;
- Vérifier avec NVDA que le rôle `slider` est correctement restitué, avec sa valeur actuelle et ses bornes.

> Un lecteur audio personnalisé n'apporte rien de plus qu'un habillage visuel : toute la mécanique d'accessibilité doit être reconstruite manuellement dès qu'on s'éloigne des contrôles natifs du navigateur.

## Notre verdict

Construire un lecteur de podcast accessible sur mesure ne demande aucune bibliothèque tierce, mais exige de couvrir intégralement le motif ARIA choisi, sans se contenter d'ajouter un rôle décoratif. La transcription liée, souvent traitée comme une option secondaire, s'avère au final l'élément le plus consulté par l'ensemble du lectorat, bien au-delà du seul public malentendant visé initialement.