Ressources d'accessibilité

Une brève histoire de l'accessibilité du web

Bien avant l'existence du web, le droit fédéral américain avait commencé à bâtir l'échafaudage juridique auquel l'accessibilité s'arrimerait plus tard. La section 504 de la loi sur la réadaptation de 1973 (Rehabilitation Act) interdisait la discrimination fondée sur le handicap par tout programme bénéficiant d'une aide financière fédérale, ses règlements d'application n'ayant été signés que le 28 avril 1977, et seulement après le célèbre sit-in de la section 504, au cours duquel des militants des droits des personnes handicapées ont occupé un bâtiment fédéral à San Francisco pendant 25 jours, la plus longue occupation non violente d'un bâtiment fédéral de l'histoire des États-Unis. La section 508 de la même loi a été ajoutée par amendement en 1986, mais sans réel pouvoir de contrainte ; la version substantiellement révisée à laquelle les praticiens se réfèrent aujourd'hui a été promulguée en 1998 dans le cadre du Workforce Investment Act, obligeant les agences fédérales américaines à rendre accessibles leurs technologies électroniques et de l'information. L'Americans with Disabilities Act de 1990 est la loi sur les droits civiques plus large qui interdit la discrimination liée au handicap, et c'est l'ADA (et non la section 508) qui est invoqué dans les poursuites visant les sites web du secteur privé.

Le W3C a lancé la Web Accessibility Initiative (WAI) en 1997 pour coordonner le travail d'accessibilité du web au sein de la communauté de normalisation. La vision de Tim Berners-Lee (selon laquelle la valeur du web repose sur l'universalité, et l'accès par tous, quel que soit le handicap, est essentiel) est devenue la prémisse fondatrice de la WAI.

La chronologie des versions des WCAG

• WCAG 1.0 : recommandation du W3C, 5 mai 1999. Elles organisaient les conseils d'accessibilité autour de 14 directives, avec des points de contrôle classés Priorité 1, 2 ou 3 (les niveaux de conformité A, AA et AAA héritent de ce schéma). Fermement orientées autour du HTML et de la pile technologique du web naissant de la fin des années 1990.
• WCAG 2.0 : recommandation du W3C, 11 décembre 2008. Elles ont réorganisé l'ensemble du cadre autour des quatre principes POUR. Elles ont introduit le modèle de conformité à trois niveaux toujours en vigueur (A / AA / AAA). Adoptées sous la référence ISO/IEC 40500:2012 en octobre 2012.
• WCAG 2.1 : recommandation du W3C, 5 juin 2018. Ajout de 17 nouveaux critères de succès concernant les utilisateurs mobiles (orientation de l'écran, gestes du pointeur, actionnement par le mouvement), les utilisateurs malvoyants (redistribution à 320 pixels CSS, contraste non textuel de 3:1 pour les composants d'interface, tolérance d'espacement du texte) et les personnes ayant des troubles cognitifs et de l'apprentissage (détection de la finalité des champs pour le remplissage automatique, aide aux délais d'expiration). « WCAG 2.1 AA » demeure la norme la plus citée dans le droit de l'accessibilité à travers le monde.
• WCAG 2.2 : recommandation du W3C, 5 octobre 2023, avec des mises à jour de maintenance éditoriale publiées en décembre 2024. Ajout de neuf nouveaux critères de succès, dont Focus Not Obscured (2.4.11/2.4.12), Dragging Movements (2.5.7), Target Size Minimum (2.5.8, au moins 24×24 pixels CSS), Consistent Help (3.2.6), Redundant Entry (3.3.7) et Accessible Authentication (3.3.8/3.3.9, les parcours de connexion ne peuvent pas exiger de CAPTCHA-énigmes sans solution accessible de remplacement). Suppression du critère obsolète 4.1.1 Parsing. C'est la version actuellement publiée.
• WCAG 3.0 : encore à l'état de brouillon de travail. Conçues avec un modèle de notation plus souple et une portée plus large (applications, outils de création, plateformes de publication, technologies émergentes). Le W3C est clair : les WCAG 3 ne remplaceront pas immédiatement les WCAG 2 ; les WCAG 2 continueront d'être maintenues pendant plusieurs années après la finalisation des 3. Les praticiens qui rédigent des déclarations d'accessibilité en 2026 devraient encore se référer aux WCAG 2.2 (ou 2.1) comme norme en vigueur.

Les quatre principes POUR, en clair

Perceptible pose la question : l'utilisateur peut-il réellement saisir ce qui est à l'écran ? Une photographie sans texte alternatif n'est pas perceptible pour une personne utilisant un lecteur d'écran. Une vidéo sans sous-titres n'est pas perceptible pour une personne sourde. Un texte en gris foncé de 9 points sur un gris à peine moins foncé n'est pas perceptible pour beaucoup de personnes malvoyantes. « Perceptible » ne veut pas dire « joli », cela veut dire « l'information est-elle présente sous une forme que les sens et les outils de cet utilisateur peuvent capter ? ».

Utilisable pose la question : l'utilisateur peut-il réellement se servir de l'interface ? Un site qui exige de survoler avec une souris n'est pas utilisable pour les utilisateurs au clavier ou au toucher. Un délai d'expiration de 60 secondes n'est pas utilisable pour une personne qui a besoin de plus de temps pour lire. Une fenêtre modale qui piège le focus clavier sans échappatoire n'est pas utilisable.

Compréhensible pose la question : l'utilisateur peut-il donner un sens à ce qui se passe ? Un formulaire qui affiche « Erreur 47 » et rien d'autre n'est pas compréhensible. Une page dont la navigation se réorganise différemment à chaque visite n'est pas compréhensible.

Robuste pose la question : le contenu continuera-t-il de fonctionner à mesure qu'évoluent les agents utilisateurs et les technologies d'assistance ? Les composants personnalisés qui n'exposent pas les rôles, noms et états appropriés à l'arbre d'accessibilité échouent à ce principe. Le conseil pratique le plus courant : privilégier les éléments HTML standard plutôt que les widgets JavaScript personnalisés lorsque c'est possible ; et lorsque vous construisez des widgets personnalisés, suivre les modèles ARIA documentés par le W3C.

WAI-ARIA, le complément pour les applications riches

WAI-ARIA est une spécification distincte du W3C qui définit des rôles, des états et des propriétés que le HTML peut porter pour communiquer aux technologies d'assistance la finalité et l'état actuel des composants d'interface dynamiques. ARIA est nécessaire parce que le HTML seul ne peut pas décrire des modèles modernes comme les onglets, les boîtes de dialogue, les listes déroulantes à saisie semi-automatique, les vues arborescentes et les régions dynamiques qui se mettent à jour sans rechargement de page. Chronologie des versions : WAI-ARIA 1.0, recommandation du 20 mars 2014 ; 1.1 le 14 décembre 2017 ; 1.2 le 6 juin 2023, la version actuelle. Les cinq « règles d'utilisation d'ARIA » se résument à : privilégier le HTML natif ; ne pas changer la sémantique des éléments existants ; garantir l'utilisabilité au clavier ; ne jamais masquer les éléments focalisables aux technologies d'assistance ; et toujours donner à chaque élément interactif un nom accessible.

Le paysage juridique, juridiction par juridiction

Aux États-Unis, les poursuites pour accessibilité du web sont presque toutes engagées au titre du titre III de l'ADA. Deux affaires ont façonné le paysage moderne. National Federation of the Blind c. Target Corp. (déposée le 7 février 2006, réglée en août 2008 pour 6 millions de dollars, plus 3,7 millions de dollars de frais d'avocat) a été le premier grand recours collectif américain en matière d'accessibilité du web. Robles c. Domino's Pizza : arrêt de la cour d'appel du neuvième circuit le 15 janvier 2019 ; la Cour suprême a refusé d'entendre l'appel le 7 octobre 2019, confirmant que l'ADA s'applique à toute plateforme en ligne d'une entreprise américaine disposant d'établissements physiques. Le résultat a été une explosion soutenue des dépôts : 4 187 poursuites fédérales pour accessibilité numérique en 2024, avec plus de 4 000 chaque année depuis 2021. Environ un quart des affaires de 2024 concernaient des entreprises qui avaient déjà été poursuivies auparavant. Fait notable, plus de 1 000 des défendeurs de 2024 avaient déjà installé un « widget d'accessibilité » (ces scripts de type surcouche fortement commercialisés auprès des petites entreprises), ce qui n'a pas empêché la poursuite.

En avril 2024, le département de la Justice des États-Unis a finalisé une règle longtemps attendue appliquant le titre II de l'ADA au contenu web et aux applications mobiles des administrations des États et locales. La règle a été publiée au Federal Register le 24 avril 2024 et a adopté le niveau AA des WCAG 2.1 comme norme technique. En avril 2026, le DOJ a prolongé d'un an les délais initiaux par une règle finale provisoire (Interim Final Rule) : les grandes entités publiques ont désormais jusqu'au 26 avril 2027, les petites entités jusqu'au 26 avril 2028.

L'European Accessibility Act est la directive (UE) 2019/882, adoptée en avril 2019. Les États membres devaient la transposer en droit national au plus tard le 28 juin 2022, et les exigences d'accessibilité de fond ont commencé à s'appliquer le 28 juin 2025. L'EAA couvre un large éventail de produits et de services de consommation mis sur le marché de l'UE : ordinateurs et systèmes d'exploitation, téléphones intelligents et tablettes, liseuses, distributeurs automatiques de billets et bornes de billetterie/enregistrement, sites de commerce électronique, services bancaires, livres numériques, services de médias audiovisuels et informations sur le transport de voyageurs. Les microentreprises (moins de 10 salariés, chiffre d'affaires inférieur à 2 millions d'euros) qui fournissent des services en sont exemptées. La norme technique harmonisée est EN 301 549, publiée conjointement par le CEN, le CENELEC et l'ETSI ; la version actuelle 3.2.1 (mars 2021) intègre le texte intégral des WCAG 2.1.

Autres cadres nationaux importants : l'AODA de l'Ontario (Accessibility for Ontarians with Disabilities Act), promulguée en 2005 avec un objectif affiché d'accessibilité complète d'ici 2025 ; le RGAA français (Référentiel Général d'Amélioration de l'Accessibilité) v4.1.2 (2022), un ensemble de 106 critères techniques alignés sur les WCAG 2.1 AA, assorti d'amendes substantielles en cas de non-conformité pour le secteur public et les grandes entreprises privées (chiffre d'affaires annuel de 250 millions d'euros ou plus).

Qui utilise réellement votre site : le paysage des technologies d'assistance

Les données les plus fiables sur les combinaisons de lecteur d'écran et de navigateur proviennent du WebAIM Screen Reader User Survey. L'édition la plus récente, la 10e enquête, a été menée en décembre 2023 et janvier 2024 et a recueilli 1 539 réponses valides. Chiffres clés : comme lecteur d'écran principal, JAWS 40,5 %, NVDA 37,7 %, VoiceOver 9,7 %. En tant que « lecteur le plus utilisé, tous usages confondus » (choix multiple), NVDA 65,6 %, JAWS 60,5 %, VoiceOver 43,9 % : environ 71,6 % des répondants utilisent plus d'un lecteur d'écran. Les combinaisons les plus courantes sont JAWS + Chrome (24,7 %), NVDA + Chrome (21,3 %), JAWS + Edge (11,4 %), NVDA + Firefox (10,0 %) et VoiceOver + Safari (7,0 %).

• JAWS (Job Access With Speech), lecteur d'écran commercial pour Windows, sorti à l'origine en 1989 par Ted Henter via Henter-Joyce, aujourd'hui intégré à Vispero. Dominant dans les entreprises et les administrations américaines.
• NVDA (NonVisual Desktop Access), principal lecteur d'écran libre et open source pour Windows, sorti pour la première fois en avril 2006 par Michael Curran et James Teh (tous deux aveugles eux-mêmes). L'organisme à but non lucratif NV Access a été créé début 2007. La croissance de NVDA a été la tendance la plus frappante du marché des lecteurs d'écran au cours de la dernière décennie.
• VoiceOver : intégré aux systèmes d'exploitation d'Apple. Apparu pour la première fois dans Mac OS X 10.4 Tiger (2005) ; ajouté à iOS avec l'iPhone 3GS (2009). Désormais livré sur macOS, iOS, iPadOS, tvOS et watchOS.
• TalkBack : le lecteur d'écran intégré équivalent sur Android, maintenu par Google.

Autres technologies d'assistance de l'écosystème au sens large : les agrandisseurs d'écran (ZoomText pour Windows, l'agrandisseur intégré de macOS), les logiciels de reconnaissance vocale (Dragon NaturallySpeaking), les dispositifs d'accès par contacteur pour les utilisateurs à motricité réduite, les claviers alternatifs et les pointeurs à la tête, les systèmes de suivi oculaire et les afficheurs braille éphémères. Les critères des WCAG concernent tous ces cas, même lorsque la page ne pense qu'aux lecteurs d'écran.

Le contraste des couleurs : le modèle des WCAG 2 et le candidat APCA

Les WCAG 2.x mesurent le contraste comme un rapport de luminance entre deux couleurs, un nombre allant de 1:1 (aucun contraste) à 21:1 (blanc pur sur noir pur). Les seuils : niveau AA, texte normal 4,5:1 ; texte large (18 pt ou 14 pt gras) 3:1 ; niveau AAA, texte normal 7:1 ; texte large 4,5:1. Le critère §1.4.11 Non-Text Contrast des WCAG 2.1 a ajouté une exigence de 3:1 au niveau AA pour les composants d'interface et les objets graphiques porteurs d'information.

Le modèle du rapport de luminance a des faiblesses connues, en particulier qu'il surestime le contraste perçu des couleurs foncées ; une paire de deux couleurs foncées à 4,5:1 peut être fonctionnellement illisible même si elle réussit techniquement. L'APCA (Accessible Perceptual Contrast Algorithm), mis au point par Andrew Somers, est un remplaçant fondé sur la perception, conçu pour les écrans auto-illuminés. C'est la méthode de contraste candidate pour les WCAG 3.0, qui ne fait actuellement partie d'aucune version publiée des WCAG. L'APCA produit un nombre signé sur une échelle allant à peu près de -108 à +108 (négatif lorsqu'un texte clair repose sur un fond foncé). Les praticiens qui livrent en 2026 devraient encore tester par rapport aux rapports des WCAG 2.x comme exigence légale, en traitant les scores APCA comme des vérifications perceptuelles complémentaires.

L'état du domaine, en chiffres

L'instantané annuel le plus cité est le rapport Million de WebAIM, qui, depuis 2019, effectue des contrôles d'accessibilité automatisés sur les pages d'accueil du million de sites web les plus visités au monde. L'édition WebAIM Million 2026, publiée en mars 2026, est la plus récente au moment où nous écrivons. 95,9 % des pages d'accueil présentaient des échecs WCAG 2 détectés (contre 94,8 % en 2025, le premier renversement d'une tendance à l'amélioration sur six ans). La page moyenne comptait 56,1 erreurs d'accessibilité détectées, soit une augmentation de 10,1 % d'une année sur l'autre. Les six types d'erreurs les plus courants représentent environ 96 % de tous les problèmes détectés :

1. Texte à faible contraste : 83,9 % des pages, environ 34 occurrences par page en moyenne
2. Texte alternatif manquant sur les images, 53,1 %
3. Étiquettes de formulaire manquantes : 51,0 %
4. Liens vides : 46,3 %
5. Boutons vides : 30,6 %
6. Déclaration de langue de document manquante : 13,5 %

Pour situer le contexte : 1,3 milliard de personnes dans le monde, soit environ 16 % de la population mondiale, ou à peu près 1 sur 6, vivent avec un handicap significatif, selon la fiche d'information de l'Organisation mondiale de la santé mise à jour pour la dernière fois le 7 mars 2023.

D'où proviennent les ressources de ce répertoire

Le répertoire ci-dessus puise dans le petit nombre d'organisations et de projets qui définissent véritablement le domaine :

• W3C Web Accessibility Initiative (WAI). L'organisme de normalisation lui-même. Les deux groupes de travail les plus actifs pour les équipes de sites sont l'Accessibility Guidelines Working Group (qui maintient les WCAG) et l'ARIA Working Group (qui maintient WAI-ARIA). La WAI publie des pages de présentation, des spécifications techniques détaillées, la Quick Reference et des cours éducatifs gratuits sur edX.
• WebAIM (Web Accessibility In Mind). Fondé en 1999 au Center for Persons with Disabilities de l'Université d'État de l'Utah. Exploite l'outil d'évaluation WAVE, mène le Screen Reader User Survey et le WebAIM Million, et publie l'une des bibliothèques d'articles pratiques sur l'accessibilité les plus consultées du web.
• Deque Systems. Fondée en 1999, dont le siège est à Herndon, en Virginie. Éditrice du moteur de règles axe-core, qu'elle a passé en open source en juin 2015. Deque gère également la Deque University et produit l'extension de navigateur axe DevTools, devenue l'outil de test automatisé par défaut du secteur.
• A11Y Project. Une ressource et une bibliothèque de modèles open source, animées par la communauté, fondées en 2013. Surtout connu pour sa liste de contrôle d'accessibilité largement partagée ; l'ensemble du site est sur GitHub, ouvert à la contribution de la communauté.
• International Association of Accessibility Professionals (IAAP). Organisme professionnel fondé le 19 mars 2014, devenu une division de G3ict en juillet 2016. Administre les certifications reconnues du secteur (CPACC, WAS, CPWA, ADS).
• MDN Web Docs. La référence pour développeurs de Mozilla, y compris la section sur l'accessibilité, tenue à jour, qui documente ARIA, la sémantique et les modèles d'accessibilité sous l'angle de la mise en œuvre par les développeurs.

En mettant tout cela ensemble : la réponse pratique à « à quelle norme dois-je me conformer » en 2026 est WCAG 2.1 AA comme plancher (parce que la plupart des lois la citent encore) et WCAG 2.2 AA comme cible tournée vers l'avenir. La réponse pratique côté outils de test, c'est axe DevTools pour l'automatisation, plus un vrai lecteur d'écran (NVDA + Chrome sous Windows, VoiceOver + Safari sous macOS) pour les parties qu'aucun outil automatisé ne peut détecter ; Deque présente elle-même axe comme détectant « jusqu'à 80 % des problèmes », et la plupart des estimations indépendantes situent la détection automatisée à 30-50 % de la conformité WCAG totale. Un test manuel avec un vrai lecteur d'écran reste nécessaire.