Des sites et des formulaires que tout le monde peut utiliser.

Les WCAG 2.2 AA en mots simples

Les WCAG sont la norme internationale pour un contenu Web accessible. Le niveau AA est celui que demandent la plupart des lois et des politiques.

Les Règles pour l’accessibilité des contenus Web (WCAG) sont publiées par le W3C. La version 2.2 est devenue une recommandation du W3C dans sa forme actuelle le 12 décembre 2024, et s’appuie sur la version 2.1 : un contenu conforme aux WCAG 2.2 est aussi conforme aux versions 2.1 et 2.0. Chaque règle, appelée critère de succès, a un niveau : A (le minimum), AA (la cible habituelle) et AAA (le plus élevé).

Les critères sont regroupés sous quatre principes. Le contenu doit être :

• Perceptible : les gens peuvent le voir ou l’entendre, quels que soient leurs sens. Textes de remplacement, sous-titres, contraste suffisant.
• Utilisable : les gens peuvent s’en servir, quel que soit l’appareil qu’ils utilisent. Accès au clavier, assez de temps, rien qui clignote dangereusement, navigation claire.
• Compréhensible : les gens peuvent le suivre. Langage simple, comportement prévisible, formulaires qui aident à éviter et à corriger les erreurs.
• Robuste : il fonctionne avec les technologies d’assistance comme les lecteurs d’écran, aujourd’hui et à mesure qu’elles évoluent.

Les WCAG 2.2 ont ajouté des critères, notamment : le focus ne doit pas être masqué, des solutions de rechange aux mouvements de glisser, une taille de cible minimale, une aide cohérente, ne pas demander aux gens de saisir de nouveau une information déjà donnée, et une authentification accessible.

Les correctifs les plus importants

Commencez ici. Chacun élimine un obstacle courant et est à la portée d’une petite équipe sans aide spécialisée.

1. Décrivez les imagesDonnez à chaque image porteuse de sens un court texte de remplacement qui dit ce qu’elle montre ou ce qu’elle fait. Les images décoratives reçoivent un texte de remplacement vide pour que les lecteurs d’écran les ignorent. Un logo qui ramène à l’accueil doit dire « Accueil », et non « logo ».
2. Utilisez de vrais titresBalisez les titres comme des titres, dans l’ordre, plutôt que de mettre du texte en gros et en gras. Les personnes qui utilisent un lecteur d’écran sautent d’un titre à l’autre comme les personnes voyantes survolent une page.
3. Vérifiez le contraste des couleursLe texte normal a besoin d’un rapport de contraste d’au moins 4,5:1 avec son arrière-plan; le grand texte, d’au moins 3:1. Le gris pâle sur blanc échoue habituellement. N’utilisez jamais la couleur seule pour transmettre une information, comme le rouge pour les champs obligatoires.
4. Étiquetez chaque champ de formulaireChaque champ a besoin d’une étiquette visible liée à lui dans le code, et pas seulement d’un texte indicatif qui disparaît quand on tape. Les messages d’erreur doivent dire ce qui ne va pas et comment le corriger.
5. Rendez tout utilisable au clavierTout ce qu’on peut faire à la souris doit être possible avec les touches Tab, Entrée, Espace et les flèches, avec un contour de focus bien visible, et rien ne doit être caché derrière une bannière fixe quand il reçoit le focus.
6. Sous-titrez les vidéos, transcrivez l’audioLes vidéos préenregistrées avec du son ont besoin de sous-titres. Les sous-titres automatiques sont un début, pas une fin : corrigez les noms et les termes clés. Les balados et les fichiers audio ont besoin de transcriptions.
7. Méfiez-vous des PDFUn PDF numérisé est une image de texte que les lecteurs d’écran ne peuvent pas lire. Quand vous le pouvez, publiez l’information sous forme de page Web. Quand il vous faut un PDF, exportez-le à partir d’un document bien structuré, avec des titres et des textes de remplacement, et non à partir d’une numérisation.
8. Faites des boutons assez grandsLes WCAG 2.2 ajoutent une taille de cible minimale : les boutons et les liens devraient mesurer au moins 24 pixels CSS sur 24, ou être assez espacés pour qu’on ne les rate pas. Elles demandent aussi que la connexion ne dépende pas de la mémorisation ou de la transcription d’un code sans aide, par exemple en permettant le collage et les gestionnaires de mots de passe.

Vérifiez vous-même, à peu de frais

Pas besoin de logiciel spécial pour trouver les plus gros problèmes. Il vous faut une heure et les outils que vous avez déjà.

1. Le passage au clavier seulement (15 minutes)

• Rangez la souris. Appuyez sur Tab à partir du haut de votre page d’accueil et de votre formulaire le plus important.
• Voyez-vous où vous êtes à chaque étape? Pouvez-vous atteindre et utiliser chaque lien, bouton, menu et champ? Pouvez-vous sortir de chaque fenêtre contextuelle?
• Envoyez le formulaire avec une erreur. L’erreur est-elle claire, et le focus va-t-il à un endroit logique?

2. Un lecteur d’écran déjà installé (30 minutes)

• Sur iPhone, iPad et Mac : VoiceOver sur iPhone et VoiceOver sur Mac.
• Sur Android : TalkBack.
• Sur Windows : le Narrateur.
• Apprenez d’abord les gestes de base, puis écoutez votre page d’accueil et votre formulaire. Les images ont-elles du sens? Les champs sont-ils annoncés avec leur étiquette? Les boutons disent-ils ce qu’ils font?

3. Un vérificateur automatique gratuit (15 minutes)

• Lighthouse, intégré aux outils de développement de Chrome, et WAVE de WebAIM (en anglais) signalent les textes de remplacement manquants, le contraste insuffisant, les étiquettes manquantes et plus encore.
• Les outils automatiques ne trouvent qu’une partie des problèmes, et un score parfait ne veut pas dire qu’une page est accessible. Utilisez-les en plus des vérifications manuelles ci-dessus, et non à leur place.

Corrigez ce que vous trouvez, en commençant par tout ce qui empêche quelqu’un d’accomplir une tâche : présenter une demande, réserver, payer, vous joindre.

La loi, là où nous l’avons vérifiée

Bien des pays ont des lois contre la discrimination fondée sur le handicap qui peuvent s’appliquer aux sites Web. Voici les règles que nous avons vérifiées à la source.

États-Unis : règle du titre II de l’ADA pour les gouvernements des États et les administrations locales

La règle du département de la Justice en vertu du titre II de l’ADA exige que le contenu Web et les applications mobiles des gouvernements des États et des administrations locales respectent les WCAG 2.1, niveau AA, avec des exceptions limitées. Une règle finale provisoire (Interim Final Rule) publiée le 20 avril 2026 a reporté les dates de conformité :

Respecter les WCAG 2.2 AA, c’est aussi respecter les WCAG 2.1 AA : viser la version 2.2 est donc un bon choix.

Royaume-Uni : règlement sur l’accessibilité dans le secteur public

Le Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 exige que les organismes du secteur public, y compris les administrations locales, respectent les WCAG 2.2 AA (à moins d’une raison juridique valable) et publient une déclaration d’accessibilité. Les organismes de bienfaisance et les autres organisations non gouvernementales en sont exemptés, sauf s’ils sont financés principalement par des fonds publics, s’ils offrent des services essentiels au public ou des services destinés aux personnes handicapées. Tout fournisseur de services au Royaume-Uni a quand même l’obligation de faire des aménagements raisonnables en vertu de l’Equality Act 2010, ou du Disability Discrimination Act 1995 en Irlande du Nord.

Les autres pays où Moraph a des bureaux ont leurs propres lois sur le handicap et l’accessibilité. Nous ne les avons pas résumées ici parce que nous ne les avons pas encore vérifiées à la source.