Accessibilité web : auditer un site avec une checklist vraiment utile

Un site peut être agréable à regarder tout en restant difficile, voire impossible, à utiliser pour certaines personnes. Un bouton inaccessible au clavier, un contraste insuffisant ou un formulaire mal étiqueté suffit à bloquer une action importante. Un audit d’accessibilité web permet de repérer ces obstacles avant qu’ils ne deviennent des abandons, des demandes d’assistance ou des corrections coûteuses.

La méthode la plus efficace ne consiste pas à lancer un outil automatique puis à corriger mécaniquement toutes ses alertes. Il faut combiner des contrôles rapides, des essais manuels et quelques vérifications dans des situations réelles d’utilisation. Cette checklist vous aide à commencer par les problèmes qui ont le plus de conséquences pour les visiteurs.

Commencer par les parcours qui comptent vraiment

Un audit complet peut couvrir chaque page, chaque composant et chaque état d’interface. Pour un premier passage, mieux vaut sélectionner les parcours qui correspondent aux objectifs du site : trouver une information, remplir un formulaire, acheter, prendre rendez-vous, télécharger un document ou se connecter à un espace personnel.

Choisissez ensuite plusieurs pages représentatives :

• la page d’accueil ou une page d’entrée depuis un moteur de recherche ;
• une page contenant beaucoup de texte ou de médias ;
• une page avec formulaire, filtres ou éléments interactifs ;
• une page de conversion, comme une fiche produit ou une demande de contact ;
• une page importante consultée sur mobile.

Cette sélection révèle souvent les problèmes récurrents du site. Si un composant est mal conçu dans le menu ou le formulaire, le corriger à la source sera généralement plus rentable que de traiter chaque page séparément.

La checklist d’accessibilité à parcourir manuellement

1. Vérifier la navigation sans souris

Débranchez mentalement la souris et utilisez uniquement la touche Tab, la combinaison Majuscule + Tab, la touche Entrée et les flèches lorsque l’interface les prévoit. Le focus visible doit permettre de savoir immédiatement quel élément est sélectionné.

Observez notamment si :

• tous les liens, boutons, champs et contrôles sont atteignables ;
• l’ordre de navigation suit la logique visuelle de la page ;
• le focus ne disparaît pas derrière un bandeau fixe ou une fenêtre ;
• un menu ouvert peut être parcouru sans revenir à des éléments cachés ;
• une modale peut être fermée au clavier et restitue ensuite le focus au bon endroit ;
• aucun composant ne crée de boucle ou de blocage.

Un lien « Passer au contenu » placé au début de la page peut éviter de parcourir le même menu à chaque visite. Il doit toutefois fonctionner réellement et déplacer le focus vers la zone principale, pas seulement modifier l’apparence de l’écran.

2. Contrôler les textes, les titres et les liens

Les titres doivent décrire la structure du contenu et suivre une hiérarchie cohérente. Un titre de niveau 2 ne sert pas uniquement à agrandir une phrase : il signale une nouvelle partie du document. Les niveaux ne doivent pas être choisis pour leur apparence, mais pour leur rôle.

Les liens doivent aussi être compréhensibles hors contexte. Une succession de liens intitulés « En savoir plus » ne permet pas toujours de distinguer les destinations, surtout lorsqu’un lecteur utilise une liste de liens générée par un lecteur d’écran. Préférez des formulations comme « Lire le guide de sauvegarde » ou « Voir les conditions de livraison ».

Les textes alternatifs des images doivent transmettre l’information utile. Une image purement décorative peut avoir un attribut alt vide afin de ne pas être annoncée inutilement. À l’inverse, une capture d’écran qui explique une procédure a besoin d’une description correspondant à ce que le lecteur doit comprendre, et pas seulement de la mention « capture d’écran ».

3. Examiner les couleurs et les contrastes

La couleur ne doit jamais être le seul moyen d’indiquer une information. Un champ obligatoire signalé uniquement en rouge, un graphique distinguant des séries par la seule couleur ou un lien reconnaissable uniquement par une teinte différente posent problème.

Testez les textes, les boutons, les icônes porteuses de sens et les éléments d’interface dans leurs différents états : normal, survol, focus, désactivé et erreur. Un contraste acceptable dans un bouton au repos peut devenir insuffisant lorsque sa couleur change au survol.

Les outils de contraste donnent une première indication, mais ils ne jugent ni la pertinence du choix des couleurs ni la clarté globale de l’interface. Une page peut respecter un rapport de contraste et rester difficile à lire à cause d’un texte trop petit, d’un interlignage serré ou d’un arrière-plan visuellement chargé.

4. Tester l’agrandissement et l’affichage mobile

Agrandissez le contenu et réduisez la largeur de la fenêtre. Le texte doit rester lisible sans obliger l’utilisateur à faire défiler horizontalement une page entière. Les blocs importants ne doivent pas se chevaucher, et les boutons doivent conserver une zone d’activation utilisable.

Vérifiez les cas souvent oubliés : longues adresses e-mail, mots très longs, tableaux, messages d’erreur, fenêtres de consentement et formulaires en plusieurs étapes. Un design qui fonctionne avec des textes courts peut se briser dès qu’un utilisateur augmente la taille des caractères ou saisit une information inhabituelle.

Formulaires : le point de rupture le plus fréquent

Un formulaire accessible indique clairement ce qui est attendu avant la saisie et explique les erreurs après l’envoi. Chaque champ doit être associé à une véritable étiquette, pas à un texte qui disparaît dès que l’utilisateur commence à écrire.

Contrôlez les éléments suivants :

• l’étiquette décrit précisément la donnée demandée ;
• les champs obligatoires sont signalés de manière compréhensible ;
• le format attendu est indiqué avant la validation ;
• les erreurs sont formulées en toutes lettres et reliées au champ concerné ;
• les données déjà saisies ne sont pas effacées après une erreur ;
• le message de confirmation est perceptible et compréhensible ;
• les groupes de cases à cocher ou de boutons radio possèdent une consigne commune.

Évitez de corriger uniquement par la couleur ou par une icône. Le message « Le numéro de téléphone doit contenir dix chiffres » est plus utile que « Champ invalide ». Lorsque plusieurs erreurs existent, un résumé placé avant le formulaire peut aider l’utilisateur à repérer rapidement ce qui doit être modifié.

Structure HTML et composants interactifs à examiner

Le HTML fournit des informations essentielles aux technologies d’assistance. Une zone principale correctement identifiée, des boutons utilisés pour déclencher une action et des liens utilisés pour changer de page sont plus fiables que des éléments génériques auxquels on ajoute des comportements en JavaScript.

Inspectez en priorité :

• la présence d’une zone principale identifiable et de repères cohérents ;
• la correspondance entre le texte visible et le nom accessible des boutons ;
• les menus déroulants, onglets, accordéons et carrousels ;
• les états dynamiques, comme « ouvert », « sélectionné » ou « chargé » ;
• les contenus injectés après une action, notamment les alertes et erreurs ;
• les tableaux, qui doivent conserver une relation claire entre en-têtes et cellules.

Les attributs ARIA peuvent compléter un composant lorsque le HTML natif ne suffit pas, mais ils ne réparent pas automatiquement une interaction mal conçue. Ajouter un rôle à un élément ne lui donne ni comportement clavier, ni gestion du focus, ni information dynamique. Un bouton HTML correctement utilisé reste souvent préférable à un élément générique transformé artificiellement en bouton.

Ce que les outils automatiques détectent — et ce qu’ils ignorent

Une extension ou un service d’audit peut signaler rapidement des images sans alternative, des champs sans étiquette, certains contrastes insuffisants ou des problèmes de structure. C’est utile pour repérer des motifs répétitifs et établir une première liste de corrections.

Ces outils ne savent toutefois pas déterminer seuls si un texte alternatif est pertinent, si l’ordre de lecture est logique, si une consigne est compréhensible ou si une fonctionnalité peut être menée à son terme au clavier. Un résultat sans erreur ne constitue donc pas une preuve d’accessibilité.

Un ordre de correction pour ne pas se disperser

Classez les problèmes selon leur impact sur un parcours important, leur fréquence et la difficulté de correction. Une erreur qui empêche l’envoi d’un formulaire mérite généralement de passer avant une amélioration esthétique sur une page secondaire.

1. Bloquer les obstacles critiques : éléments impossibles à atteindre au clavier, boutons sans nom compréhensible, formulaires inutilisables ou contenus masqués sans alternative.
2. Corriger les composants réutilisés : menu, fenêtre de consentement, accordéon, lecteur vidéo, champ de recherche ou système de navigation.
3. Améliorer la structure : titres, repères, liens, alternatives textuelles et ordre de lecture.
4. Traiter les détails récurrents : contrastes, états de focus, messages d’erreur et comportements sur mobile.
5. Rejouer les parcours : vérifier qu’une correction n’a pas créé un nouveau blocage.

Notez pour chaque anomalie la page concernée, le composant touché, la situation observée, le niveau de priorité et la correction envisagée. Cette trace évite les diagnostics vagues du type « le site n’est pas accessible » et facilite le travail entre contenu, design et développement.

Quand compléter l’audit avec des utilisateurs et des technologies d’assistance

Un test avec un lecteur d’écran, une navigation à la voix ou des utilisateurs ayant des besoins différents révèle des obstacles qu’un audit technique ne reproduit pas toujours. Il peut notamment montrer qu’un intitulé est ambigu, qu’une notification passe inaperçue ou qu’un parcours demande trop de mémorisation.

Ces essais ne remplacent pas les vérifications de base : faire tester un site ne dispense pas de corriger un bouton inaccessible au clavier ou une absence d’étiquette. Ils ajoutent une dimension d’usage, particulièrement utile pour les services complexes, les démarches en ligne et les interfaces qui évoluent fréquemment.

Pour un premier audit, commencez par un parcours court et concret, documentez chaque blocage, corrigez les composants communs, puis retestez avec plusieurs modes d’interaction. L’accessibilité progresse davantage grâce à cette boucle régulière qu’à une vérification isolée réalisée juste avant la mise en ligne.