ACCESSIBILITÉ ≠ OVERLAY · 35
L’accessibilité ne se prouve pas par une note : elle se prouve lorsque les personnes peuvent utiliser votre site
📅 6 novembre 2026 · ⏱ 6 min de lecture
Un score parfait peut masquer des obstacles bien réels.
01. Ce que signifie réellement une note
Une note résume des contrôles précis réalisés dans un contexte donné. Elle ne représente ni toutes les personnes ni tous les usages. Une page d’accueil peut obtenir un résultat excellent alors que le panier, la réservation ou l’espace personnel comporte des obstacles empêchant de terminer une démarche.
Les scores sont utiles pour suivre certaines erreurs techniques et repérer des régressions. Ils deviennent trompeurs lorsqu’on les présente comme une garantie absolue. L’accessibilité concerne le service entier : ses contenus, ses interactions et les résultats obtenus par les visiteurs.
02. L’utilité des outils automatiques
Les analyseurs automatiques repèrent des erreurs vérifiables : images sans alternative, certains contrastes insuffisants, champs sans étiquette, problèmes de structure HTML et attributs incorrects. Ils permettent de contrôler rapidement plusieurs modèles de pages et de répéter les vérifications après une mise à jour.
Leur efficacité dépend aussi du périmètre analysé. Scanner uniquement l’accueil ne renseigne pas sur les fenêtres modales, les erreurs de formulaire ou les étapes d’un paiement. Les alertes nécessitent une interprétation et l’absence d’alerte ne garantit pas une expérience inclusive.
03. Les limites de l’automatisation
Un logiciel ne peut pas toujours juger si le texte alternatif explique réellement une image, si une instruction est claire sans voir l’écran ou si un parcours complexe reste compréhensible. Il ne reproduit pas non plus toutes les configurations de navigateurs et de technologies d’assistance.
Un lien intitulé « cliquez ici » peut être techniquement valide et demeurer incompréhensible dans une liste de liens annoncée par un lecteur d’écran. Il faut examiner le contexte et formuler une destination explicite. Cette décision exige une compréhension humaine du contenu.
04. Quand un score parfait cache des obstacles
Imaginons une boutique affichant une note parfaite. Les boutons possèdent des noms et les images des alternatives. Pourtant, l’ouverture du panier laisse le focus derrière une fenêtre. Une personne utilisant le clavier ne peut ni fermer la fenêtre ni terminer sa commande.
D’autres obstacles apparaissent lorsqu’une erreur n’est indiquée que par la couleur rouge ou lorsqu’un message disparaît trop vite. Une capture d’écran ne montre pas ces problèmes. Seul un essai du parcours complet permet de constater si le service fonctionne réellement.
05. Tester la navigation au clavier
Mettez la souris de côté. Utilisez Tab et Maj+Tab pour parcourir les liens, boutons et champs. Vérifiez que le focus reste visible et suit un ordre logique. Essayez les menus, calendriers et fenêtres de dialogue, puis activez les commandes avec les touches appropriées.
Atteindre un élément ne suffit pas : il faut pouvoir l’utiliser et poursuivre sa navigation. Un focus piégé, invisible ou déplacé de manière inattendue constitue un obstacle sérieux. Notez les étapes exactes pour permettre la reproduction et la correction.
06. Écouter le site avec un lecteur d’écran
Un lecteur d’écran révèle comment les titres, régions, liens, commandes et messages sont annoncés. Une ligne simplement agrandie visuellement ne remplace pas un véritable titre HTML. Un bouton représenté uniquement par une icône doit posséder un nom compréhensible.
Écoutez ce qui se produit après chaque action. Une erreur est-elle annoncée ? Le champ concerné est-il identifié ? La confirmation d’une opération est-elle communiquée ? Ces questions rendent visibles les limites d’un indicateur numérique global.
07. Formulaires et parcours complets
Un formulaire accessible explique les informations attendues, distingue les champs obligatoires et fournit des erreurs compréhensibles. Les visiteurs doivent pouvoir corriger leurs réponses sans perdre inutilement ce qu’ils ont déjà saisi. Le fonctionnement ne doit pas dépendre exclusivement de la souris.
Testez la démarche de son début jusqu’à sa confirmation. Une page de présentation accessible ne suffit pas si le calendrier de rendez-vous ne fonctionne pas au clavier. Dans une boutique, l’objectif réel est de finaliser la commande, pas seulement d’ouvrir le panier.
08. Contraste, zoom et compréhension
Contrôlez les contrastes réels, la visibilité du focus et la taille des cibles interactives. Agrandissez fortement la page et vérifiez que les informations importantes restent disponibles sans défilements inutiles dans deux directions. N’utilisez jamais uniquement la couleur pour transmettre un état.
La compréhension fait également partie de l’expérience. Des titres précis, des instructions simples et une navigation cohérente réduisent les erreurs. Une interface imprévisible peut rester difficile même lorsque chacun de ses éléments satisfait un contrôle technique isolé.
09. WCAG 2.2 : une référence, pas un trophée
Les WCAG 2.2 proposent des critères de succès vérifiables et un langage commun aux équipes. Elles aident à définir les exigences et à contrôler les corrections. Cependant, un score automatique n’est pas une preuve de conformité à l’ensemble des critères applicables.
Associez ces règles à une inspection manuelle, des essais fonctionnels et la participation de personnes handicapées. Une déclaration d’accessibilité responsable décrit la situation réelle et les limites connues, plutôt que de promettre une perfection non vérifiée.
10. Tester avec des personnes concernées
Les personnes handicapées peuvent révéler des obstacles que les équipes n’ont pas anticipés. Observez des tâches concrètes et écoutez les difficultés rencontrées, sans considérer qu’un participant représente tous les besoins. Les pratiques et technologies d’assistance sont diverses.
Préparez des scénarios : trouver un service, réserver un rendez-vous, modifier un paramètre ou télécharger un document. Notez les blocages et leurs conséquences. Traitez en priorité les problèmes empêchant de terminer les tâches essentielles et vérifiez les corrections.
11. Pourquoi un overlay ne suffit pas
Un overlay peut proposer des réglages visuels, mais il ne remplace pas une structure HTML correcte, des formulaires utilisables ou une navigation fiable au clavier et au lecteur d’écran. Il ne peut pas décider si les explications d’une démarche sont suffisamment claires.
Installer un widget ne rend pas automatiquement un site conforme aux WCAG 2.2. L’interface ajoutée peut elle-même nécessiter des tests. La solution durable consiste à corriger le site d’origine et à maintenir ses améliorations.
12. Organiser une amélioration continue
Identifiez les parcours prioritaires et les modèles de pages concernés. Combinez analyse automatique, clavier, lecteur d’écran, zoom, contrôle de la structure et tests des formulaires. Consignez chaque problème avec des étapes reproductibles et un responsable.
Intégrez ensuite les contrôles aux publications et mises à jour. Revérifiez les composants communs et les démarches critiques après chaque changement. L’objectif n’est pas d’afficher un nombre flatteur, mais de permettre à davantage de personnes d’utiliser le service de manière autonome.