Comment rendre votre site web accessible : un guide de départ WCAG 2.2

Pour rendre un site web accessible, concevez-le pour qu'on puisse l'utiliser avec un clavier, un lecteur d'écran, le zoom ou un dispositif à commutateur, et pas seulement avec une souris : utilisez de vrais éléments HTML pour les boutons, les liens, les titres et les étiquettes de formulaires, donnez aux images un texte alternatif significatif, gardez un contraste élevé pour le texte et rendez le focus visible. La norme à viser est WCAG 2.2 niveau AA. Les outils automatiques en détectent une partie ; un test de dix minutes au clavier et avec un lecteur d'écran en repère une bonne partie du reste.

Ce que « accessible » signifie concrètement

L'accessibilité concerne des personnes : quelqu'un qui est aveugle et utilise un lecteur d'écran, quelqu'un qui a des tremblements et navigue au clavier, quelqu'un qui a une vue réduite et agrandit à 200 %, quelqu'un qui lit en plein soleil, quelqu'un qui a un poignet cassé temporairement. Une bonne accessibilité tend à améliorer le site pour tout le monde : une structure plus claire, un texte lisible, des formulaires qui expliquent leurs erreurs.

La référence est les Règles pour l'accessibilité des contenus Web (WCAG) du W3C. En septembre 2026, la version actuelle est WCAG 2.2 (publiée en octobre 2023, mise à jour en décembre 2024) ; WCAG 3 est une ébauche préliminaire. WCAG s'organise autour de quatre principes — le contenu doit être perceptible, utilisable, compréhensible et robuste — et comporte trois niveaux de conformité :

Niveau	Ce que cela signifie	Qui vise ce niveau
A	Le minimum ; sans lui, certaines personnes ne peuvent pas du tout utiliser le site	Tout le monde
AA	La cible courante ; couvre le contraste, le focus, le redimensionnement et la gestion des erreurs	La plupart des organisations et de nombreuses lois
AAA	Le plus strict ; impossible à atteindre pour tout contenu	Des services et publics précis

Des lois dans plusieurs pays font référence à WCAG — par exemple l'Acte européen sur l'accessibilité, qui s'applique depuis juin 2025 à de nombreux services numériques destinés aux consommateurs dans l'UE. Les règles qui s'appliquent à vous dépendent de l'endroit où vous exercez et de ce que vous vendez ; consultez un conseiller si vous avez un doute. Ce guide couvre le travail pratique.

Options : comment y arriver

Approche	Convient à	Compromis
Intégrer l'accessibilité dès le départ	Nouveaux sites et apps	Effort total le plus faible ; doit être demandé dès le début
Auditer et corriger	Sites existants	Trouve de vrais problèmes ; exige une révision ciblée page par page
Audit professionnel	Secteurs réglementés, grands sites, organismes publics	Complet et documenté ; coûte de l'argent
Widget de surcouche	Non recommandé	Ne peut pas corriger le code sous-jacent

Pour la plupart des petits sites, les deux premières options suffisent : demandez à l'IA de construire de façon accessible dès le départ, puis auditez avant le lancement.

Les correctifs qui comptent le plus

Utiliser les bons éléments HTML

La plupart de l'accessibilité vient gratuitement avec un HTML correct. Un <button> peut recevoir le focus, fonctionne avec Entrée et Espace, et est annoncé comme un bouton. Un <div> avec un gestionnaire de clic n'a aucune de ces propriétés. Le code généré par l'IA utilise parfois des div stylisés pour tout ; demandez des éléments sémantiques :

<button> pour les actions, <a href> pour la navigation
Un seul <h1> par page, puis <h2>, <h3> dans l'ordre — les utilisateurs de lecteurs d'écran naviguent entre les titres
Des repères : <header>, <nav>, <main>, <footer>
Un <label> relié à chaque champ de formulaire
La langue de la page dans <html lang="fr-CA">

N'utilisez les attributs ARIA que lorsqu'aucun élément natif ne convient — pour un ensemble d'onglets ou une liste combinée personnalisés, par exemple. Un mauvais ARIA est pire que pas d'ARIA du tout.

Accès au clavier et focus visible

Tout ce que vous pouvez faire avec une souris doit fonctionner au clavier seul (WCAG 2.1.1). Parcourez la page avec la touche Tab : chaque lien, bouton et champ doit être accessible dans un ordre logique, et vous devez toujours voir où se trouve le focus (2.4.7 Focus visible). WCAG 2.2 a ajouté que l'élément qui reçoit le focus ne doit pas être complètement masqué derrière un en-tête fixe ou une bannière de témoins (2.4.11, niveau AA).

Échecs courants : des menus qui ne s'ouvrent qu'au survol, des fenêtres modales qui ne retiennent pas le focus ou qu'on ne peut pas fermer avec Échap, et outline: none dans le CSS sans rien pour le remplacer.

Équivalents textuels

Chaque image significative a besoin d'un texte alternatif qui décrit ce qu'elle montre dans son contexte (« Le chef dressant le menu dégustation », et non « image1.jpg »). Les images décoratives reçoivent un alt="" vide pour que les lecteurs d'écran les ignorent. Les boutons qui ne contiennent qu'une icône ont besoin d'un nom accessible (« Fermer », « Rechercher »). Les vidéos ont besoin de sous-titres ; l'audio, d'une transcription.

Couleur et contraste

WCAG 2.2 niveau AA exige un rapport de contraste d'au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte (1.4.3), et 3:1 pour les éléments d'interface tels que les bordures de champs et les icônes significatives (1.4.11). Le texte de substitution gris pâle et les boutons pâles sont les échecs habituels. Ne transmettez jamais un sens par la seule couleur : une bordure rouge sur un champ invalide a besoin aussi d'un message d'erreur.

Redimensionnement et reflux

Le texte doit rester utilisable lorsqu'on l'agrandit à 200 % (1.4.4), et le contenu doit fonctionner sur une largeur de 320 pixels CSS sans défilement latéral (1.4.10). Une mise en page adaptative gère la plupart de ces aspects.

Cibles, formulaires et erreurs

Taille des cibles : WCAG 2.2 niveau AA exige des cibles de pointeur d'au moins 24 par 24 pixels CSS, ou un espacement suffisant autour des plus petites (2.5.8). Plus grand, c'est plus agréable sur téléphone.
Formulaires : étiquettes visibles (et non seulement un texte de substitution), instructions claires, et messages d'erreur qui disent ce qui ne va pas et comment le corriger, à côté du champ.
Connexion : ne faites pas résoudre un casse-tête ni recopier un code sans solution de rechange ; autorisez les gestionnaires de mots de passe et le collage (3.3.8 Authentification accessible).

Requêtes qui fonctionnent

Construis ce site pour respecter WCAG 2.2 niveau AA : repères HTML sémantiques, un seul h1 par page avec des titres dans l'ordre, de vrais éléments button et link, des étiquettes sur chaque champ de formulaire, des styles de focus visibles, un contraste de texte d'au moins 4,5:1, un texte alternatif sur les images significatives et alt="" sur les images décoratives, et html lang défini.

Audite les pages /inscription et /paiement pour l'accessibilité. Vérifie l'utilisation au clavier seul, l'ordre de focus, le focus visible, les étiquettes, les messages d'erreur, le contraste et les noms lus par les lecteurs d'écran pour les boutons à icône. Liste chaque problème avec le critère WCAG correspondant, puis corrige-les sans modifier le design visuel plus que nécessaire.

Le menu mobile ne peut pas être utilisé au clavier. Fais-en un bouton avec aria-expanded, déplace le focus dans le menu à l'ouverture, ferme-le avec Échap et ramène le focus sur le bouton.

Étape par étape

Lancez une vérification automatique. La section Accessibilité de Lighthouse dans les outils de développement de Chrome, ou l'extension de navigateur axe, sur chaque page principale. Corrigez tout ce qu'elles signalent.
Débranchez la souris. Parcourez chaque page avec Tab et effectuez chaque tâche clé — s'inscrire, rechercher, payer. Notez tout ce que vous ne pouvez pas atteindre, dont le focus n'est pas visible ou dont vous ne pouvez pas sortir.
Agrandissez à 200 % et réduisez la fenêtre à la largeur d'un téléphone. Rien ne doit être coupé ni exiger de défilement latéral.
Essayez un lecteur d'écran pendant dix minutes : VoiceOver sur Mac et iPhone, TalkBack sur Android, ou NVDA sous Windows (gratuit). Écoutez les titres, les liens et les champs de formulaire. « Bouton » sans nom, ou « lien, cliquez ici », signifie du travail à faire.
Vérifiez le contraste du texte, des boutons et des champs avec un vérificateur de contraste.
Corrigez, puis retestez les mêmes tâches.
Publiez une déclaration d'accessibilité qui indique la norme visée et comment signaler un problème — et répondez à ces signalements.

Erreurs courantes

Se fier à un widget de surcouche au lieu de corriger le code.
Supprimer les contours de focus parce qu'ils paraissent peu soignés, sans les remplacer.
Utiliser le texte de substitution comme seule étiquette. Il disparaît dès que quelqu'un commence à écrire et il est souvent de faible contraste.
Les liens « cliquez ici » et « Lire la suite ». Hors contexte, les utilisateurs de lecteurs d'écran entendent une liste de liens identiques.
Bourrer le texte alternatif de mots-clés. Le texte alternatif est pour les personnes ; décrivez l'image.
Tester une seule fois. Chaque nouvelle fonction peut casser l'accès au clavier. Ajoutez une passe au clavier à vos tests avant lancement.

Liste de contrôle d'accessibilité

Vérification automatique (Lighthouse ou axe) propre sur les pages principales
Chaque tâche peut être effectuée au clavier seul
Le focus est toujours visible et jamais masqué derrière des éléments fixes
Titres, repères, boutons et liens sémantiques ; lang défini
Texte alternatif significatif ; images décoratives en alt="" ; sous-titres sur les vidéos
Contraste du texte ≥ 4,5:1 (grand texte ≥ 3:1) ; éléments d'interface ≥ 3:1
Fonctionne à 200 % de zoom et sur 320 px de largeur
Chaque champ de formulaire a une étiquette visible et des messages d'erreur clairs
Déclaration d'accessibilité avec un moyen de signaler les problèmes

Pour les concepts qui sous-tendent tout cela, lisez qu'est-ce que l'accessibilité web. La conception accessible et la bonne conception se recoupent beaucoup ; comment concevoir une app esthétique avec l'IA couvre l'aspect visuel.

L'accessibilité sur Mythex

Mythex construit selon la norme que vous demandez ; mettez donc « WCAG 2.2 AA » dans votre première requête et dans les suivantes. Vous pouvez utiliser le cadre de taille téléphone de l'aperçu pour vérifier les petits écrans (Aperçu et code), mais les tests au clavier, au zoom et avec un lecteur d'écran fonctionnent mieux sur l'URL publiée ou sur un aperçu ouvert dans son propre onglet. Demandez à l'agent d'auditer une page, de corriger ce qu'il trouve, puis testez vous-même les corrections : une vérification automatique est un début, et non une approbation finale.

Questions

Quelle est la norme d'accessibilité actuelle pour les sites web ?

En septembre 2026, la norme actuelle du W3C est WCAG 2.2, publiée pour la première fois en octobre 2023. La plupart des organisations et de nombreuses lois visent le niveau AA. WCAG 3 en est encore à une ébauche préliminaire.

Une surcouche d'accessibilité peut-elle rendre mon site conforme ?

Ne vous y fiez pas. Ces surcouches ajoutent une barre d'outils par-dessus la page, mais elles ne peuvent pas corriger les étiquettes manquantes, l'accès au clavier défaillant ou une structure médiocre dans le code sous-jacent. C'est la correction du site lui-même qui le rend utilisable.

Les outils de vérification automatiques trouvent-ils tous les problèmes ?

Non. Des outils comme Lighthouse et axe repèrent des éléments tels que le texte alternatif manquant, le faible contraste et les champs sans étiquette, mais beaucoup de problèmes — un ordre de focus déroutant, un texte de lien vide de sens, un texte alternatif présent mais erroné — exigent une personne qui vérifie au clavier et avec un lecteur d'écran.

Quel rapport de contraste WCAG exige-t-il ?

WCAG 2.2 niveau AA exige au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte, ainsi que 3:1 pour les composants d'interface utilisateur tels que les bordures de champs de saisie et les icônes qui transmettent un sens.