Accessibilité dès la conception : RGAA, WCAG 2.2 et EAA

Concevoir une interface accessible, c'est prendre dès la maquette les décisions qui permettront à toute personne, quel que soit son handicap, d'utiliser l'application : contrastes suffisants, information jamais portée par la seule couleur, cibles assez grandes, focus visible, ordre de lecture logique, textes alternatifs, messages compréhensibles. Ce chapitre fait le point sur les obligations en vigueur en novembre 2026 (RGAA, European Accessibility Act), présente les exigences des WCAG 2.2 qui se décident à la conception, montre comment calculer un contraste et comment annoter une maquette pour l'accessibilité.

Pourquoi décider l'accessibilité dans la maquette

L'accessibilité se vérifie dans le code, mais elle se gagne ou se perd bien avant. Une palette de couleurs trop pâle, un statut indiqué par un simple point de couleur, un planning qui ne fonctionne qu'au glisser-déposer, des icônes sans libellé : une fois dessinés et validés par le client, ces choix sont codés tels quels, et les corriger plus tard coûte cher. Les développeurs du cours HTML et CSS apprennent à coder une page accessible ; ce chapitre s'adresse à celui qui conçoit l'écran.

Les situations à garder en tête sont variées : une personne aveugle qui utilise un lecteur d'écran (NVDA ou JAWS sous Windows, VoiceOver sur Mac et iPhone, TalkBack sur Android) et navigue au clavier ou par gestes ; une personne malvoyante qui agrandit l'affichage, comme Brigitte et son zoom à 150 % ; une personne daltonienne, qui ne distingue pas certaines couleurs ; une personne qui ne peut pas utiliser de souris et navigue au clavier ou à la commande vocale ; une personne qui a des difficultés de lecture ou de concentration. S'y ajoutent les situations temporaires (un bras dans le plâtre) et de contexte (le soleil sur l'écran du téléphone de Mathis, les mains prises de Noah). Ce qui est indispensable pour certains est utile à tous.

Ce que dit la loi en 2026

Deux textes imposent aujourd'hui l'accessibilité numérique en France.

L'article 47 de la loi du 11 février 2005 vise les services publics en ligne et les entreprises dont le chiffre d'affaires en France dépasse 250 millions d'euros. Ils doivent rendre leurs sites, applications mobiles et progiciels conformes au RGAA (référentiel général d'amélioration de l'accessibilité), publier une déclaration d'accessibilité et un schéma pluriannuel. Le cours présence en ligne détaille ces obligations et la déclaration.

L'European Accessibility Act (directive (UE) 2019/882, transposée en France en 2023) s'applique depuis le 28 juin 2025 à des produits et services destinés aux consommateurs, quelle que soit la taille de l'entreprise, à une exception près. Les services concernés sont notamment :

• le commerce électronique ;
• les services bancaires aux consommateurs ;
• les éléments des services de transport de voyageurs (sites, applications, billets électroniques, informations) ;
• les livres numériques et leurs logiciels de lecture ;
• les services de communications électroniques et l'accès aux services de médias audiovisuels.

L'obligation porte sur les sites web et sur les applications mobiles qui fournissent ces services. Les microentreprises qui fournissent des services (moins de 10 personnes et un chiffre d'affaires annuel ou un total de bilan d'au plus 2 millions d'euros) en sont exemptées.

Et Prêt'Matos ? Application interne d'une PME de 14 salariés, il n'entre ni dans l'article 47 ni dans l'European Accessibility Act. Mais un salarié en situation de handicap doit pouvoir faire son travail : l'employeur doit prendre les mesures appropriées pour cela (article L5213-6 du Code du travail), et une application interne inaccessible est un obstacle qu'il devra lever. Concevoir accessible dès le départ coûte peu ; rendre accessible après coup coûte cher.

Les WCAG 2.2 en bref

Les WCAG (Web Content Accessibility Guidelines) sont le standard international du W3C. La version 2.2, publiée en octobre 2023 et mise à jour en décembre 2024, compte des critères de succès rangés sous quatre principes : le contenu doit être perceptible, utilisable, compréhensible et robuste. Chaque critère a un niveau : A (minimum), AA (le niveau exigé par la loi, en France comme en Europe) et AAA (renforcé). Ils s'appliquent aux sites web, et la norme EN 301 549 les étend aux applications mobiles, aux logiciels de bureau et aux documents.

La version 2.2 a ajouté neuf critères, dont six de niveau A ou AA, presque tous liés à la conception, et retiré le critère 4.1.1 (analyse syntaxique), devenu inutile :

Les trois autres (2.4.12, 2.4.13 et 3.3.9) sont de niveau AAA.

Ce qui se décide dans la maquette

Voici les exigences des WCAG que le concepteur tranche avant le développeur. Pour chacune, la règle, le critère et ce que cela donne sur Prêt'Matos.

Calculer un rapport de contraste

Le rapport de contraste compare la luminance relative (la clarté perçue, entre 0 pour le noir et 1 pour le blanc) des deux couleurs. Il va de 1:1 (deux couleurs identiques) à 21:1 (noir sur blanc).

1. Pour chaque canal R, G, B (de 0 à 255) :   c = valeur / 255
   puis    c ≤ 0,04045  →  c' = c / 12,92
           sinon        →  c' = ((c + 0,055) / 1,055) ^ 2,4

2. Luminance relative :   L = 0,2126 × R' + 0,7152 × G' + 0,0722 × B'

3. Rapport de contraste : (L_claire + 0,05) / (L_foncée + 0,05)

Pour le gris #767676 (118 sur chacun des trois canaux) : c = 118 / 255 ≈ 0,4627, puis c' = (0,5177 / 1,055)^2,4 ≈ 0,1812 ; les trois canaux étant égaux, L ≈ 0,1812. Sur fond blanc (L = 1), le rapport vaut (1 + 0,05) / (0,1812 + 0,05) = 1,05 / 0,2312 ≈ 4,54:1. C'est conforme pour le texte courant, de justesse ; le gris #777777, à peine plus clair, tombe à 4,48:1 et ne l'est plus. Un rapport se compare au seuil sans l'arrondir : 4,48 n'est pas « environ 4,5 ».

Personne ne calcule cela à la main au quotidien : les outils de développement des navigateurs affichent le rapport quand on inspecte un texte, et des outils gratuits comme Colour Contrast Analyser le donnent en pointant deux couleurs à l'écran. Mais savoir d'où vient le chiffre permet de comprendre pourquoi un vert vif qui « se voit bien » échoue avec du texte blanc.

Voici la palette proposée au départ pour Prêt'Matos, et ce que l'équipe en a gardé :

Annoter une maquette pour l'accessibilité

Une maquette montre l'apparence ; elle ne dit pas tout ce que le développeur doit coder. Ajoute des annotations d'accessibilité, dans la marge ou sur un calque à part :

• la structure : le titre principal de l'écran, les sous-titres et leur niveau, les zones (en-tête, navigation, contenu principal) ;
• l'ordre de tabulation, numéroté sur les éléments interactifs, quand il n'est pas évident ;
• le texte alternatif de chaque image utile, et « décorative » pour les autres ;
• le nom accessible de chaque bouton qui n'a qu'une icône (« Annuler la réservation du 24/03 », pas « corbeille ») ;
• les comportements du focus : où il va quand une fenêtre s'ouvre, quand elle se ferme, après l'envoi d'un formulaire ;
• les annonces pour les lecteurs d'écran : « Réservation enregistrée » lu automatiquement, « Chargement… » annoncé.

Ces annotations font gagner du temps à tout le monde : le développeur sait quoi coder, le testeur sait quoi vérifier, et la recette ne découvre pas les problèmes à la fin. Les chapitres 10 et 11 montrent leur traduction en HTML et React, puis en React Native et WinForms.

Tester tôt, et pas seulement avec un outil

Trois vérifications se font sur la maquette ou le prototype, avant le code :

1. Les contrastes, avec un outil de mesure.
2. La lecture en niveaux de gris : imprime ou affiche l'écran sans couleurs ; si une information disparaît (le statut, l'erreur), c'est qu'elle reposait sur la couleur seule.
3. Le parcours au clavier, sur un prototype codé ou en le simulant : dans quel ordre passe-t-on ? Voit-on toujours où l'on est ?

Les outils automatiques (Lighthouse, axe DevTools, WAVE) détectent une partie des défauts seulement : ils voient qu'une image a un texte alternatif, pas que ce texte est pertinent. Rien ne remplace une navigation au clavier et quelques minutes avec un lecteur d'écran. Le cours HTML et CSS montre comment mener ces vérifications.

Exercices