WCAG 2.2 AA : L'Accessibilité N'est Pas une Option
Concevoir pour Tous, sans Compromis sur l'Esthétique
Sommaire
1,3 milliard de personnes. Vous les ignorez encore ?
Selon l'Organisation mondiale de la sante, 16% de la population mondiale vit avec un handicap significatif. En France, 12 millions de personnes sont en situation de handicap. Et pourtant, en 2026, moins de 3% des sites web français sont conformes aux standards d'accessibilité. Ce n'est pas un problème technique. Les outils existent. Les standards sont documentes. Les frameworks modernes le supportent nativement. C'est un problème de culture design. L'accessibilité est encore perçue comme une contrainte, un ajout, une case a cocher en fin de projet. Je le dis clairement : cette vision est obsolete, moralement discutable, et désormais illégale en Europe.
L'accessibilité n'est pas ce que vous faites pour "les autres". C'est ce que vous faites pour tout le monde, y compris votre futur vous-meme.
WCAG : le standard mondial, pas une recommandation
Les Web Content Accessibility Guidelines (WCAG) sont publiees par le W3C et constituent le standard de référence mondial pour l'accessibilité du contenu web. Ce ne sont pas des suggestions. Dans de nombreuses juridictions, y compris l'Union Européenne et les États-Unis, elles ont force de loi. Le standard est organise en trois niveaux de conformité : A (minimum), AA (standard recommande), et AAA (optimal). Le niveau AA est celui que la législation européenne impose. Il représente l'équilibre entre exigence et faisabilité. Les WCAG reposent sur quatre principes fondamentaux -- POUR : Percevable, Operable, Understandable (compréhensible), Robust. Chaque critère de succes est rattâche à l'un de ces principes.
Niveau A : le strict minimum. Ne pas le respecter crée des barrières infranchissables.
Niveau AA : le standard impose par la loi européenne et la plupart des législations. C'est votre objectif.
Niveau AAA : l'ideal, rarement atteint integralement, mais a viser pour les fonctionnalités critiques.
Les 4 principes POUR sont le cadre conceptuel : chaque décision de design devrait être évaluée à travers eux.
Niveaux de conformite WCAG
WCAG 2.2 : les 9 nouveaux critères qui changent la donne
WCAG 2.2, publie en octobre 2023, apporte 9 nouveaux critères de succes et en retire un (4.1.1 Parsing, devenu obsolete avec HTML5). Ces ajouts ne sont pas mineurs. Ils adressent des problèmes reels que les versions précédentes ignoraient, notamment autour de la navigation mobile, du contrôle moteur, et de l'authentification. Les changements les plus impactants pour les désigners sont les critères sur la taille des cibles (2.5.8), l'apparence du focus (2.4.11/2.4.12), les mouvements de glissement (2.5.7), et l'aide accessible (3.3.7). Ces critères traduisent enfin en norme ce que les bons désigners faisaient déjà par intuition.
2.4.11 Focus Not Obscured (Minimum) [AA] : le focus clavier ne doit pas etre completement cache par d'autres elements.
2.4.12 Focus Not Obscured (Enhanced) [AAA] : le focus ne doit pas etre partiellement cache non plus.
2.4.13 Focus Appearance [AAA] : le focus doit avoir un indicateur visible de taille et contraste suffisants.
2.5.7 Dragging Movements [AA] : toute fonctionnalite utilisant le glissement doit offrir une alternative par clic simple.
2.5.8 Target Size (Minimum) [AA] : les cibles interactives doivent faire au moins 24x24 CSS pixels.
3.2.6 Consistent Help [A] : les mecanismes d'aide doivent etre au meme endroit sur chaque page.
3.3.7 Redundant Entry [A] : ne pas demander a l'utilisateur de re-saisir des informations deja fournies.
3.3.8 Accessible Authentication (Minimum) [AA] : pas de tests cognitifs (captcha complexe) comme unique methode d'authentification.
3.3.9 Accessible Authentication (Enhanced) [AAA] : pas de reconnaissance d'objets ou de contenu personnel.
Percevable : si l'utilisateur ne le voit pas, il n'existe pas
Le premier principe WCAG exige que toute information et tout composant d'interface soit presentable de manière perceptible pour tous les utilisateurs. Cela signifie fournir des alternatives textuelles pour le contenu non textuel, des sous-titres pour les medias audiovisuels, et un contenu adaptable a différents modes de présentation. Ce principe est le plus viole dans la pratique. Des images sans attribut alt, des videos sans sous-titres, des informations transmises uniquement par la couleur -- ces erreurs sont omniprésentes. Et elles ne sont pas de simples oublis techniques. Elles révèlent une incapacité a penser au-dela de sa propre expérience sensorielle.
Un alt="image" ou alt="photo" est pire qu'un alt vide. Si vous ne décrivez pas ce que l'image communique, vous ajoutez du bruit pour les lecteurs d'écran sans apporter de valeur.
Textes alternatifs : décrivez la fonction, pas l'apparence. "Bouton d'envoi du formulaire", pas "fleche bleue".
Contraste : ratio minimum de 4.5:1 pour le texte normal, 3:1 pour le texte large (>18pt ou >14pt bold).
Couleur : ne jamais utiliser la couleur comme seul vecteur d'information. Ajoutez du texte, des icones, des patterns.
Redimensionnement : le contenu doit rester fonctionnel a 200% de zoom sans perte d'information.
Operable : chaque action doit être executable par tous
Le principe d'opérabilité exige que tous les composants d'interface et la navigation soient utilisables. Concrètement : tout doit être accessible au clavier, les utilisateurs doivent avoir assez de temps pour lire et interagir, le contenu ne doit pas provoquer de crises épileptiques, et la navigation doit être prévisible. Les pieges au clavier sont l'un des problèmes les plus graves : quand un utilisateur naviguant au clavier entre dans un composant (modale, menu deroulant, widget personnalise) et ne peut plus en sortir. C'est l'équivalent numérique d'enfermer quelqu'un dans une piece. Les animations automatiques sont un autre point critique. Les carousels qui défilent seuls, les videos en autoplay, les animations en boucle -- ils doivent tous pouvoir être mis en pause, arretes, ou masques.
Navigation clavier : Tab, Shift+Tab, Enter, Espace, fleches. Testez TOUT votre parcours sans souris.
Indicateur de focus visible : c'est le curseur des utilisateurs clavier. Le supprimer avec outline:none est un crime d'accessibilité.
Skip links : un lien "aller au contenu" en haut de page pour éviter de tabuler à travers 50 liens de navigation.
Timeout : si une session expire, prévenez l'utilisateur et offrez la possibilité de prolonger.
Checklist WCAG 2.2 AA
Contraste >= 4.5:1
Taille cible >= 24x24px
Focus visible
Redim. texte 200%
Compréhensible : la clarte n'est pas un bonus
Le troisieme principe WCAG exige que l'information et le fonctionnement de l'interface soient compréhensibles. La langue de la page doit être déclarée en HTML (lang="fr"), les changements de langue dans le contenu doivent être balises, les formulaires doivent fournir des instructions claires et des messages d'erreur explicites. Ce principe va plus loin que la simple lisibilité. Il impose que le comportement de l'interface soit prévisible. Un lien qui ouvre un nouvel onglet sans prévenir viole ce principe. Un formulaire qui se soumet automatiquement sans confirmation viole ce principe. Un menu dont le contenu change quand on survole un élément viole ce principe. La prévisibilité est une forme d'accessibilité cognitive que nous négligeons systematiquement.
Un message d'erreur qui dit "Champ invalide" est inutile. "Veuillez entrer un email au format nom@domaine.fr" est accessible. La précision est une forme de respect.
Robuste : votre code doit parler aux machines aussi
Le quatrieme principe exige que le contenu soit suffisamment robuste pour être interprété de manière fiable par une grande variete d'agents utilisateurs, y compris les technologies d'assistance. Cela signifie un HTML semantique correct, des rôles ARIA bien utilises, et des composants personnalises qui exposent correctement leur état et leurs propriétés. Les désigners ont tendance a ignorer ce principe en le considerant comme "technique". C'est une erreur grave. Quand vous concevez un composant personnalise -- un accordeon, un système d'onglets, un sélecteur de date -- vous devez spécifier son comportement accessible dans vos maquettes. Si le développeur ne sait pas que votre accordeon doit annoncer "section 2 sur 5, depiee" au lecteur d'écran, il ne l'implementera pas.
HTML semantique : utilisez <button> pour un bouton, pas un <div> avec un onclick. La semantique est gratuite.
ARIA : la première règle d'ARIA est "ne pas utiliser ARIA si un élément HTML natif fait le travail".
Annotations d'accessibilité : intégréz les rôles, états et propriétés ARIA directement dans vos maquettes Figma.
Tests avec lecteur d'écran : VoiceOver (macOS/iOS) et NVDA (Windows) sont gratuits. Aucune excuse.
Taille des cibles : 24px minimum, 44px recommande
Le critère 2.5.8 de WCAG 2.2 impose une taille minimale de 24x24 CSS pixels pour les cibles interactives au niveau AA. Mais soyons clairs : 24px est un minimum legal, pas un objectif de design. Apple recommande 44pt, Google recommande 48dp, et les recherches du MIT montrent que la taille optimale pour un doigt adulte est de 57px. Les exceptions existent : les liens dans un texte continu, les cibles dont la taille est déterminée par l'agent utilisateur, et les cibles avec un espacement suffisant. Mais ces exceptions ne sont pas des excuses pour des boutons minuscules. En tant que désigner senior, je considere que toute cible en dessous de 44px sur mobile est un compromis qui doit être justifie par écrit dans les specs.
Chaque pixel en dessous de 44px sur mobile est une exclusion potentielle. Les utilisateurs avec des tremblements, de l'arthrite, ou simplement de gros doigts ne sont pas des cas limites. Ils sont vos utilisateurs.
L'apparence du focus : le critère le plus trahi du web
Combien de sites avez-vous visites ou le focus clavier est invisible ? La réponse est : presque tous. La ligne de code la plus destructrice en accessibilité est "*:focus { outline: none; }". Elle est présente dans d'innombrables templates et reset CSS. Elle supprime le seul indicateur de navigation pour les utilisateurs clavier. WCAG 2.2 renforce les exigences avec le critère 2.4.11 (Focus Not Obscured) au niveau AA : le focus ne doit jamais être complètement cache par d'autres éléments (sticky headers, modales, tooltips). Et le critère 2.4.13 (Focus Appearance) au niveau AAA spécifié que l'indicateur de focus doit avoir un contraste suffisant et une taille minimale perceptible.
Designez un focus visible et esthétique : un anneau de 2px avec un offset de 2px dans votre couleur primaire fonctionne parfaitement.
Utilisez :focus-visible au lieu de :focus pour n'afficher le focus qu'aux utilisateurs clavier, pas aux clics souris.
Vérifiez que vos sticky headers et modales ne recouvrent pas l'élément focus. C'est le nouveau critère AA 2.4.11.
Le focus fait partie de votre système de design. Documentez-le dans votre design system au même titre que vos couleurs et typographies.
Le contraste des couleurs : la science derriere les ratios
Le contraste n'est pas une question d'opinion esthétique. C'est de la physique perceptive. Le ratio de contraste WCAG est calcule selon la luminance relative des couleurs, définie par la formule du W3C. Au niveau AA, le texte normal nécessité un ratio de 4.5:1 et le texte large (18pt+ ou 14pt+ bold) nécessité 3:1. WCAG 2.2 maintient egalement le critère 1.4.11 sur les composants d'interface : les éléments interactifs (bordures de champs, icones fonctionnelles, indicateurs de focus) doivent avoir un ratio de 3:1 avec l'arriere-plan adjacent. Cela signifie que vos champs de formulaire gris clair sur fond blanc sont probablement non conformes. Vos icones gris moyen aussi.
"Le gris clair sur blanc c'est elegant" est l'excuse la plus répandue pour un design inaccessible. L'elegance qui exclut n'est pas de l'elegance. C'est de la négligence.
Utilisez des outils de vérification : Contrast Checker de WebAIM, le plugin Stark pour Figma, l'inspecteur d'accessibilité de Chrome DevTools.
Concevez en dark mode ET light mode : les ratios de contraste changent et doivent être vérifiés dans les deux modes.
Ne vous fiez pas à votre écran Retina calibre. Testez sur des écrans bas de gamme, en plein soleil, a luminosité réduite.
Le daltonisme affecte 8% des hommes. Simulez avec les filtres de daltonisme dans Figma ou Chrome DevTools.
Demonstration de contraste
L'Acte Europeen d'Accessibilité : la loi change tout en 2025
Le 28 juin 2025, l'European Accessibility Act (EAA) entre en application dans tous les États membres de l'UE. Ce n'est plus une directive optionnelle. C'est une obligation legale qui concerne les sites e-commerce, les services bancaires en ligne, les plateformes de streaming, les services de transport, les livres numériques, et bien d'autres. Les sanctions varient par pays mais peuvent inclure des amendes significatives et des injonctions de mise en conformité. En France, le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) s'aligne sur WCAG 2.2 AA. Les entreprises de plus de 250 millions d'euros de chiffre d'affaires sont déjà soumises à des obligations de déclaration.
Apres le 28 juin 2025, l'inaccessibilité n'est plus un choix de design. C'est une infraction legale. Les entreprises qui attendent le dernier moment vont payer le prix -- en amendes et en dettes techniques.
L'EAA couvre les produits ET les services numériques. Votre application mobile est concernee.
Les micro-entreprises (moins de 10 employes ET moins de 2M de CA) sont exemptees, mais le marche va exiger la conformité de tous.
Aux États-Unis, l'ADA est déjà utilisee pour des poursuites judiciaires sur l'accessibilité web. Plus de 4000 plaintes en 2023.
L'accessibilité est désormais un risque juridique que les directions générales prennent au sérieux. Utilisez cet argument.
Détruire les mythes : l'accessibilité n'est PAS laide
Le mythe le plus tenace dans notre industrie est que l'accessibilité et le beau design sont incompatibles. C'est faux. C'est empiriquement, demonstrablement faux. Apple, l'entreprise la plus associee au design premium, est aussi l'une des plus avancees en accessibilité. VoiceOver est intégré nativement à chaque appareil Apple depuis 2005. Stripe, référence du design SaaS, est conforme WCAG AA. Gov.uk, l'un des systèmes de design les plus respectes au monde, est ne de l'accessibilité. Le vrai problème n'est pas que l'accessibilité limite la créativité. C'est que les désigners n'ont jamais appris a être creatifs dans le cadre de l'accessibilité. Les contraintes ne tuent pas la créativité. Elles la catalysent.
Si vous ne pouvez pas créer un design beau ET accessible, le problème n'est pas l'accessibilité. Le problème est vos compétences en design.
Guide pratique : intégrér l'accessibilité dans votre workflow
L'accessibilité ne peut pas être ajoutee en fin de projet. C'est une méthode structurelle qui doit être intégrée à chaque étape du processus de design. Pendant la recherche, incluez des utilisateurs en situation de handicap dans vos panels. Pendant le design, utilisez des plugins comme Stark ou axe pour Figma. Pendant le développement, executez des audits automatises avec axe-core, Lighthouse, et WAVE. Apres le lancement, faites des audits manuels avec des utilisateurs de lecteurs d'écran et de navigation clavier.
Étape 1 - Recherche : incluez au moins 1 utilisateur en situation de handicap par étude qualitative.
Étape 2 - Design : annotez chaque maquette avec les informations d'accessibilité (ordre de tab, alt texts, rôles ARIA, messages d'erreur).
Étape 3 - Specs : documentez le comportement clavier de chaque composant interactif.
Étape 4 - Dev : intégréz axe-core dans votre CI/CD. Aucun merge sans score d'accessibilité satisfaisant.
Étape 5 - QA : testez manuellement avec VoiceOver + Safari, NVDA + Firefox, TalkBack + Chrome.
Étape 6 - Monitoring : utilisez des outils comme Siteimprove ou Deque pour surveiller la conformité en continu.
L'accessibilité est une compétence de design, pas un fardeau
L'accessibilité n'est pas un compromis. C'est une discipline. Les rampes de trottoir conçues pour les fauteuils roulants beneficient aux parents avec poussettes, aux livreurs avec chariots, aux personnes agees avec cannes. C'est le "curb cut effect" : ce qui est conçu pour les personnes en situation de handicap ameliore l'expérience de tout le monde. Les sous-titres beneficient à ceux qui regardent une video sans son dans le metro. Le contraste élevé beneficie à ceux qui utilisent leur telephone en plein soleil. Les grandes cibles tactiles beneficient à tous ceux qui ont les mains mouillees, gantees, ou fatiguees. En tant que désigner, l'accessibilité est la preuve ultime de votre maîtrise. Elle démontré que vous savez concevoir pour la diversité humaine, pas seulement pour des personas idealises dans des conditions parfaites.
WCAG 2.2 AA n'est pas un obstacle a franchir. C'est un plancher de qualité en dessous duquel un désigner professionnel ne devrait jamais descendre.
Sources & Références
- [1]W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation.
- [2]European Parliament (2019). European Accessibility Act — Directive (EU) 2019/882.
- [3]WebAIM (2024). The WebAIM Million — Annual accessibility analysis of the top 1,000,000 home pages.
- [4]Nielsen Norman Group (2023). Accessibility Standards and Guidelines for UX Designers.
- [5]Deque Systems. axe — The Standard in Accessibility Testing.
- [6]W3C WAI (2023). What's New in WCAG 2.2.
- [7]UsableNet (2024). 2023 Year End Digital Accessibility Lawsuit Report.
- [8]DINUM (2024). RGAA 4.1 — Referentiel General d'Amelioration de l'Accessibilite.
- [9]World Health Organization (2023). Disability and Health — Key Facts.