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

Pour rendre un site web accessible, concevez-le pour qu'il puisse être utilisé au clavier, avec un lecteur d'écran, en zoom ou avec un dispositif à commutateur, et pas seulement à la souris : utilisez de vrais éléments HTML pour les boutons, les liens, les titres et les étiquettes de formulaire ; donnez aux images des textes alternatifs pertinents ; gardez un contraste élevé pour le texte et rendez le focus visible. La norme à viser est WCAG 2.2 niveau AA. Les outils de vérification automatique détectent une partie du problème ; un test de dix minutes au clavier et avec un lecteur d'écran en révèle une bonne part du reste.

Ce que « accessible » signifie concrètement

L'accessibilité concerne des personnes : une personne aveugle qui utilise un lecteur d'écran, une personne qui tremble et navigue au clavier, une personne malvoyante qui zoome à 200 %, une personne qui lit en plein soleil, une personne avec un bras temporairement cassé. Une bonne accessibilité rend généralement un site meilleur pour tout le monde : structure plus claire, texte lisible, formulaires qui expliquent leurs erreurs.

La référence est celle des Web Content Accessibility Guidelines (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 n'en est qu'à un premier projet. 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 tous les contenus	Services et publics spécifiques

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 vous concernent dépendent de votre zone d'activité et de ce que vous vendez ; en cas de doute, consultez un conseiller. Ce guide traite du travail pratique.

Options : comment y parvenir

Approche	Adaptée à	Compromis
Intégrer l'accessibilité dès le départ	Nouveaux sites et applications	Le moins d'effort au total ; il faut le prévoir dès le début
Auditer et corriger	Sites existants	Trouve de vrais problèmes ; demande un passage ciblé par page
Audit professionnel	Secteurs réglementés, grands sites, organismes publics	Complet et documenté ; a un coût
Widget de superposition	Non recommandé	Ne peut pas corriger le code sous-jacent

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

Les corrections les plus importantes

Utiliser les bons éléments HTML

L'essentiel de l'accessibilité vient gratuitement avec un HTML correct. Un <button> est focalisable, fonctionne avec Entrée et Espace, et est annoncé comme bouton. Une <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ées 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 d'un titre à l'autre
Des repères : <header>, <nav>, <main>, <footer>
Un <label> relié à chaque champ de formulaire
La langue de la page dans <html lang="fr">

N'utilisez les attributs ARIA que lorsqu'aucun élément natif ne convient — par exemple pour un ensemble d'onglets ou une combobox personnalisée. Un mauvais ARIA est pire que rien.

Accès au clavier et focus visible

Tout ce qui peut se faire à la souris doit fonctionner au clavier seul (WCAG 2.1.1). Parcourez la page avec Tab : chaque lien, bouton et champ doit être atteignable dans un ordre logique, et vous devez toujours voir où se trouve le focus (2.4.7 Focus visible). WCAG 2.2 ajoute que l'élément focalisé ne doit pas être entièrement masqué par un en-tête collant ou une bannière de cookies (2.4.11, niveau AA).

Échecs courants : des menus qui ne s'ouvrent qu'au survol, des fenêtres modales qui ne piègent pas le focus ou ne peuvent pas être fermées avec Échap, et outline: none dans le CSS sans rien pour le remplacer.

Alternatives textuelles

Chaque image porteuse de sens a besoin d'un texte alternatif qui décrit ce qu'elle montre dans son contexte (« Le chef dresse 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 doivent avoir des sous-titres ; l'audio, une transcription.

Couleur et contraste

WCAG 2.2 niveau AA exige un ratio de contraste d'au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte (1.4.3), ainsi que 3:1 pour les éléments d'interface comme les bordures de champs et les icônes porteuses de sens (1.4.11). Le texte d'espace réservé gris clair et les boutons pâles sont les échecs les plus fréquents. Par ailleurs, ne transmettez jamais une information par la seule couleur : une bordure rouge sur un champ invalide a aussi besoin d'un message d'erreur.

Redimensionnement et reflow

Le texte doit rester utilisable lorsqu'on zoome à 200 % (1.4.4), et le contenu doit fonctionner à une largeur de 320 pixels CSS sans défilement horizontal (1.4.10). Une mise en page adaptative gère l'essentiel de cela.

Zones cliquables, formulaires et erreurs

Taille des cibles : WCAG 2.2 niveau AA exige des zones de pointage d'au moins 24 sur 24 pixels CSS, ou un espacement suffisant autour des plus petites (2.5.8). Plus grand, c'est plus confortable sur téléphone.
Formulaires : étiquettes visibles (et non seulement un texte d'espace réservé), instructions claires, et messages d'erreur qui indiquent ce qui ne va pas et comment le corriger, à côté du champ.
Connexion : ne demandez pas de résoudre une énigme ou de recopier un code sans alternative ; autorisez les gestionnaires de mots de passe et le collage (3.3.8 Authentification accessible).

Prompts 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, des textes alternatifs sur les images porteuses de sens et alt="" sur les images décoratives, et l'attribut lang du html défini.

Audite les pages /signup et /checkout 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 le lecteur d'écran pour les boutons à icône. Liste chaque problème avec le critère WCAG correspondant, puis corrige-les sans modifier davantage le design visuel 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 renvoie 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'elle signale.
Débranchez la souris. Parcourez chaque page avec Tab et réalisez chaque tâche clé — inscription, recherche, paiement. Notez tout ce que vous ne pouvez pas atteindre, dont le focus n'est pas visible, ou dont vous ne pouvez pas sortir.
Zoomez à 200 % et réduisez la fenêtre à la largeur d'un téléphone. Rien ne doit être coupé ni nécessiter de défilement horizontal.
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. Un « bouton » sans nom, ou un « lien, cliquez ici », signifie qu'il reste du travail.
Vérifiez le contraste du texte, des boutons et des champs avec un outil de vérification du contraste.
Corrigez, puis retestez les mêmes tâches.
Publiez une déclaration d'accessibilité indiquant la norme visée et la façon de signaler un problème — et répondez à ces signalements.

Erreurs courantes

Se fier à un widget de superposition au lieu de corriger le code.
Supprimer les contours de focus parce qu'ils paraissent peu esthétiques, sans rien pour les remplacer.
Le texte d'espace réservé comme seule étiquette. Il disparaît dès que la personne commence à écrire et il est souvent peu contrasté.
Les liens « cliquez ici » et « En savoir plus ». Hors contexte, les utilisateurs de lecteurs d'écran entendent une liste de liens identiques.
Des textes alternatifs bourrés de mots-clés. Le texte alternatif s'adresse aux personnes ; décrivez l'image.
Ne tester qu'une fois. Chaque nouvelle fonction peut casser l'accès au clavier. Ajoutez un passage au clavier à vos tests avant lancement.

Liste de contrôle d'accessibilité

Vérification automatique (Lighthouse ou axe) sans erreur sur les pages principales
Chaque tâche peut être réalisée au clavier seul
Le focus est toujours visible et jamais masqué par des éléments collants
Titres, repères, boutons et liens sémantiques ; lang défini
Textes alternatifs pertinents ; 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 à un zoom de 200 % et à une largeur de 320 px
Chaque champ de formulaire a une étiquette visible et des messages d'erreur clairs
Une déclaration d'accessibilité avec un moyen de signaler les problèmes

Pour les concepts sous-jacents, lisez qu'est-ce que l'accessibilité web. Le design accessible et le bon design se recoupent beaucoup ; comment concevoir une application esthétique avec l'IA traite de l'aspect visuel.

L'accessibilité sur Mythex

Mythex construit selon la norme que vous demandez : mettez « WCAG 2.2 AA » dans votre premier prompt et dans les demandes 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, de 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, pas une validation 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 n'en est encore qu'à un premier projet.

Un widget d'accessibilité peut-il rendre mon site conforme ?

Ne vous y fiez pas. Ces widgets ajoutent une barre d'outils par-dessus la page, mais ne peuvent pas corriger les étiquettes manquantes, un clavier inopérant ou une structure défaillante dans le code sous-jacent. C'est la correction du site lui-même qui le rend utilisable.

Les outils de vérification automatique détectent-ils tous les problèmes ?

Non. Des outils comme Lighthouse et axe repèrent des éléments tels que les textes alternatifs manquants, les contrastes faibles et les champs sans étiquette, mais de nombreux problèmes — un ordre de focus déroutant, un texte de lien dénué de sens, un texte alternatif présent mais erroné — demandent une vérification humaine au clavier et avec un lecteur d'écran.

Quel ratio de contraste exige WCAG ?

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 comme les bordures de champs de saisie et les icônes porteuses de sens.