ACCESIBILIDAD ≠ OVERLAY · 34
L’accessibilité n’est pas seulement une question technique : une approche globale
Code accessible, contenus clairs, design compréhensible, expérience inclusive et maintenance continue doivent fonctionner ensemble.
1. L’accessibilité dépasse le code
Un site peut réussir des contrôles automatiques tout en restant difficile à utiliser. L’accessibilité associe technique, contenus, design, parcours réels et maintenance. Aucun de ces éléments ne remplace les autres.
Un HTML correct ne rend pas des consignes confuses compréhensibles. Une interface séduisante ne répare pas un achat impossible au clavier. Il faut examiner l’expérience entière.
2. Le développement accessible est essentiel
Le HTML sémantique aide les navigateurs et technologies d’assistance à reconnaître titres, liens, boutons, formulaires et régions. Les composants natifs offrent généralement des comportements prévisibles.
Il faut respecter un ordre de lecture et de focus logique, associer les étiquettes aux champs et rendre les erreurs identifiables par programmation. ARIA complète la sémantique sans remplacer le HTML approprié.
3. Les contenus peuvent aussi créer des obstacles
Les titres structurent l’information, les liens doivent décrire leur destination et les instructions ne doivent pas dépendre uniquement des couleurs ou de la position. L’accessibilité éditoriale commence avant publication.
Les images informatives demandent des alternatives textuelles, les tableaux des en-têtes pertinents et les documents une structure accessible. Les vidéos nécessitent des sous-titres et d’autres alternatives adaptées.
4. Un design clair et cohérent
Une hiérarchie visuelle reconnaissable, des composants cohérents, un contraste suffisant et une typographie lisible facilitent l’autonomie. Les visiteurs ne devraient pas réapprendre chaque commande.
La couleur seule ne doit pas signaler une erreur. Le zoom, la redistribution du contenu et les petits écrans doivent préserver informations et fonctionnalités.
5. Les parcours réels comptent
Une belle page d’accueil ne prouve pas qu’on puisse prendre rendez-vous, payer ou envoyer une demande. Il faut évaluer les parcours complets, y compris la correction des erreurs et les confirmations.
Testez les menus au clavier, les champs obligatoires et les retours d’information. Une fenêtre qui piège le focus peut empêcher de terminer une démarche.
6. Une responsabilité collective
Des obstacles apparaissent quand design, développement, rédaction et maintenance considèrent que l’accessibilité relève d’un autre service. Chaque décision compte.
Définissez des critères communs et des responsables. Le design documente les états, le développement assure les interactions, la rédaction clarifie les messages et les tests vérifient les tâches.
7. Les WCAG 2.2 comme référence
Les WCAG 2.2 reposent sur quatre principes : perceptible, utilisable, compréhensible et robuste. Elles apportent des critères vérifiables au-delà des préférences esthétiques.
Elles couvrent alternatives textuelles, clavier, contraste, focus, erreurs et compatibilité. Réussir un contrôle automatique ne démontre pas une conformité complète.
8. Associer plusieurs méthodes de test
Les outils automatiques détectent certaines erreurs de contraste, de noms et de balisage. Ils ne jugent pas toujours le sens des consignes ou la pertinence d’un texte alternatif.
Associez analyse automatique, inspection du code, navigation au clavier, zoom et lecteurs d’écran. Impliquez si possible des personnes handicapées.
9. La maintenance fait partie du travail
Une mise à jour de thème, une extension ou un document publié peuvent introduire de nouveaux obstacles. Un site accessible aujourd’hui peut ne plus l’être demain.
Ajoutez des vérifications aux publications et aux mises à jour. Listes de contrôle, tests de régression et suivi des anomalies aident à conserver les progrès.
10. Pourquoi un overlay ne suffit pas
Un widget flottant peut changer certains réglages visuels sans garantir des formulaires accessibles, une gestion correcte du focus ou des documents compréhensibles.
Sa présence ne prouve pas la conformité aux WCAG 2.2. Il faut corriger les obstacles dans la structure et les interactions réelles.
11. Commencer par des actions concrètes
Choisissez trois tâches importantes et essayez-les au clavier et avec des technologies d’assistance. Vérifiez titres, liens, formulaires, erreurs, contraste et zoom.
Notez les obstacles, leur impact et les responsables. Corrigez d’abord les blocages puis testez à nouveau. L’accessibilité est une méthode de travail.
Sémantique et comportement prévisible
Imaginez un bouton ouvrant un formulaire de contact. S’il s’agit seulement d’un élément graphique réagissant au clic de souris, une personne utilisant le clavier risque de ne jamais pouvoir l’activer. Un véritable bouton HTML, doté d’un nom explicite et d’une gestion correcte du focus, corrige la cause du problème.
De même, une étiquette visible près d’un champ ne suffit pas si elle n’est pas associée dans le code. Le message d’erreur doit identifier le champ concerné et expliquer comment le corriger. Une personne utilisant un lecteur d’écran doit recevoir cette information sans dépendre du texte rouge.
Des contenus qui guident
Les équipes éditoriales peuvent améliorer l’accessibilité sans toucher au code. Les liens doivent décrire leur destination au lieu de répéter « en savoir plus ». Les informations importantes présentes dans les images doivent également être disponibles en texte. Les documents téléchargeables nécessitent des titres structurés et un ordre de lecture cohérent.
Les consignes ne doivent pas supposer que tout le monde voit la disposition de la page. Remplacer « choisissez l’option verte à droite » par le nom de l’action améliore la compréhension avec un lecteur d’écran, un fort zoom ou un petit écran.
Un design adapté à différentes situations
Vérifiez le contraste réel entre texte et fond, y compris dans les boutons, les champs et les alertes. L’indicateur de focus doit rester visible. Les éléments interactifs ne doivent pas exiger des mouvements de pointeur extrêmement précis. Avec un zoom important, les contenus essentiels doivent rester accessibles.
Examinez si la lecture ordinaire nécessite des défilements inutiles dans deux directions sur les petits écrans. Vérifiez également que les fenêtres de dialogue ne masquent pas d’informations importantes et que le focus revient à un endroit logique après leur fermeture.
Tester le parcours complet
Partez d’une tâche concrète : une personne trouve un service, lit sa description, choisit une date, remplit un formulaire et reçoit une confirmation. Des obstacles peuvent survenir à chaque étape, même lorsque le rapport automatique paraît satisfaisant. Notez les étapes et le résultat attendu.
Refaites ce parcours sans souris, avec un zoom élevé et avec un lecteur d’écran. Donnez la priorité aux problèmes qui empêchent de terminer la démarche. Après correction, retestez tout le parcours, car la modification d’un composant peut avoir des effets ailleurs.
Un processus durable
L’accessibilité doit faire partie du design, du développement, de la publication et de la maintenance. Une liste de contrôle pour les nouveaux articles, images et formulaires évite le retour des erreurs. Chaque équipe doit savoir qui détecte et qui corrige les obstacles.
Après la mise à jour d’un thème ou d’une extension, vérifiez de nouveau les tâches importantes. Les WCAG 2.2 fournissent des exigences mesurables, mais une note automatique ne remplace pas le jugement humain. Un overlay n’assume pas cette responsabilité.