Qu'est-ce que l'accessibilité web ? WCAG et conception inclusive expliqués

L'accessibilité web consiste à construire des sites et des applications que les personnes handicapées peuvent utiliser — qu'elles soient aveugles et utilisent un lecteur d'écran, ne puissent pas utiliser de souris, aient une basse vision ou un daltonisme, soient sourdes, ou aient un handicap cognitif ou d'apprentissage. Concrètement, cela passe par des choses comme des alternatives textuelles pour les images, un contraste de couleurs suffisant, des formulaires aux libellés corrects, et un fonctionnement complet au seul clavier. La norme internationale en la matière est le WCAG, les Web Content Accessibility Guidelines publiées par le W3C.

L'accessibilité est souvent abrégée en a11y : « a », puis 11 lettres, puis « y ».

Pourquoi l'accessibilité compte quand on crée avec l'IA

Les outils de création par IA savent très bien produire des applications qui semblent correctes. L'accessibilité concerne surtout ce qu'on ne voit pas sur une capture d'écran : un bouton est-il vraiment un bouton, un champ a-t-il un libellé qu'un lecteur d'écran peut annoncer, peut-on atteindre le menu avec la touche Tab ?

C'est pourquoi il est important de se poser ces questions :

• C'est facile à manquer. Une liste déroulante au style personnalisé peut sembler parfaite et être impossible à utiliser sans souris. Vous ne le remarquerez pas sans le tester.
• C'est moins coûteux si l'on s'en occupe tôt. Demander des composants accessibles dès le premier prompt ne coûte presque rien. Rattraper une application terminée oblige à toucher à chaque écran.
• Cela profite à tout le monde. Les sous-titres aident les personnes dans des lieux bruyants, un bon contraste aide les utilisateurs de téléphone en plein soleil, et des libellés clairs permettent à tous de remplir les formulaires plus vite.
• Cela recoupe le référencement. Des titres bien structurés, des liens descriptifs et des textes alternatifs aident aussi les moteurs de recherche à comprendre vos pages — voir le SEO pour les sites créés avec l'IA.
• Cela peut être obligatoire. Selon le pays où vous opérez et les publics que vous servez, l'accessibilité peut être une obligation légale.

Une analogie du quotidien

Pensez à l'entrée d'un bâtiment.

Les marches conviennent à beaucoup de personnes. Une rampe sert aux personnes en fauteuil roulant — mais aussi aux parents avec une poussette, aux livreurs avec un diable et aux voyageurs avec leurs valises. Les portes automatiques, une signalétique claire, le braille sur les boutons d'ascenseur et un bon éclairage suppriment chacun un obstacle pour quelqu'un.

L'accessibilité web applique la même idée aux espaces numériques : les rampes, les panneaux et les mains courantes de votre application. Et comme pour un bâtiment, il est bien plus simple de prévoir une rampe dans les plans que d'en ajouter une une fois le béton coulé.

Le WCAG en bref

Le WCAG est publié par l'Initiative pour l'accessibilité du web (WAI) du W3C. La version actuelle est le WCAG 2.2, publiée pour la première fois en octobre 2023. Elle est rétrocompatible : un contenu conforme au WCAG 2.2 l'est aussi aux versions 2.1 et 2.0, et le W3C encourage à utiliser la dernière version. Le WCAG 2.2 est également approuvé comme norme internationale, ISO/IEC 40500:2025. Un WCAG 3, très différent, est en cours d'élaboration sous forme de premier brouillon, et non de norme achevée.

Le WCAG s'organise autour de quatre principes, souvent résumés par l'acronyme POUR :

Chaque recommandation comporte des critères de succès vérifiables, à trois niveaux :

• Niveau A — le minimum. Ne pas les respecter bloque complètement certaines personnes.
• Niveau AA — la cible standard, celle à laquelle renvoient la plupart des lois et des politiques.
• Niveau AAA — le niveau le plus élevé. Il est parfois utile de viser ce niveau, mais le W3C ne recommande pas de l'exiger pour des sites entiers, car certains contenus ne peuvent pas l'atteindre.

Le WCAG 2.2 a ajouté neuf critères de succès à la version 2.1, dont Taille de la cible (minimum) au niveau AA — les zones cliquables doivent en général mesurer au moins 24 × 24 pixels CSS, avec des exceptions — et Authentification accessible (minimum), qui limite les étapes de connexion reposant sur la mémoire ou sur des énigmes, comme devoir retaper un mot de passe sans pouvoir le coller. Il a aussi retiré l'ancien critère « Analyse syntaxique », devenu obsolète.

Un exemple concret : un formulaire d'inscription

Voici un formulaire d'inscription qu'une IA pourrait produire, et ce qu'une vérification d'accessibilité y trouve :

Aucune de ces corrections ne change beaucoup l'apparence du formulaire. Toutes changent la possibilité, pour certaines personnes, de l'utiliser tout court.

Termes clés

Idées reçues courantes

• « L'accessibilité ne concerne que les utilisateurs aveugles. » Elle couvre les handicaps visuels, moteurs, auditifs, de la parole et cognitifs, ainsi que les situations temporaires comme un bras cassé.
• « Les sites accessibles sont austères. » L'accessibilité impose quelques contraintes — contraste, styles de focus, taille du texte —, mais les sites accessibles et esthétiques sont la norme, pas l'exception.
• « Un outil automatique affiche 100, donc c'est terminé. » Les outils automatiques ne détectent qu'une partie des problèmes. Savoir si un texte alternatif est réellement pertinent, ou si un parcours a du sens avec un lecteur d'écran, demande une vérification humaine.
• « Un widget de surcouche nous rendra conformes. » Une barre d'outils ajoutée par-dessus ne peut pas corriger des libellés manquants ou un accès clavier défaillant dans votre code. Corrigez la source.
• « Nous n'avons aucun utilisateur handicapé. » Vous ne le savez peut-être pas. Beaucoup de handicaps ne se voient pas, et les personnes qui rencontrent un obstacle partent généralement simplement.

Quoi demander à votre outil de création par IA

• « Construis ceci pour respecter le WCAG 2.2 niveau AA. »
• « Utilise du HTML sémantique : de vrais boutons, de vrais liens, des titres dans l'ordre, et un libellé pour chaque champ de formulaire. »
• « Assure-toi que chaque élément interactif fonctionne uniquement au clavier et possède un style de focus visible. »
• « Vérifie le contraste de toutes les couleurs de texte et d'icônes — 4,5:1 pour le texte normal, 3:1 pour le grand texte et les icônes. »
• « Ajoute des textes alternatifs pertinents aux images informatives et des textes alternatifs vides aux images décoratives. »
• « Affiche les erreurs de formulaire sous forme de texte, reliées au champ, et pas seulement par la couleur. »
• « Respecte le réglage de mouvement réduit de l'utilisateur pour les animations. »
• « Lance une vérification automatique de l'accessibilité et liste ce qu'elle ne peut pas tester, afin que je le vérifie à la main. »

Testez ensuite vous-même : écartez la souris et essayez de réaliser votre parcours principal uniquement avec Tab, Maj+Tab, Entrée et Espace. Essayez le lecteur d'écran intégré de votre téléphone sur la page principale. Zoomez le navigateur à 200 % et vérifiez que rien ne se casse.

L'accessibilité dans Mythex

Mythex n'inclut pas de vérificateur d'accessibilité dédié : traitez donc l'accessibilité comme une partie de vos prompts et de vos tests. Demandez le WCAG 2.2 AA dès le premier prompt, vérifiez le résultat dans l'aperçu au clavier, et utilisez /test pour que l'agent parcourt vos principaux parcours avant la publication — voir Tests d'application. La recette SEO demande aussi des titres sémantiques et des textes alternatifs pertinents, ce qui sert les deux objectifs.

Pour une liste de contrôle pratique, voir comment rendre votre site accessible. Pour le design, lisez comment concevoir une application esthétique avec l'IA, et avant le lancement, comment tester votre application avant le lancement. La présentation du WCAG par le W3C reste la source de référence.

Questions