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, qu'elles ne puissent pas utiliser une souris, qu'elles aient une basse vision ou un daltonisme, qu'elles soient sourdes ou qu'elles aient une déficience cognitive ou d'apprentissage. Concrètement, cela passe par des choses comme des textes alternatifs pour les images, un contraste de couleurs suffisant, des formulaires aux étiquettes bien reliées et un fonctionnement complet au clavier seul. La norme internationale en la matière est WCAG, les Web Content Accessibility Guidelines du W3C.

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

Pourquoi l'accessibilité est importante quand on construit avec l'IA

Les outils de création IA produisent bien des applications qui ont l'air correctes. L'accessibilité concerne surtout ce qu'une capture d'écran ne montre pas : si un bouton est vraiment un bouton, si un champ a une étiquette qu'un lecteur d'écran peut annoncer, si vous pouvez atteindre le menu avec la touche Tab.

C'est pourquoi il faut le demander :

• C'est facile à manquer. Un menu déroulant au style personnalisé peut paraître parfait et être impossible à utiliser sans souris. Vous ne le remarquerez pas sans le tester.
• C'est moins coûteux si on le fait tôt. Demander des composants accessibles dès la première demande ne coûte presque rien. Rattraper une application terminée oblige à retoucher chaque écran.
• Cela profite à tout le monde. Les sous-titres aident les gens dans les endroits bruyants, un bon contraste aide les personnes qui utilisent leur téléphone en plein soleil, et des étiquettes claires aident tout le monde à remplir les formulaires plus vite.
• Cela recoupe le référencement. Des titres bien structurés, des liens descriptifs et du texte alternatif aident aussi les moteurs de recherche à comprendre vos pages ; voir le SEO pour les sites construits avec l'IA.
• Cela peut être obligatoire. Selon l'endroit où vous exercez et les personnes que vous servez, l'accessibilité peut constituer une obligation légale.

Une analogie du quotidien

Pensez à l'entrée d'un édifice.

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

L'accessibilité web, c'est la même idée pour les espaces numériques : les rampes, la signalisation et les mains courantes de votre application. Et, comme pour un édifice, il est beaucoup plus facile de prévoir une rampe dans les plans que de l'ajouter après que le béton a durci.

WCAG en bref

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

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

Chaque ligne directrice 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, et le niveau que visent la plupart des lois et des politiques.
• Niveau AAA : le niveau le plus élevé. Il est utile de le viser par endroits, mais le W3C ne recommande pas de l'exiger pour des sites entiers, car certains contenus ne peuvent pas l'atteindre.

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 cibles cliquables devraient généralement mesurer au moins 24 par 24 pixels CSS, avec des exceptions ; et Authentification accessible (minimum), qui limite les étapes de connexion reposant sur la mémoire ou des casse-têtes, comme devoir retaper un mot de passe sans pouvoir le coller. Elle a aussi retiré l'ancien critère « Analyse », devenu obsolète.

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 découvre :

Aucune de ces corrections ne change beaucoup l'apparence du formulaire. Toutes changent en revanche la capacité de certaines personnes à l'utiliser.

Termes clés

Idées reçues courantes

• « L'accessibilité ne concerne que les personnes 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 ternes. » L'accessibilité impose quelques contraintes, comme le contraste, les styles de mise au point et la taille du texte ; mais les sites accessibles et esthétiques sont la norme, pas l'exception.
• « Un vérificateur automatique qui affiche 100 signifie que c'est réglé. » Les outils automatisés ne détectent qu'une partie des problèmes. Seule une personne peut vérifier si un texte alternatif est vraiment significatif, ou si un parcours est logique avec un lecteur d'écran.
• « Un module superposé rendra notre site conforme. » Les barres d'outils ajoutées par-dessus ne peuvent pas corriger des étiquettes manquantes ni un accès au clavier défaillant dans votre code. Il faut corriger la source.
• « Nous n'avons aucun utilisateur handicapé. » Vous ne le savez peut-être simplement pas. Beaucoup de handicaps ne se voient pas, et les personnes qui se heurtent à un obstacle partent généralement tout simplement.

Quoi demander à votre outil IA

• « Construis ceci pour respecter WCAG 2.2 au niveau AA. »
• « Utilise du HTML sémantique : de vrais boutons, de vrais liens, des titres dans le bon ordre et une étiquette pour chaque champ de formulaire. »
• « Assure-toi que chaque élément interactif fonctionne avec le clavier seul et possède un style de mise au point visible. »
• « Vérifie le contraste de tous les textes et de toutes les icônes : 4,5:1 pour le texte normal, 3:1 pour le grand texte et les icônes. »
• « Ajoute un texte alternatif pertinent aux images informatives et un texte alternatif vide aux images décoratives. »
• « Affiche les erreurs de formulaire sous forme de texte, relié au champ, et pas seulement avec une couleur. »
• « Respecte le réglage de l'utilisateur sur la réduction des animations. »
• « Lance une vérification d'accessibilité automatisée et dresse la liste de ce qu'elle ne peut pas tester, pour que je le vérifie à la main. »

Testez ensuite vous-même : mettez la souris de côté et essayez de terminer votre parcours principal avec Tab, Maj+Tab, Entrée et Espace seulement. Essayez le lecteur d'écran intégré de votre téléphone sur la page principale. Zoomez le navigateur à 200 % et voyez si quelque chose se brise.

L'accessibilité dans Mythex

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

Pour une liste de vérification pratique, consultez comment rendre votre site accessible. Pour la conception, lisez comment concevoir une application esthétique avec l'IA, et avant le lancement, comment tester votre application avant le lancement. L'aperçu de WCAG du W3C reste la source de référence.

Questions