Checklist accessibilité web 2026 : quoi vérifier, dans quel ordre et comment garder le site corrigé

D’où vient une checklist accessibilité web

Une checklist accessibilité web vaut ce que vaut la norme qui la fonde, et pour le web cette norme est WCAG, les règles pour l’accessibilité des contenus web du W3C. La version 2.2 est devenue une Recommandation du W3C le 5 octobre 2023. Elle a ajouté neuf critères de succès et supprimé le critère 4.1.1 Parsing, que le W3C déclare obsolète. GOV.UK, par exemple, évalue ses services publics au niveau AA, et cette liste suit le même niveau.

La liste sert à trouver des problèmes ; ce n’est pas un certificat. La page Easy Checks du W3C précise elle-même que ces contrôles rapides ne couvrent que quelques points et que les réussir ne prouve pas qu’une page est accessible. Rien de tout cela n’est un avis juridique : savoir si une loi s’applique à votre entreprise est une question pour un avocat qui connaît votre pays.

Les six défauts présents sur presque toutes les pages d’accueil

Le WebAIM Million est une analyse automatique annuelle d’un million de pages d’accueil. Pour 2026, elle indique que 95,9 % des pages présentaient des échecs WCAG détectés, avec 56,1 erreurs par page en moyenne. Six problèmes dominent : un texte trop peu contrasté sur 83,9 % des pages, une alternative textuelle absente sur 53,1 %, des champs sans étiquette sur 51 %, des liens vides sur 46,3 %, des boutons vides sur 30,6 % et une langue du document non indiquée sur 13,5 %.

Aucun de ces défauts n’exige une refonte. Ce sont des habitudes dans la façon de fabriquer les gabarits et les contenus : un bouton qui ne contient qu’une icône, un lien qui ne contient qu’une image, un texte gris sur un gris plus clair.

Images, titres, titres de page et langue : les contrôles de contenu

Commencez par les images. Les Easy Checks du W3C demandent si chaque image a une courte description textuelle qui en transmet la fonction, car une personne qui utilise un lecteur d’écran ne la voit pas. WebAIM ajoute qu’une image décorative doit porter un attribut alt vide pour être ignorée, et qu’une image qui est aussi un lien doit avoir un texte indiquant où il mène.

Viennent ensuite le titre de la page et les intertitres. Le titre apparaît dans l’onglet du navigateur et fait partie des premières choses qu’annonce un lecteur d’écran, donc chaque page a besoin du sien. Les intertitres doivent fonctionner comme une table des matières, car les utilisateurs de lecteurs d’écran naviguent souvent par eux. WebAIM demande de vrais éléments de titre, pas du gras en gros caractères, et des titres informatifs : trois sections intitulées Détails n’apprennent rien à personne.

Puis la langue de la page. Un attribut lang sur l’élément html permet à la technologie d’assistance de prononcer correctement les mots. L’analyse citée plus haut l’a trouvé absent sur 13,5 % des pages d’accueil, ce qui en fait l’une des corrections les moins chères de la liste.

Contraste, liens et zoom : les contrôles que l’on peut mesurer

Le contraste est l’endroit où la liste donne des chiffres. Le résumé de WCAG par WebAIM indique 4,5:1 pour le texte normal et 3:1 pour le grand texte au niveau AA, et 3:1 pour les icônes, les champs de formulaire et les indicateurs de focus. Un lien qui ne se distingue du texte voisin que par la couleur doit offrir 3:1 par rapport à ce texte, plus un autre indice, comme un soulignement au survol et au focus.

Le zoom est le deuxième contrôle mesurable. Les Easy Checks demandent que le texte et les images grossissent au zoom et restent lisibles et utilisables. Essayez la page avec un fort agrandissement et sur un téléphone, et repérez le texte coupé, les boutons qui se chevauchent ou un menu qu’on ne peut plus ouvrir.

Clavier, focus et taille des cibles : utiliser le site sans souris

Posez la souris et appuyez sur Tab. WCAG demande que toute la fonctionnalité soit utilisable au clavier et que le focus ne reste jamais piégé sur un élément, et les Easy Checks ajoutent un indicateur visible qui se déplace à chaque pression. Le premier arrêt devrait être un lien d’évitement qui saute le menu jusqu’au contenu principal.

WCAG 2.2 a affiné ce domaine. Le critère 2.4.11 dit qu’un élément qui a le focus ne doit pas être entièrement masqué par un autre contenu, ce que fait précisément un en-tête fixe ou un widget de discussion avec le champ où vous écrivez. Le critère 2.5.8 demande des cibles de pointeur d’au moins 24 sur 24 pixels CSS, sauf si elles sont suffisamment espacées. Le critère 2.5.7 demande une alternative à un seul pointeur pour toute action de glisser, comme un curseur qu’on peut aussi régler avec des boutons.

L’ordre du focus compte autant que sa visibilité. WebAIM cite le 2.4.3, un ordre logique et intuitif, et le 3.2.1 : recevoir le focus ne doit pas provoquer de changement important dans la page. Notez chaque endroit où vous perdez le fil de votre position.

Formulaires et vidéo : étiquettes, erreurs, sous-titres et transcriptions

Les formulaires sont l’endroit où un visiteur devient client. Chaque champ a besoin d’un texte visible qui dit quoi saisir, relié au champ dans le code, ce que WebAIM range sous les critères 1.3.1 et 3.3.2. Les champs obligatoires doivent être signalés, et les erreurs identifiées clairement, avec une suggestion pour les corriger. Les champs qui collectent des données personnelles courantes doivent porter l’attribut autocomplete adapté, selon le 1.3.5.

WCAG 2.2 a ajouté deux règles qui touchent les formulaires. La Saisie redondante, 3.3.7, dit qu’on ne doit pas obliger quelqu’un à ressaisir une information déjà fournie dans le même processus. L’Authentification accessible, 3.3.8, dit qu’une étape de connexion ne doit pas dépendre d’un test cognitif sans alternative ni aide.

La vidéo et l’audio ont leurs propres contrôles. Une vidéo préenregistrée a besoin de sous-titres synchronisés selon le 1.2.2, un contenu audio seul a besoin d’une transcription, et quand une information visuelle importante manque à la bande-son, la vidéo a besoin d’audiodescription. Les Easy Checks décrivent les sous-titres comme un texte synchronisé de la parole et des sons importants qui ne sont pas de la parole.

Tests avec des outils, au clavier et au lecteur d’écran, puis à chaque version

Les outils automatiques couvrent beaucoup de pages vite, et ils ne suffisent pas. Le manuel de service de GOV.UK dit que vous passerez à côté de certains problèmes si vous ne faites que des tests automatiques, et le W3C affirme que les outils ne peuvent pas tout faire et donnent parfois de faux résultats.

Ensuite, utilisez le site comme le ferait une personne avec une technologie d’assistance. GOV.UK attend des tests avec des lecteurs d’écran et des logiciels de reconnaissance vocale et recommande de les faire soi-même quand c’est possible. Il n’est pas nécessaire de tout tester : le guide de GOV.UK conseille de prendre un échantillon qui reflète la variété des contenus et des fonctions.

Un site corrigé ne le reste pas tout seul. Selon le même manuel, il faut lancer les tests à chaque ajout de fonctionnalité, et il en va de même pour un bandeau, un nouveau formulaire ou une extension. Le guide de GOV.UK pour les sites du secteur public demande aussi une déclaration d’accessibilité en langage clair, révisée au moins une fois par an ; demandez à un spécialiste si une règle de ce genre vous concerne.

Commander des corrections d’accessibilité : quoi préparer et ce que vous recevez

Sur un petit site, vous pouvez parcourir cette liste vous-même en quelques jours. Préparez l’adresse du site, une liste de gabarits clés, comme la page d’accueil, une page de contenu, un formulaire et le paiement, ainsi que les résultats de vos contrôles ou d’un audit que vous avez déjà.

VITON13 Studio propose ce travail en deux forfaits. Les corrections d’accessibilité signifient que les problèmes de l’audit sont corrigés dans votre code et votre contenu : changements dans les gabarits et le code, corrections comme les alternatives textuelles, les titres et les noms de liens, et un nouveau test après les changements. Avant de payer, vous recevez une ébauche gratuite : un gabarit corrigé, montré sur une copie de test de votre site. Le prix est fixe, à partir de 213 $, et le travail prend de 7 à 15 jours ouvrés.

Le suivi d’accessibilité couvre ce qu’une liste ponctuelle ne peut pas faire : les nouvelles pages restent accessibles pendant que le site évolue. Il comprend un nouveau contrôle mensuel des pages nouvelles et modifiées et un court rapport de ce qu’il faut corriger, et les corrections sont chiffrées à part quand de nouveaux problèmes apparaissent. Il coûte 13 $/mois et se résilie avec un préavis de 30 jours, et son ébauche gratuite est un rapport d’exemple sur une page de votre site. Savoir si le résultat suffit pour une exigence légale reste une question pour votre avocat.