Un site web accessible permet à davantage de visiteurs de lire vos contenus, remplir un formulaire, demander un devis ou acheter sans obstacle. Ce guide vous aide à effectuer un premier audit d’accessibilité web WCAG 2.2, même sans équipe spécialisée. Il ne remplace pas un audit complet ni une certification de conformité.
Qu’est-ce que WCAG 2.2 et pourquoi l’utiliser ?
Les Web Content Accessibility Guidelines (WCAG) sont des recommandations techniques internationales du W3C. Elles reposent sur quatre principes : contenu perceptible, interface utilisable, fonctionnement compréhensible et code robuste. Les niveaux A, AA et AAA distinguent des exigences différentes ; le niveau AA est une cible fréquente dans les projets. Les obligations juridiques exactes dépendent du pays, du secteur et du type de service : ne présumez pas qu’une simple checklist constitue une preuve de conformité.
Étape 1 — Choisir un échantillon représentatif
Ne testez pas uniquement la page d’accueil. Retenez au minimum une page de service, un article, une page contact, un formulaire, une page mobile et, pour une boutique, le panier et le paiement. Notez l’URL, le navigateur, la largeur d’écran et la date de chaque contrôle. Reproduisez les scénarios de vos utilisateurs : chercher un service, remplir un devis, se connecter, acheter et recevoir une confirmation.
Étape 2 — Tester la navigation au clavier
Débranchez la souris et parcourez les éléments avec Tab et Maj+Tab. Chaque lien, menu, bouton et champ doit pouvoir être atteint et utilisé. Le focus visuel doit rester identifiable, dans un ordre logique, sans être masqué par un bandeau fixe ou une fenêtre. Vérifiez qu’aucun composant ne piège le clavier ; les fenêtres modales doivent proposer une sortie utilisable. Les critères WCAG 2.1.1, 2.1.2, 2.4.7 et 2.4.11 sont particulièrement pertinents.
Cas fréquent : un menu mobile inaccessible
Si l’icône du menu ne s’active qu’au clic souris, implémentez un véritable élément <button>, un libellé accessible et l’état aria-expanded. Évitez de rendre cliquable un simple <div> sans prise en charge clavier.
Étape 3 — Vérifier contrastes, textes et zoom
Contrôlez le contraste des textes et des composants essentiels avec un outil adapté. Pour le texte normal, le critère WCAG AA 1.4.3 prévoit généralement un rapport minimal de 4,5:1 ; pour le texte de grande taille, 3:1. Testez le zoom à 200 % et la présentation sur un écran étroit : les textes ne doivent pas devenir illisibles ni masquer les actions importantes. Ne communiquez jamais une information uniquement par la couleur : accompagnez le rouge ou le vert d’un message explicite.
Étape 4 — Examiner les images et les formulaires
Les images porteuses d’information ont besoin d’une alternative textuelle utile. Les images purement décoratives peuvent avoir un attribut alt="". Sur un formulaire, associez chaque champ à un libellé visible, signalez les champs obligatoires et expliquez précisément les erreurs. Vérifiez que les messages de validation sont perceptibles au clavier et aux technologies d’assistance. Testez un formulaire volontairement incomplet, puis corrigez les erreurs sans perdre les données déjà saisies.
Étape 5 — Tester avec un lecteur d’écran et des outils automatiques
Des outils tels que Lighthouse, axe DevTools ou WAVE peuvent détecter certaines anomalies de structure, de contraste ou d’attributs. Mais aucun score automatique ne prouve à lui seul la conformité WCAG. Complétez-les par des essais manuels au clavier et, si possible, avec NVDA, VoiceOver ou TalkBack. Écoutez l’ordre de lecture, les titres, les libellés des boutons et les messages d’erreur.
Étape 6 — Corriger les problèmes dans le bon ordre
Classez chaque anomalie selon son impact sur une tâche essentielle, sa fréquence et la difficulté de correction. Traitez d’abord un bouton « Envoyer » inaccessible, un paiement impossible au clavier ou un champ sans libellé. Corrigez ensuite les obstacles répétés dans les menus et composants communs, puis les problèmes de confort. Après chaque correction, retestez le parcours complet : une amélioration visuelle peut créer une régression fonctionnelle.
Checklist d’audit rapide à copier
- Les pages et fonctionnalités principales sont identifiées et testées.
- Tous les éléments interactifs sont utilisables au clavier.
- Le focus est visible et n’est pas entièrement masqué.
- Les contrastes et le zoom sont contrôlés.
- Les images informatives ont une alternative pertinente.
- Les champs ont des libellés et des erreurs compréhensibles.
- La hiérarchie des titres est cohérente.
- Les tests automatiques sont complétés par des tests humains.
- Les corrections sont priorisées et vérifiées après déploiement.
Comment organiser un audit d’accessibilité pour une PME ?
Commencez par un inventaire des parcours et un relevé des problèmes avec capture, URL, étape de reproduction et recommandation. Attribuez chaque correction à un responsable, définissez une échéance, puis effectuez une contre-vérification. Si votre site doit être modernisé, envisagez une refonte de site web intégrant l’accessibilité dès les maquettes. Pour un suivi technique durable, consultez aussi notre service de maintenance de site web et notre guide pour mettre WordPress à jour sans interrompre le service.
Ressources officielles et prochaines étapes
Référez-vous aux WCAG 2.2 du W3C, à la méthode de test de la WAI et à la checklist WebAIM pour approfondir les critères. Vous souhaitez identifier les obstacles qui font abandonner vos visiteurs ? Contactez 3Vision Group pour discuter d’un diagnostic technique, d’une refonte ou d’une maintenance adaptée à votre site.
