Pour chaque script ayant une alternative, cette alternative est-elle pertinente ?
Vous avez prévu une alternative à votre carte Google Maps : un formulaire textuel pour chercher une adresse. Bonne initiative. Mais si ce formulaire ne permet pas de calculer un itinéraire alors que la carte le fait, l’alternative n’est pas pertinente. C’est exactement ce que vérifie le critère 7.2.
Le test 7.2.1 porte sur les alternatives fonctionnelles : l’utilisateur peut-il accéder aux mêmes contenus et accomplir les mêmes tâches sans JavaScript ? Une alternative pertinente est une alternative équivalente, pas un ersatz. Elle peut prendre la forme d’un lien vers une version alternative, d’un contenu HTML qui s’affiche quand JS est désactivé, ou d’un composant <noscript>.
Le test 7.2.2 concerne les éléments non textuels mis à jour dynamiquement. Un graphique actualisé toutes les trente secondes : son aria-label doit être mis à jour dans le même cycle. Un attribut figé sur les données précédentes devient un mensonge pour les utilisateurs de lecteurs d’écran. C’est la technique d’échec F20 en action.
L’amélioration progressive règle les deux problèmes : une base HTML fonctionnelle, JavaScript qui enrichit. Pas d’alternative à maintenir séparément, pas de désynchronisation possible.
2 tests pour confirmer qu'une alternative est proposée pour chaque script
Équivalence fonctionnelle de l'alternative JavaScript
- Identifiez les composants JavaScript qui proposent une alternative déclarée : lien « Version accessible », bloc
<noscript>, version HTML de secours. - Désactivez JavaScript dans le navigateur et rechargez la page pour faire apparaître les alternatives qui s’affichent automatiquement.
- Pour chaque alternative identifiée, vérifiez qu’elle donne accès aux mêmes contenus que le composant JavaScript original.
- Vérifiez qu’elle permet d’accomplir des fonctionnalités similaires (calculer un itinéraire, filtrer des données, soumettre un formulaire).
- Si toutes les alternatives sont fonctionnellement équivalentes : test validé. Si une alternative est incomplète sur une fonctionnalité clé : test non validé.
Mise à jour synchronisée de l'alternative d'un élément non textuel
- Repérez tous les éléments non textuels (images, graphiques, jauges,
<canvas>,<svg>) dont le contenu est modifié dynamiquement par JavaScript. - Pour chacun, vérifiez qu’une alternative textuelle est présente :
alt,aria-label,aria-labelledby, ou<title>sur SVG. - Déclenchez la mise à jour du contenu non textuel (attendre le rechargement automatique ou interagir avec le composant).
- Observez dans l’inspecteur DOM si l’alternative textuelle est modifiée dans le même temps.
- Vérifiez que l’alternative mise à jour décrit le nouveau contenu affiché, pas l’ancien.
- Si l’alternative est synchronisée et pertinente : test validé. Si elle est figée ou décrit un état précédent : test non validé.
Exemples
❌ Non conforme : Graphique dynamique avec alternative textuelle figée
<canvas id="sales-chart" aria-label="Ventes septembre : 120 k unités"></canvas>
<script>
function updateChart(newData) {
drawChart(newData); // Met à jour le canvas visuellement
// L'aria-label n'est PAS mis à jour
}
setInterval(() => fetchData().then(updateChart), 30000);
</script>Le graphique affiche les chiffres d’octobre en temps réel, mais l’aria-label annonce encore « Ventes septembre ». Un utilisateur de lecteur d’écran reçoit des données fausses. C’est la technique d’échec F20 des WCAG : l’alternative n’est pas mise à jour quand le contenu change.
✅ Conforme : Carte interactive avec alternative fonctionnelle complète
<div id="map-container">
<div id="google-map" aria-hidden="true"></div>
<div id="map-fallback">
<p>Cette carte interactive nécessite JavaScript.
Utilisez le formulaire ci-dessous pour calculer votre itinéraire.</p>
<form action="/itineraire" method="get">
<label for="depart">Adresse de départ</label>
<input type="text" id="depart" name="depart">
<label for="arrivee">Adresse d’arrivée</label>
<input type="text" id="arrivee" name="arrivee">
<button type="submit">Calculer l’itinéraire</button>
</form>
</div>
</div>
<script>
document.getElementById('map-fallback').hidden = true;
initGoogleMap();
</script>L’alternative offre les mêmes fonctionnalités que la carte : l’utilisateur peut calculer un itinéraire. Elle est visible quand JS est désactivé ou quand la carte ne charge pas. Le formulaire permet d’accomplir la même tâche principale : test 7.2.1 validé.
Astuces et pièges
⚠️ Une alternative qui affiche le contenu mais n’en permet pas l’interaction
C’est l’erreur la plus fréquente en audit. Un tableau de données remplace un graphique filtrable, mais sans les filtres. L’utilisateur voit l’information mais ne peut pas la manipuler. Afficher n’est pas équivalent à interagir : l’alternative doit couvrir les fonctionnalités, pas seulement le contenu statique.
⚠️ Confondre critère 7.1 et critère 7.2
Le critère 7.1 vérifie que le script lui-même est accessible nativement (rôles ARIA, interactions clavier). Le critère 7.2 vérifie que l’alternative à ce script est pertinente. Un composant peut échouer à 7.1 et réussir à 7.2, et inversement. Ce sont deux périmètres d’audit distincts.
💡 Pas besoin de désactiver JS sur tout le site
Le RGAA n’impose pas de désactiver JavaScript sur l’ensemble de la page pour auditer le critère 7.2. L’obligation porte uniquement sur les scripts qui déclarent une alternative. Si un composant est accessible nativement (7.1 validé), il n’est pas concerné par 7.2.
⚠️ Mise à jour asynchrone : l’alternative doit suivre en temps réel
Pour le test 7.2.2, l’alternative textuelle doit être mise à jour dans le callback de la requête AJAX, pas dans un setTimeout décalé. Ouvrez l’inspecteur DOM et observez l’attribut aria-label pendant que le contenu visuel change : si le DOM ne bouge pas, c’est non conforme.
⚠️ L’amélioration progressive satisfait 7.2 sans alternative séparée
Si votre composant JavaScript est construit par-dessus une base HTML fonctionnelle, il n’y a pas d’« alternative » à proprement parler : le HTML de base est la version sans JS, et le critère 7.2 est satisfait nativement. Aucune version parallèle à maintenir.
Questions fréquentes
Comment procéder pour tester le critère RGAA 7.2 sans JavaScript activé ?
Seulement pour révéler les alternatives HTML qui s’affichent automatiquement quand JS est absent (test 7.2.1). Vous n’avez pas à désactiver JS sur tout le site : le RGAA ne l’exige pas. L’objectif est de vérifier que les alternatives déclarées sont fonctionnellement équivalentes, pas de tester chaque composant en mode dégradé.
Quand un composant JavaScript nativement accessible doit-il proposer une alternative RGAA ?
Non. Le critère 7.2 ne s’applique qu’aux scripts « ayant une alternative » — c’est dans l’intitulé même du critère. Si votre composant est accessible nativement (critère 7.1 validé), vous n’avez pas à fournir d’alternative. L’obligation porte sur la qualité des alternatives existantes, pas sur leur création.
Pourquoi un bloc <noscript> ne constitue pas forcément une alternative valide au script ?
<noscript> est une alternative valide pour le test 7.2.1, à condition que son contenu soit fonctionnellement équivalent au composant JS. En revanche, il ne résout pas le test 7.2.2 (mise à jour d’une alternative en temps réel) : <noscript> n’est rendu que quand JS est désactivé, pas pendant l’exécution dynamique.
Comment vérifier qu'une alternative est bien mise à jour pour le test 7.2.2 ?
Deux méthodes : ouvrez l’inspecteur DOM et observez l’attribut alt ou aria-label en direct pendant que le contenu visuel change. Ou utilisez NVDA en mode navigation : si l’annonce vocale décrit encore l’état précédent après la mise à jour, c’est la technique d’échec F20 des WCAG.