Audit checklist
- Confirmez que chaque contrôle interactif possède un nom accessible.
- Vérifiez la structure des titres, les points de repère et le HTML sémantique.
- Vérifiez l'accès au clavier et la visibilité de l'indicateur de focus.
- Repérez les défauts de contraste du texte et des composants d'interface.
- Contrôlez les étiquettes, les erreurs et les instructions des formulaires.
- Passez en revue les images, icônes et SVG pour des alternatives utiles.
- Retestez les gabarits corrigés et les pages à forte valeur.
Pourquoi les WCAG 2.2 AA sont la cible pratique
Les WCAG s'organisent en critères de succès de niveaux A, AA et AAA. Le niveau A couvre les barrières les plus élémentaires ; le niveau AA ajoute des exigences largement attendues pour les sites publics et commerciaux. Les WCAG 2.2 conservent les critères connus des WCAG 2.1 et ajoutent des exigences plus récentes, comme l'apparence du focus et la taille des cibles.
Pour les contenus web dans l'UE, la norme EN 301 549 renvoie aux critères WCAG. Un audit WCAG constitue donc une base pratique pour la préparation à l'EAA, les déclarations d'accessibilité et les questionnaires de marchés publics.
Erreurs WCAG fréquentes qui nuisent aux conversions
Les problèmes d'accessibilité ne sont pas qu'un risque juridique ; ce sont des problèmes de conversion. Des étiquettes manquantes compliquent les formulaires. Un contraste faible masque les prix et les appels à l'action. Les pièges au clavier bloquent les personnes utilisant des technologies d'assistance comme les utilisateurs avancés. Des messages d'erreur confus donnent l'impression que le panier est cassé.
Les gains les plus rapides viennent généralement du design system : boutons, champs de formulaire, fenêtres modales, navigation et composants d'alerte accessibles. Corriger ces patrons améliore chaque page qui les utilise.
- Boutons et liens sans nom descriptif
- Champs de formulaire sans étiquette ou avec des erreurs inaccessibles
- Fenêtres modales qui ne gèrent pas le focus
- Défauts de contraste sur les appels à l'action et les états désactivés
- Icônes annoncées comme des noms de fichiers sans signification
Une démarche de correction réaliste
Commencez par les violations critiques et sérieuses sur les pages génératrices de revenus. Corrigez ensuite les gabarits réutilisables. Après chaque sprint, lancez un scan de vérification pour que l'équipe voie si la même règle réapparaît. Conservez les preuves avant/après avec les notes de version ; elles serviront quand des clients demanderont une documentation d'accessibilité.
FAQ
Les WCAG 2.2 remplacent-elles les WCAG 2.1 ?
Les WCAG 2.2 s'appuient sur les WCAG 2.1. Un audit WCAG 2.2 AA contrôle toujours les critères A/AA antérieurs et ajoute les nouvelles exigences de la version 2.2.
axe-core peut-il trouver tous les problèmes WCAG ?
Aucun moteur automatique ne trouve tous les problèmes WCAG. Les tests automatisés excellent pour de nombreuses erreurs détectables dans le code ; la qualité du contenu, la logique des tâches et certaines exigences multimédias demandent une revue humaine.
Les corrections WCAG relèvent-elles des développeurs ou du juridique ?
Les développeurs corrigent le code, mais le produit, le design et le juridique doivent s'accorder sur le périmètre, la formulation de la déclaration et les priorités de risque. L'accessibilité est un processus de qualité produit, pas la liste de contrôle d'une seule personne.