ACCESIBILIDAD ≠ OVERLAY · 30
Accessibilité ≠ Overlay : 10 vérifications pour savoir si votre site est vraiment accessible
📅 29 octobre 2026 · ⏱ 4 min de lecture
Une icône flottante ne prouve pas l’accessibilité. Ce qui compte, c’est la possibilité de naviguer, de comprendre et d’accomplir une tâche sans obstacle. Voici dix vérifications concrètes.
01. Commencer par une tâche, pas par le widget
Choisissez un objectif important : demander un devis, prendre rendez-vous, acheter ou trouver un contact. Parcourez toutes les étapes au lieu de chercher seulement un bouton d’accessibilité.
Notez chaque étape confuse ou impossible. Un site séduisant peut malgré tout empêcher une personne de terminer sa démarche.
02. Tester le parcours au clavier
Mettez la souris de côté et utilisez Tab et Maj+Tab. Activez les commandes avec Entrée ou Espace et essayez menus, formulaires et confirmations.
Un ordre de focus illogique, une commande inaccessible ou un piège au clavier sont de véritables obstacles. Modifier les couleurs ne les résout pas.
03. Vérifier le focus et les fenêtres de dialogue
Le focus doit rester visible, même avec un en-tête fixe. Lorsqu’une fenêtre modale s’ouvre, il faut gérer correctement le focus et le rétablir après la fermeture.
Si la confirmation d’achat laisse le focus derrière la fenêtre, le parcours est défaillant. Il faut corriger le composant.
04. Écouter la page avec un lecteur d’écran
Avec un lecteur d’écran, parcourez titres, liens, boutons et champs. Écoutez les noms accessibles, l’ordre de lecture et les descriptions des images informatives.
L’apparence ne remplace pas la sémantique HTML. Les technologies d’assistance ont besoin d’étiquettes et d’états correctement annoncés.
05. Examiner les formulaires et les erreurs
Envoyez un formulaire vide puis saisissez des données invalides. Les messages expliquent-ils le problème et comment le corriger ? Les champs obligatoires sont-ils identifiables ?
Un simple « Erreur » ou un code couleur ne suffit pas. Les instructions doivent être claires et associées au bon champ.
06. Tester le zoom et les petits écrans
Passez le zoom à 200 % et testez les petits écrans. Les actions essentielles doivent rester accessibles sans chevauchements ni défilement impraticable.
Agrandir le texte n’aide que si la mise en page s’adapte. Un widget ne répare pas un design responsive défectueux.
07. Vérifier les contenus et la structure
Structurez les titres de manière logique, rédigez des liens explicites et des consignes compréhensibles. Les images informatives nécessitent des alternatives textuelles.
Une bonne structure aide les utilisateurs de lecteurs d’écran et les personnes qui parcourent rapidement la page. C’est aussi un travail éditorial.
08. Comprendre les limites des tests automatiques
Les outils automatiques détectent certains défauts de contraste, de balisage ou de nom accessible. Ils ne peuvent pas juger seuls la qualité d’un parcours complet.
Associez-les à des vérifications manuelles, au clavier et avec des technologies d’assistance. Un score n’est pas une preuve de conformité WCAG.
09. Prioriser les blocages et désigner des responsables
Classez les problèmes selon leur impact : empêcher un paiement est plus grave qu’un petit défaut visuel. Documentez la manière de reproduire chaque blocage.
Désignez des responsables et corrigez les composants partagés plutôt que de masquer les symptômes sur chaque page.
10. Refaire les tests après chaque modification
Une mise à jour WordPress, un module Divi ou un nouveau formulaire peut introduire des obstacles. Intégrez les contrôles au processus de maintenance.
Appuyez-vous sur les WCAG 2.2 et conservez les résultats des tests. L’objectif est l’autonomie des personnes.