Pourquoi l'accessibilité numérique reste pensée comme un sujet à part, et ce que ça change en pratique
Il y a quelques temps, dans une réunion de travail sur les personas d'un projet, j'ai suggéré qu'on prenne en compte les personnes âgées. On m'a répondu: "oui, c'est déjà fait, on a une persona de 50 ans." J'ai précisé : non, je parle de vraies personnes âgées, autour de 75 ans, qui peuvent avoir des problèmes de vue, des difficultés à manier une souris avec précision, ou à lire un texte trop petit. Réponse, sans aucune malice : "ah non, ce n'est pas notre cible".
Je n'ai rien répondu sur le moment. Mais cette phrase m'a fait réfléchir. Parce qu'elle résume à peu près tout ce qui coince quand on parle d'accessibilité numérique dans une entreprise.
Deux constats, une même racine
Depuis, j'ai observé deux choses qui reviennent sans cesse. La première : quand je prononce le mot "accessibilité numérique" en réunion, je récolte surtout des hochements de tête polis — le genre qui signifie "je vois très bien de quoi il s'agit" sans que ce soit vraiment le cas. Si j'ai de la chance, quelqu'un ose demander discrètement ce que ça signifie exactement.
La seconde, c'est exactement ce qui s'est passé avec cette persona de 50 ans : le handicap, et plus largement tout ce qui s'en approche, reste pensé comme une catégorie à part. Un sujet qu'on aborde à côté. Comme si "les personnes concernées" formaient un groupe bien distinct du reste des utilisateurs — homogène, minoritaire, et qu'on pourrait donc, en toute bonne conscience, ne pas considérer comme "la cible".
Ces deux constats ne sont pas deux problèmes séparés. Ce sont deux symptômes du même malentendu : on a toujours présenté l'accessibilité comme un sujet “à part” qui concerne l’équipe RSE (Responsabilité sociale des entreprise) ou au mieux (quand le sujet est pris un peu plus au sérieux) un référent accessibilité avec une petite équipe.
"Pas notre cible" : vraiment ?
Reprenons l'échange sur les personas. D'abord, il y a une confusion classique entre "un peu plus âgé" et "réellement âgé" : 50 ans n'a presque rien à voir avec 75 ou 80 ans en termes de vue, de motricité fine ou d'aisance avec un écran. Ensuite, une idée reçue coriace : les personnes âgées seraient, par définition, hors du numérique — donc pas une cible.
Sauf que la démographie dit l'inverse. Les personnes de 70-80 ans aujourd'hui sont celles du baby-boom : une génération nombreuse, déjà largement connectée, et qui a eu le temps d'accumuler le plus de capital — immobilier, épargne, patrimoine. Une cible à hauts revenus, en somme, pas une cible marginale. Les exclure par négligence, ce n'est pas juste les priver d'un droit d'usage : c'est aussi se priver d'une bonne part de son marché.
Et ce n'est pas un problème qui se réglera avec le renouvellement des générations : les "digital natives" d'aujourd'hui vieilliront aussi.
Difficile, dans ces conditions, de continuer à parler de "cible à part".
Le handicap ne se limite pas à l'âge
Le même réflexe qui a produit "pas notre cible" range aussi le handicap dans une catégorie distincte de la société — avec ses propres dispositifs, ses propres associations. Comme si les personnes concernées formaient un groupe homogène et permanent.
Mais le handicap n'est pas une catégorie, c'est une situation — parfois temporaire, parfois permanente, parfois contextuelle. Et surtout, diversifiée : il recouvre des réalités très différentes — motrices, cognitives, mentales, psychiques, sensorielles, maladies chroniques évolutives ou invalidantes — parfois invisibles, parfois cumulées.
Petite anecdote, en restitution d'audit, un jour, je signale une non-conformité sur la navigation au clavier. Le client, un peu perplexe, me répond : "mais non, ça marche, regardez" — et clique, à la souris, sur le bouton en question. Il ne comprenait pas ma remarque, parce que dans sa tête, "ça marche" voulait dire "je clique dessus et ça fonctionne". L'idée même qu'on puisse — et qu'on doive pouvoir — atteindre ce bouton sans souris ne correspond simplement pas à son expérience à lui. Et ça révélait simplement un angle mort sur une façon de naviguer qu'il n'avait jamais eu besoin d'utiliser lui-même.
Ce qui nous ramène à l'essentiel : l'accessibilité numérique existe d'abord pour des situations de handicap bien réelles et permanentes, où l'absence de prise en compte n'est pas un inconfort, mais une exclusion pure et simple. Voici ce que ça change concrètement, pour des personnes bien réelles :
- Une personne daltonienne à qui on demande de repérer une erreur "en rouge", sans autre indice : on vient de lui rendre l'information inaccessible, sans même s'en rendre compte.
- Une personne dyslexique face à une police trop fine ou un texte trop dense : la lecture devient épuisante, parfois impossible dans un temps raisonnable.
- Une personne aveugle qui utilise un lecteur d'écran : sans balisage HTML correct, l'outil ne peut littéralement rien lui lire de cohérent. Ce n’est pas une gêne mais une porte fermée.
- Une personne avec un tremblement ou une difficulté de préhension, qui ne peut pas cliquer avec précision et dépend du clavier ou d'un dispositif adapté — comme dans la situation ci-dessus.
- Une personne avec des troubles de l'attention, face à une page saturée d'animations, qui n'arrive pas à aller au bout d'une démarche pourtant simple.
- Une personne en difficulté de compréhension face à un jargon administratif, sans reformulation ni exemple concret.
Dans chacun de ces cas, ce n'est pas la personne qui est "en difficulté" : c'est le service conçu pour une seule façon de voir, lire ou naviguer. Et quand ce service est celui d'une administration, des impôts, ou d'un fournisseur d'eau, d'électricité ou d'accès à internet, l'inaccessibilité cesse d'être un défaut d'ergonomie : elle devient un déni de droit — on ne parle plus d'un inconfort, mais de l'impossibilité d'exercer un droit ou d'accéder à un service essentiel.
Ce n'est pas un manque de volonté, c'est une habitude
Voici, je crois, le cœur du sujet : tant que l'accessibilité reste perçue comme un sujet "à côté" — celui des personas qu'on n'a pas — elle n'entre jamais vraiment dans la conception. Pas dans les maquettes dès le départ, pas dans les critères d'un ticket, pas dans les tests avant mise en ligne. Elle arrive après coup, quand tout est déjà figé, au moment où corriger coûte le plus cher.
Un bouton mal contrasté repéré dès la maquette se corrige en quelques minutes. Le même problème découvert après développement, sur un produit déjà en ligne, se corrige en jours, parfois en refonte. Ce n'est pas un manque de bonne volonté qui explique ça, c'est un réflexe de priorisation qui ne dit jamais son nom : celui qui a produit, un jour, un "ah non, ce n'est pas notre cible".
Concevoir large, pas concevoir "pour eux"
Voilà peut-être le changement de posture le plus utile : arrêter de penser l'accessibilité comme une aide qu'on accorde à une minorité, et commencer à la penser comme une qualité de conception qui profite à une diversité d'usages bien plus large qu'on ne l'imagine. Un bouton bien contrasté, un texte alternatif, une vidéo sous-titrée : personne n'y perd. Beaucoup y gagnent.
Et la bonne nouvelle, c'est qu'on peut commencer dès aujourd'hui, sans attendre le moment idéal. Et cela repose surtout sur un changement de mentalité et de processus, à intégrer dès la conception plutôt qu'en bout de chaîne. Une norme existe déjà, le RGAA, avec un encadrement juridique qui se durcit et, désormais, de véritables sanctions.
Trois vérifications à faire dès aujourd'hui, sur n'importe quel produit existant
Le contraste. Le texte et les boutons ont-ils suffisamment de contraste avec leur fond pour être lisibles ?
Les images. Celles qui apportent une information ont-elles un texte alternatif décrivant leur contenu ou leur fonction ? Une image purement décorative, elle, n'en a pas besoin.
Lien d’accès rapide. La page contient-elle au moins un lien qui permet d’accéder à la zone de contenu principale.
Pourquoi ces trois-là plutôt que d'autres critères du RGAA ? Parce qu'on peut les vérifier rapidement, avec un outillage minimal et gratuit (une extension de contraste, ou simplement en inspectant le DOM), Ce sont aussi, dans les audits qu'on mène, parmi les non-conformités les plus fréquentes.
Mais l'IA ne va-t-elle pas s'en charger à notre place ?
On pourrait objecter : avec l'IA, les personnes concernées auront bientôt des outils capables de rendre n'importe quelle interface accessible à leur place — pourquoi investir en amont ? L'argument se heurte à trois limites.
D'abord, ces outils n'inventent pas l'information manquante, ils la devinent — au même titre qu'un lecteur d'écran face à un bouton sans label, la même faille qui trompe un agent IA trompe l'outil censé compenser.
Ensuite, ça déplace la charge sur l'utilisateur : il doit trouver, configurer et faire confiance à un service tiers pour accéder à ce qu'on aurait pu lui rendre directement utilisable — une dépendance de plus, pas une solution.
Enfin, ça ne change rien à l'obligation légale : le RGAA (Référentiel Général de l’Amélioration de l’Accessibilité) et l'EAA (European Accessibility Act) imposent l'accessibilité au service, pas à un correctif que l'utilisateur devrait apporter lui-même. Reporter la responsabilité sur une IA externe, c'est reproduire le réflexe de départ — "pas notre problème, quelqu'un d'autre s'en chargera" — avec un habillage technologique en plus.
Ce qu'on peut retenir
Alors la prochaine fois qu'on vous parle d'accessibilité numérique, n'hésitez plus à poser vos questions. Et si une persona ou un cas d'usage vous paraît "à côté du sujet", jetez-y un second regard — ce sujet nous concerne souvent plus qu'on ne le croit.
On y reviendra bientôt, cette fois avec du concret : les trois vérifications ci-dessus ne sont qu'un point de départ. Dans un prochain article, on détaillera comment le RGAA s'articule avec ces réflexes du quotidien, et surtout comment les intégrer dès la conception.
