Qu’est-ce que les WCAG ? Explication des Règles pour l’accessibilité des contenus Web

Près de 94,8 % des un million de sites web les plus visités ne respectent pas les normes d’accessibilité de base, avec en moyenne 51 erreurs détectables par page d’accueil. Parallèlement, plus de 5 100 poursuites judiciaires liées à l’accessibilité numérique au titre de l’ADA ont été intentées aux États-Unis pour la seule année 2025 — et les coûts juridiques et réputationnels liés au non-respect de l’accessibilité augmentent rapidement. Que vous gériez une boutique e-commerce, une plateforme SaaS ou un portail gouvernemental, un document se trouve au centre de presque toutes les discussions sur l’accessibilité : les WCAG, les Web Content Accessibility Guidelines. Si vous vous êtes déjà demandé ce que sont exactement les WCAG, pourquoi elles existent et ce qu’elles exigent réellement de vous, ce guide est l’explication en langage clair que vous recherchiez.

Les origines des WCAG : d’où vient la norme

Les WCAG sont publiées par la Web Accessibility Initiative (WAI), un programme du World Wide Web Consortium (W3C) — le même organisme international qui normalise HTML, CSS et la plupart des technologies fondamentales du web. Ces lignes directrices existent parce que le web, par sa nature même, porte une promesse d’accès universel. En pratique, sans choix de conception délibérés, cette promesse s’effondre pour des millions d’utilisateurs.

Les racines des lignes directrices sur l’accessibilité du web remontent à 1995, lorsque Gregg Vanderheiden a compilé la première ligne directrice d’accessibilité web juste après que Tim Berners-Lee a mentionné l’accès des personnes handicapées dans une conférence plénière lors de la deuxième conférence internationale sur le World-Wide Web. Au cours des années suivantes, plus de 38 lignes directrices différentes sur l’accès au web ont émergé de divers auteurs et organisations, pour finalement converger vers les Unified Web Site Accessibility Guidelines à l’Université du Wisconsin–Madison. La version 8 de ce document, publiée en 1998, est devenue le point de départ des WCAG 1.0, qui sont devenues une recommandation officielle du W3C le 5 mai 1999.

Les WCAG 2.0 sont arrivées en décembre 2008 et ont été suffisamment importantes pour être adoptées comme norme ISO — ISO/IEC 40500:2012 — en octobre 2012. Les WCAG 2.1, publiées en juin 2018, ont étendu les critères 2.0 avec 17 nouveaux critères de succès axés sur l’ergonomie mobile, la basse vision et l’accessibilité cognitive. Et la version actuelle, WCAG 2.2, a été publiée en tant que recommandation du W3C le 5 octobre 2023 et a depuis été approuvée comme ISO/IEC 40500:2025. Le W3C encourage tout le monde à utiliser la dernière version, et ce pour une bonne raison : un contenu conforme aux WCAG 2.2 respecte automatiquement aussi les WCAG 2.1 et 2.0.

Il est utile d’être clair sur ce que les WCAG sont et ne sont pas. Il s’agit d’une norme technique — une spécification précise et testable, élaborée au terme d’un processus rigoureux multipartite du W3C en coopération avec des personnes et des organisations du monde entier. Ce n’est pas un document juridique en soi, mais il a été incorporé par référence dans des lois et règlements dans des dizaines de juridictions, ce qui en fait le code de référence de facto pour l’accessibilité numérique dans le monde entier.

À qui les WCAG sont destinées

Les WCAG traitent des obstacles à l’accessibilité pour les personnes présentant un large éventail de handicaps, notamment visuels, auditifs, physiques, de la parole, cognitifs, linguistiques, d’apprentissage et neurologiques. Il s’agit d’une population remarquablement vaste. L’Organisation mondiale de la santé estime qu’environ 1,3 milliard de personnes — soit environ 16 % de la population mondiale — vivent avec une forme de handicap qui affecte leur vie quotidienne et leur accès en ligne. Chacune de ces personnes pourrait être un client, un citoyen, un étudiant ou un employé potentiel qui essaie d’utiliser votre site web en ce moment même.

Mais les avantages de la conformité aux WCAG vont bien au-delà des utilisateurs ayant des handicaps permanents. Les lignes directrices aident également les personnes âgées ayant des limitations liées à l’âge — baisse de la vision, perte auditive, ralentissement des réflexes moteurs — et améliorent souvent l’ergonomie pour tout le monde. Pensez aux sous-titres sur les vidéos : ils ont été conçus pour les personnes sourdes, mais ils bénéficient aussi aux personnes qui regardent dans des environnements bruyants, aux locuteurs non natifs qui suivent le contenu, et à toute personne qui préfère lire plutôt qu’écouter. De même, la navigabilité au clavier aide les utilisateurs avancés qui trouvent la souris lente, et un contraste de couleur suffisant aide toute personne qui plisse les yeux devant un écran très lumineux à l’extérieur.

Les WCAG couvrent également le contenu sur pratiquement tous les types d’appareils numériques — ordinateurs de bureau, ordinateurs portables, bornes interactives et appareils mobiles — et sont intentionnellement neutres sur le plan technologique. Les critères de succès sont rédigés sous forme d’énoncés testables qui ne prescrivent pas une technologie spécifique, ce qui signifie qu’ils restent pertinents à mesure que HTML, les frameworks JavaScript et les technologies d’assistance continuent d’évoluer.

Les principes POUR : la base conceptuelle des WCAG

Chaque critère de succès des WCAG — les 86 de la version 2.2 — est organisé sous quatre principes de haut niveau, collectivement connus sous l’acronyme POUR. Ces principes constituent la base conceptuelle de l’ensemble de la norme. Les comprendre vous donne un modèle mental intuitif de l’accessibilité, même avant de lire un seul critère spécifique.

• Perceptible (Perceivable) : Les informations et les composants de l’interface utilisateur doivent être présentés aux utilisateurs de manière à pouvoir être perçus. En pratique, cela signifie que le contenu ne peut pas être invisible pour tous les sens d’un utilisateur. Si un utilisateur ne peut pas voir une image, il doit exister une alternative textuelle qu’il peut entendre via un lecteur d’écran. Si une vidéo comporte une narration parlée, il doit y avoir des sous-titres pour les utilisateurs qui ne peuvent pas entendre. Les exigences pratiques relevant de ce principe incluent le texte alternatif pour les images, les sous-titres pour les vidéos, un contraste de couleur suffisant entre le texte et l’arrière-plan, et la possibilité d’agrandir le texte sans perte de contenu.
• Utilisable (Operable) : Les composants de l’interface utilisateur et la navigation doivent être utilisables. Aucune interaction ne peut exiger une saisie qu’un utilisateur ne peut pas effectuer. L’implication la plus courante : toutes les fonctionnalités doivent être réalisables au clavier seul, et pas uniquement à la souris. Ce principe couvre également le fait de donner aux utilisateurs suffisamment de temps pour lire et interagir avec le contenu, d’éviter le contenu susceptible de déclencher des crises d’épilepsie, et de fournir plusieurs moyens de naviguer sur un site.
• Compréhensible (Understandable) : Les informations et le fonctionnement de l’interface utilisateur doivent être compréhensibles. Le contenu ne peut pas être si complexe ou déroutant que les utilisateurs ne puissent pas l’utiliser comme prévu. Cela couvre un langage lisible (y compris la spécification de la langue de la page dans le code afin que les lecteurs d’écran utilisent la bonne prononciation), un comportement de page prévisible, des instructions claires et des messages d’erreur utiles qui indiquent aux utilisateurs ce qui s’est mal passé et comment y remédier.
• Robuste : Le contenu doit être suffisamment robuste pour être interprété de manière fiable par une grande variété d’agents utilisateurs, y compris les technologies d’assistance. Un site robuste utilise un balisage sémantique propre et valide afin que les lecteurs d’écran, les afficheurs braille et autres outils d’assistance puissent analyser et transmettre correctement le contenu — aujourd’hui comme à mesure que la technologie évolue.

Considérez POUR comme quatre filtres par lesquels chaque élément de votre site web doit passer. Si un composant échoue à ne serait-ce qu’un seul des quatre filtres, il constitue probablement un obstacle pour certains de vos utilisateurs.

Ces quatre principes sont restés stables dans toutes les versions des WCAG — 2.0, 2.1 et 2.2 — même si les critères de succès spécifiques qui les sous-tendent se sont multipliés et ont évolué. Cette stabilité fait de POUR une grille de lecture durable pour évaluer l’accessibilité, quel que soit le numéro de version référencé par une loi particulière.

Niveaux de conformité : A, AA et AAA expliqués

Sous les quatre principes POUR se trouvent 13 lignes directrices, et sous ces lignes directrices se trouvent les 86 critères de succès testables — les exigences concrètes et spécifiques que vous devez respecter pour revendiquer la conformité aux WCAG. Chaque critère de succès est associé à l’un des trois niveaux de conformité.

• Niveau A est le minimum. Ce sont les exigences les plus critiques, représentant des obstacles si graves que certains utilisateurs ne peuvent tout simplement pas accéder au contenu. Des exemples incluent la fourniture d’alternatives textuelles pour le contenu non textuel et le fait de garantir que toutes les fonctionnalités sont accessibles au clavier. Le seul niveau A n’est pas suffisant pour la plupart des exigences réglementaires, mais ne pas le respecter signifie un échec fondamental.
• Niveau AA est la norme intermédiaire et celle exigée par la grande majorité des lois et règlements dans le monde. Il satisfait tous les critères de niveau A plus des exigences supplémentaires telles que garantir des rapports de contraste de couleur texte/arrière-plan d’au moins 4,5:1, fournir une navigation cohérente entre les pages et offrir des sous-titres pour les vidéos préenregistrées. La plupart des lois mondiales sur l’accessibilité — y compris la Section 508 aux États-Unis, l’EN 301 549 en Europe et l’AODA en Ontario, au Canada — exigent la conformité au niveau AA. C’est la cible que presque toutes les organisations devraient privilégier.
• Niveau AAA est la norme la plus élevée et inclut des critères qui sont plus ambitieux qu’universalement réalisables. Le W3C lui-même reconnaît qu’il n’est pas possible de satisfaire tous les critères AAA pour tous les types de contenu, de sorte que ces critères ne sont généralement pas fixés comme exigence de politique générale. Des exemples incluent l’interprétation en langue des signes pour tout le contenu audio et un niveau de lecture ne dépassant pas celui de l’enseignement secondaire inférieur.

Une nuance importante : les niveaux de conformité sont cumulatifs. Atteindre le niveau AA signifie que vous satisfaites également tous les critères de niveau A. Atteindre le niveau AAA signifie que vous satisfaites aussi A et AA. Et, point crucial, la conformité est tout ou rien à chaque niveau — vous ne pouvez pas revendiquer la conformité AA si ne serait-ce qu’un seul critère AA n’est pas respecté sur une page donnée.

Pour la plupart des organisations, WCAG 2.2 niveau AA est la bonne cible. C’est le niveau intégré dans la loi, le niveau que les tribunaux utilisent comme référence et le niveau qui ouvre réellement votre expérience numérique au public le plus large possible.

Ce qui a changé dans les WCAG 2.2 : les neuf nouveaux critères de succès

Les WCAG 2.2, publiées en octobre 2023, ont ajouté neuf nouveaux critères de succès en plus de tout ce qui figure dans les WCAG 2.1. Ces ajouts ont été motivés par des recherches continues sur les domaines où les utilisateurs handicapés — en particulier ceux ayant des handicaps cognitifs, des déficiences motrices et une basse vision — rencontraient encore fréquemment des obstacles que les lignes directrices précédentes ne traitaient pas de manière adéquate. Les WCAG 2.2 ne suppriment ni ne modifient aucune exigence existante des WCAG 2.1 ; elles les étendent simplement.

Sur les neuf nouveaux critères, quatre sont au niveau AA (et sont donc juridiquement pertinents pour la plupart des organisations), deux sont au niveau A et trois sont au niveau AAA. Voici ce que signifie concrètement chacun des critères de niveau AA et inférieur :

• 2.4.11 Focus non masqué — Minimum (AA) : Lorsqu’un utilisateur de clavier navigue vers un composant interactif, ce composant ne doit pas être entièrement masqué par un autre contenu créé par l’auteur. Il s’agit d’une réponse directe à un schéma de conception moderne courant : en-têtes fixes, bannières de cookies et pieds de page fixes qui glissent sur le contenu de la page et engloutissent silencieusement le focus clavier, laissant les utilisateurs bloqués sans indication visible de l’endroit où ils se trouvent sur la page.
• 2.5.7 Mouvements de glisser (Dragging Movements) (AA) : Toute fonctionnalité qui nécessite une action de glisser — pensez au glisser-déposer pour téléverser des fichiers, aux éléments de liste triables ou aux curseurs personnalisés — doit disposer d’une alternative à pointeur unique qui ne nécessite pas de glisser. Pour un utilisateur ayant des tremblements ou une motricité fine limitée, maintenir une pression continue tout en déplaçant un pointeur à l’écran peut être presque impossible. Fournir des alternatives du type cliquer pour sélectionner puis cliquer pour placer, ou des boutons fléchés haut/bas sur les listes triables, résout ce problème.
• 2.5.8 Taille de la cible — Minimum (AA) : Les cibles interactives telles que les boutons et les liens doivent mesurer au moins 24×24 pixels CSS. Les petites cibles tactiles sont un problème d’ergonomie bien documenté pour les utilisateurs mobiles ayant des déficiences motrices, les personnes âgées et, en réalité, toute personne qui tape sur un téléphone en multitâche.
• 3.3.8 Authentification accessible — Minimum (AA) : Les processus d’authentification ne peuvent pas exiger des utilisateurs qu’ils résolvent un test de fonction cognitive — comme un CAPTCHA traditionnel nécessitant la reconnaissance de caractères ou la résolution d’énigmes — à moins qu’une alternative ne soit fournie. Il s’agit d’un critère important pour tout site qui utilise des défis CAPTCHA standard dans les flux de connexion ou d’inscription. Les solutions incluent la prise en charge des gestionnaires de mots de passe, les liens magiques envoyés par e-mail ou SMS, l’authentification biométrique ou des alternatives basées sur la reconnaissance d’objets.
• 3.2.6 Aide cohérente (Consistent Help) (A) : Si un site fournit un mécanisme d’aide (comme un bouton de chat en direct, un lien vers une FAQ ou un numéro de téléphone du support) sur plusieurs pages, ce mécanisme doit apparaître au même emplacement relatif sur ces pages. Les utilisateurs ayant des handicaps cognitifs qui ont besoin d’aide bénéficient grandement du fait de savoir exactement où la trouver sans avoir à chercher à chaque fois.
• 3.3.7 Saisie redondante (Redundant Entry) (A) : Les informations précédemment saisies par un utilisateur dans un processus en plusieurs étapes doivent être préremplies ou sélectionnables plutôt que nécessiter une nouvelle saisie. Cela réduit les frictions pour les utilisateurs ayant des handicaps cognitifs ou moteurs pour lesquels le remplissage de formulaires est particulièrement éprouvant.

Les WCAG 2.2 ont également officiellement supprimé un critère de la version 2.1 : 4.1.1 Analyse syntaxique (Parsing). Ce critère exigeait à l’origine un HTML strictement valide pour garantir que les technologies d’assistance puissent analyser correctement le balisage. Il a été retiré parce que les navigateurs modernes et les technologies d’assistance gèrent désormais de manière robuste le balisage mal formé grâce à leurs propres mécanismes de correction d’erreurs, ce qui rend le critère pratiquement moins significatif pour l’accessibilité.

Les WCAG et la loi : ce que coûte réellement la non-conformité

Les WCAG sont une norme technique, pas une loi. Mais elles ont été intégrées dans le tissu juridique de l’accessibilité numérique dans la plupart des grandes juridictions, ce qui signifie que la non-conformité entraîne un véritable risque juridique.

Aux États-Unis, bien que ni l’ADA ni la Section 508 ne mentionnent explicitement les WCAG 2.2 dans leur texte, les WCAG sont systématiquement utilisées comme référence technique dans les litiges et les actions de mise en conformité. Le Department of Justice a publié en 2024 une règle finale fixant les WCAG 2.1 niveau AA comme norme officielle pour la conformité à la Section 508 et au titre II de l’ADA pour les gouvernements des États et locaux. Le titre III de l’ADA — qui s’applique aux lieux publics, y compris la plupart des entreprises privées opérant en ligne — est activement appliqué par le biais de poursuites privées. En 2024, plus de 4 000 poursuites liées à des propriétés numériques ont été intentées au titre de l’ADA devant les tribunaux fédéraux et d’État, et la tendance s’est poursuivie à la hausse en 2025. Les sanctions civiles pour une première violation de l’ADA ont été ajustées à l’inflation en 2024 et peuvent désormais atteindre 115 231 $, montant pouvant s’élever à 230 464 $ en cas de récidive.

En Europe, la situation est tout aussi significative. L’European Accessibility Act (EAA) est devenue juridiquement applicable dans les États membres de l’UE le 28 juin 2025, exigeant que les sites web, applications, livres numériques, plateformes d’e-commerce et PDF soient conformes aux critères WCAG 2.1 AA. La norme européenne EN 301 549 fait actuellement référence aux WCAG 2.1, la prochaine version devant être mise à jour vers les WCAG 2.2. Pour les organisations ayant une présence en Europe, la conformité à l’EAA n’est plus optionnelle.

Les données relatives aux litiges révèlent également un schéma particulièrement douloureux pour les petites entreprises : l’idée que rester petit vous protège est un mythe. En 2023, 77 % des poursuites liées à l’accessibilité numérique au titre de l’ADA visaient des entreprises dont le chiffre d’affaires annuel était inférieur à 25 millions de dollars. L’e-commerce reste de loin le secteur le plus poursuivi. Et, point crucial, être poursuivi une fois ne protège en rien contre de nouvelles poursuites — près de la moitié de toutes les actions récentes en matière d’accessibilité numérique visaient des entreprises ayant déjà fait l’objet d’au moins une plainte antérieure.

Les échecs les plus courants des WCAG (et comment les repérer)

Étant donné que près de 95 % des sites web ne respectent pas les normes d’accessibilité de base, il vaut la peine de savoir quels échecs spécifiques sont les plus répandus. Le rapport annuel WebAIM Million, qui audite les pages d’accueil du top un million de sites web, identifie systématiquement la même poignée de problèmes apparaissant sur la grande majorité des pages :

• Faible contraste de couleur : Un texte à faible contraste affectait 79,1 % des pages d’accueil dans l’analyse 2025, avec près de 30 occurrences par page en moyenne. Il s’agit à la fois de l’échec le plus courant et de l’un des plus faciles à détecter avec des outils automatisés. Le texte doit présenter un rapport de contraste d’au moins 4,5:1 avec son arrière-plan (3:1 pour le texte de grande taille) pour respecter le niveau AA.
• Texte alternatif manquant : L’absence de texte alternatif affecte 55,5 % des pages. Pour les utilisateurs de lecteurs d’écran qui sont aveugles ou malvoyants, une image sans texte alternatif est tout simplement invisible — la technologie d’assistance l’ignorera silencieusement ou lira un nom de fichier dénué de sens. Les images liées sans texte alternatif brisent complètement la navigation.
• Étiquettes de formulaire manquantes : Des champs de formulaire sans étiquettes associées signifient qu’un utilisateur de lecteur d’écran ne peut pas savoir quelles informations sont demandées. Cela crée une barrière infranchissable sur tout formulaire de paiement, d’inscription ou de contact.
• Liens vides : Des liens sans texte descriptif — souvent des liens constitués uniquement d’icônes ou des liens d’image sans texte alternatif — laissent les utilisateurs de clavier et de lecteurs d’écran sans contexte sur la destination du lien.
• Langue du document manquante : Ne pas déclarer la langue d’une page dans le HTML signifie que les lecteurs d’écran peuvent lire le contenu en utilisant les règles de prononciation d’une autre langue, rendant le texte incompréhensible.

Ce qui est frappant dans cette liste, c’est qu’aucun de ces problèmes n’est un cas limite exotique nécessitant une ingénierie avancée. Il s’agit de décisions simples de balisage et de conception. Le fait qu’ils persistent sur la grande majorité du web reflète un fossé structurel dans la manière dont l’accessibilité est (ou n’est pas) intégrée dans les flux de travail typiques de développement web, et non une barrière technique fondamentale.

Comment aborder la conformité aux WCAG en tant qu’organisation

Passer de l’état actuel de la plupart des sites web à une véritable conformité WCAG 2.2 niveau AA nécessite une approche systématique. Ce n’est pas un projet ponctuel — c’est un processus continu, car le contenu change, les frameworks sont mis à jour et les composants tiers sont remplacés. Voici comment structurer l’effort efficacement.

Commencez par un audit de base. Avant de pouvoir corriger quoi que ce soit, vous devez savoir ce qui est cassé. Les outils d’analyse automatisée peuvent identifier rapidement et à grande échelle un sous-ensemble significatif de problèmes — problèmes de contraste de couleur, texte alternatif manquant, étiquettes de formulaire absentes. Cependant, les outils automatisés ont des limites bien connues ; ils peuvent détecter environ 30 à 40 % des problèmes WCAG. Le reste nécessite des tests manuels : naviguer sur votre site uniquement au clavier, tester avec de vrais lecteurs d’écran tels que NVDA ou JAWS sur Windows et VoiceOver sur macOS et iOS, et idéalement impliquer des utilisateurs handicapés dans votre processus de test.

Priorisez selon l’impact et la fréquence. Tous les problèmes n’ont pas le même poids. Un texte alternatif manquant sur une icône décorative est bien moins critique qu’un piège clavier qui empêche un utilisateur de quitter une boîte de dialogue modale, ou qu’un formulaire de connexion totalement inutilisable avec un lecteur d’écran. Concentrez votre premier sprint de remédiation sur les obstacles qui bloquent les parcours utilisateurs essentiels — paiement, création de compte, recherche, contact — avant de traiter les éléments cosmétiques ou à impact moindre.

Intégrez l’accessibilité dans le flux de développement, plutôt qu’à la fin. Le travail d’accessibilité le plus coûteux est la remédiation après le lancement. Intégrer des contrôles d’accessibilité dans votre design system, votre bibliothèque de composants, votre processus de revue de code et votre pipeline CI/CD permet de détecter les problèmes au moment où il est le moins coûteux de les corriger. Désignez un responsable clair de l’accessibilité au sein de votre équipe et fournissez des formations spécifiques aux rôles pour les designers, développeurs et éditeurs de contenu.

Maintenez une déclaration d’accessibilité. Publier sur votre site une déclaration d’accessibilité claire et honnête — décrivant la norme que vous visez, la manière dont les utilisateurs peuvent signaler des obstacles et la façon dont vous répondez à ces signalements — démontre votre bonne foi et est en fait exigé par la loi dans certaines juridictions, notamment dans le cadre de la directive européenne sur l’accessibilité du web. Cela crée également une boucle de rétroaction qui vous aide à repérer les problèmes passés entre les mailles de vos tests.

Utilisez les widgets de surcouche comme améliorations, pas comme substitut à l’accessibilité au niveau du code. Les widgets et SDK de surcouche d’accessibilité — y compris Accsible — peuvent être des outils précieux pour mettre en avant des préférences contrôlées par l’utilisateur telles que la taille du texte, les modes de contraste et les améliorations de la navigation au clavier. Mais les données sont claires : des widgets déployés à la place d’un travail d’accessibilité fondamental ne préviennent pas les poursuites. La protection juridique vient du fait que votre code sous-jacent respecte les critères des WCAG, pas d’un widget installé au-dessus d’une base inaccessible. Utilisez les surcouches pour compléter une remédiation réelle, pas pour la remplacer.

La route à venir : WCAG 3.0 à l’horizon

Alors même que les organisations travaillent encore à respecter les WCAG 2.2, le W3C Accessibility Guidelines Working Group élabore les WCAG 3.0, une restructuration plus substantielle des recommandations d’accessibilité du web. Le premier projet de travail public a été publié début 2021, et fin 2025, le projet de travail continue de faire l’objet de développements importants. Aucune partie des WCAG 3.0 n’est encore une recommandation officielle, et aucune date de publication fixe n’a été définie.

On s’attend à ce que les WCAG 3.0 s’écartent sensiblement du modèle de conformité A/AA/AAA, introduisent une approche basée sur le scoring et couvrent un éventail plus large de types de contenus numériques, y compris les applications mobiles natives et les technologies émergentes. Pour l’instant, les organisations devraient se concentrer sur les WCAG 2.2 niveau AA — c’est la norme actuellement applicable et elle le restera dans un avenir prévisible. Les organisations qui construisent dès maintenant des fondations solides conformes aux WCAG 2.2 seront bien mieux placées pour s’adapter lorsque les WCAG 3.0 deviendront finalement une recommandation.

Points clés à retenir

• Les WCAG 2.2 sont la norme mondiale actuelle pour l’accessibilité du web, publiées par le W3C et approuvées comme ISO/IEC 40500:2025. Un contenu conforme aux WCAG 2.2 satisfait automatiquement les versions 2.1 et 2.0 — visez la dernière version.
• Le niveau AA est la cible qui compte. Presque toutes les lois mondiales sur l’accessibilité — ADA, Section 508, EAA, EN 301 549, AODA — font référence au niveau AA des WCAG comme niveau de conformité requis. Concentrez d’abord vos efforts à ce niveau.
• Les échecs les plus courants sont corrigeables. Le faible contraste de couleur, l’absence de texte alternatif, les étiquettes de formulaire manquantes et les liens vides représentent la majorité des erreurs d’accessibilité sur le web. Ils sont résolvables avec relativement peu d’efforts pour un impact significatif.
• Les tests automatisés sont nécessaires mais insuffisants. Les outils peuvent détecter environ 30 à 40 % des problèmes WCAG. Associez l’analyse automatisée à des tests au clavier, des tests avec lecteurs d’écran et, idéalement, des tests utilisateurs avec des personnes handicapées pour obtenir une vision complète.
• L’accessibilité est un processus continu, pas un projet ponctuel. Le contenu change, les composants tiers changent et les normes évoluent. Intégrez l’accessibilité dans vos flux de travail de conception, de développement et de contenu afin qu’elle soit maintenue en continu, et non corrigée de manière réactive après une plainte ou une poursuite.