Accessibilité : cadre, POUR et obligations légales

Accessibilité : de quoi parle-t-on exactement

1. La définition qui produit du travail, et celle qui n'en produit pas

   On entend généralement par accessibilité « la possibilité pour les personnes en situation de handicap d'utiliser un service ». La définition est exacte et elle est boite, parce qu'elle présente l'accessibilité comme une concession : on rendrait service à une catégorie de personnes, et le produit resterait ce qu'il est.

   La conséquence de cette lecture

   On corrige ce qui gêne visiblement : on ajoute des textes alternatifs sur les images, on agrandit les zones de clic, on met une couleur plus contrastée sur les boutons. On laisse le reste, parce que le reste ne se voit pas quand on n'est pas concerné : les incohérences de navigation, les champs de formulaire sans étiquette, les messages d'erreur qui disparaissent avant d'avoir pu être lus.

   L'autre définition

   L'accessibilité est une qualité du produit, au même titre que la vitesse ou la sécurité. Elle ne s'adresse pas « aux handicapés » mais à qui que ce soit, dans une situation donnée : un écran de formulaire lu sous la pluie, dans un train, avec 2 % de batterie, par quelqu'un qui a mal au poignet, sur un téléphone qu'il n'a pas choisi, avec un lecteur d'écran activé par erreur et jamais éteint depuis.

   Le mobile corrige les deux tiers des problèmes d'accessibilité d'un site. Non pas parce qu'il est « pour les handicapés », mais parce qu'un écran tactile de 6 pouces et une connexion dégradée sont la condition normale de millions de personnes qui se disent perfectly capable de regarder une page web.

   Pourquoi cette différence change le résultat

   Un budget « conformité RGAA » produit une checklist cochée et un site médiocre. Un budget « qualité produit » produit des tests sur des tâches réelles, et découvre des bugs que personne n'avait vus : un label qui n'est pas relié à son champ, une modale qui piège le focus, un message d'erreur qui ne dit pas quoi corriger.

   La question à poser en début de projet

   Pas « la page est-elle accessible ? » mais : quelles tâches doit pouvoir accomplir un utilisateur dans cette situation, et qu'est-ce qui l'en empêche aujourd'hui ? La première question appelle un audit. La seconde appelle un travail, et elle trouve ce que l'audit ne voit pas.

2. Les quatre principes POUR et les trois niveaux qui comptent

   La WCAG 2.2 organise ses exigences autour de quatre principes — Perceivable, Operable, Understandable, Robust — déclinés en principes-directeurs, puis en critères de succès, puis en techniques qui ne sont que des exemples de mise en œuvre.

   Perceivable — l'information doit être-IT disponible

   • Ce qui est uniquement visuel a besoin d'un équivalent.
   • Ce qui est uniquement sonore a besoin d'un équivalent.
   • L'interface s'adapte au contraste et au zoom, sans perte de contenu.
   • Les relations entre les éléments (un label, un titre) sont exposed, pas seulement dessinées.

   Operable — l'interface se manipule

   • Tout est faisable au clavier, sans piège ni délai.
   • Aucun geste exige un seul point de contact : le balayage n'est pas la seule voie.
   • Le contenu ne clignote pas plus de trois fois par seconde.
   • Les titles donnent le contexte : une page qui s'ouvre dans un nouvel onglet l'annonce.

   Understandable — c'est compréhensible

   • La langue de la page est déclarée, y compris les passages dans une autre langue.
   • Chaque page a un titre qui la décrit dans le contexte du site.
   • Les erreurs sont identifiées en texte et décrites, pas signalées par une couleur seule.
   • L'aide contextuelle est disponible quand c'est nécessaire.

   Robust — ça résiste à l'interprétation

   • Le code est valide et les rôles sont exposés : les technologies d'assistance savent ce qu'est un bouton, un champ, un titre.
   • Le nom, le rôle et la valeur de chaque composant sont programmatiquement déterminables.

   Les trois niveaux de conformité, et pourquoi le second compte

   Les critères sont classés de A à AAA par niveau d'exigence. La quasi-totalité des obligations légales et des cahiers des charges demande le niveau AA.

   Deux réflexes à éviter : viser AAA pour se distinguer, et descendre à A pour livrer plus vite. AAA contient des critères très exigeants (durée de vie des messages d'erreur, pas de texte clignotant, niveau de contraste renforcé) qui ne rapportent presque rien au produit. À l'inverse, ignorer les critères A d'Operable — le clavier, la navigation — revient à livrer un site inutilisable pour une partie consistente des utilisateurs, et c'est bien plus grave qu'un manque de contraste sur un lien secondaire.

3. Ce que la loi impose, et à qui

   L'accessibilité n'est pas une bonne pratique volunteer en France : pour un certain nombre d'acteurs, c'est une obligation légale assortie de sanctions.

   Le cas général

   La loi n° 2005-102 du 11 février 2005 pour l'égalité des droits et des chances de participation à la vie sociale impose aux services publics, aux établissements publics et aux entreprises privées obéissant à des obligations de service public une obligation d'accessibilité de leurs services de communication au public en ligne. Le principe retenu est celui de la conformité progressive : un schéma d'amélioration est attendu, avec un calendrier.

   La déclaration d'accessibilité

   Point le plus souvent manqué : ce n'est pas seulement rendre le site accessible, c'est publier une déclaration d'accessibilité. Elle doit indiquer l'état de conformité constaté, le contenu et les méthodes de l'évaluation, les écarts identifiés et leur justification, et la voie de recours en cas de difficulté. Elle doit être révisée périodiquement et à chaque évolution majeure du site.

   Le RGAA n'est pas la WCAG

   Le RGAA (Référentiel général d'amélioration de l'accessibilité, Dinum) est la déclinaison française du WCAG : il en reprend les principes en 106 critères, chacun accompagné des tests correspondants. Il permet une évaluation reproductible là où la WCAG laisse le choix des techniques.

   À la date de ce cours, la version en vigueur est le RGAA 4.1.2. La version 5 est en cours de rédaction pour une publication attendue fin 2026. Travailler avec le 4.1.2 n'est donc pas un travail provisoire : le RGAA 5 précisera ou complétera les critères du 4.1.2 sans les infirmer, et les audits réalisés avant cette publication resteront valables dix-huit mois.

   La conséquence pratique pour un projet

   Si l'acteur est concerné par l'obligation légale, il n'y a pas d'arbitrage possible entre conformité et calendrier : il y a un risque contentieux. Si le projet est un produit commercial qui vise la France, largument « accessibilité = coût » ne tient pas, parce que la sanction existe et que les grands donneurs d'ordre l'exigent dans leurs propres cahiers des charges.

4. Ce qu'un outil automatique voit, et ce qu'il ne voit pas

   Les outils d'audit automatique ont une place, et il faut savoir précisément laquelle : ils détectent environ un quart des problèmes environ. Les trois quarts restants relèvent du jugement humain.

   Ils sont fiables sur ce qui est calculable

   • Images sans alternative ou avec une alternative vide ou inutile : fiable.
   • Contraste insuffisant calculé sur les couleurs déclarées : fiable.
   • Champs de formulaire sans étiquette reliée : très fiable.
   • Attributs ARIA invalides ou contradictoires : fiable.
   • Rôles sans nom accessible (bouton icône sans texte) : fiable.

   Ils sont aveugles sur ce qui est intentionnel

   • Un texte alternatif présent mais mauvais — il passe le contrôle automatique et décrit l'image d'une façon fausse ou inutile.
   • Un parcours cohérent ou non : l'outil vérifie des éléments isolés, jamais l'enchaînement des tâches.
   • Un message d'erreur utile ou non : il vérifie que le texte existe, pas qu'il indique quoi corriger.
   • Un ordre de tabulation qui correspond à l'ordre visuel : c'est une erreur fréquente et invisible pour l'outil.
   • Le langage : un texte écrit dans une langue approximative passe.

   Ce que « absence de rapport » ne prouve pas

   Un audit automatique qui renvoie zéro erreur ne prouve pas que la page est conforme : il prouve qu'aucun des défauts qu'il sait détecter n'a été trouvé. Entre les deux, il y a la majorité des problèmes qui font mal à un vrai utilisateur. Un audit automatique sans vérification manuelle n'est pas un audit, c'est un filtre.

   La place qui revient au test manuel

   Elle n'est pas dans « corriger les avertissements », qu'un outil fait déjà. Elle est dans deux gestes uniquement humains : naviguer au clavier, ce qui révèle les pièges de focus et les désordres de tabulation, et tester des tâches réelles sur un écran de téléphone vrai en 3G, ce qui révèle les problèmes de contraste, de taille de cible et de temps de réponse que le zoom desktop masque.