Articles

1 - Comment "Scaler" (monter à l’échelle) l’accessibilité numérique grâce aux Design Systems

Ressource :

1. LIVESTREAM - Accessibility NYC Meetup -Jun 2 2026
2. Exemple de Chekclist Accessibilité

Résumé

Centraliser la conception et l’ingénierie aide les organisations à construire de meilleurs services numériques. Des expériences fragmentées surviennent souvent quand des équipes résolvent les mêmes problèmes de façon isolée. Cela entraîne des incohérences visuelles et fonctionnelles qui frustrent les utilisateurs et gaspillent des ressources. En utilisant une bibliothèque partagée de composants accessibles, les équipes peuvent travailler plus efficacement. Cette approche garantit que l’inclusion est intégrée à chaque interaction numérique dès le départ, y compris pour les équipes travaillant pour des administrations publiques, comme l’État de New York, car elle s’appuie sur leur expérience.

Cet article s’appuie sur une présentation donnée à Accessibility New York City (A11yNYC) par Jesse Gardner.

Les services numériques modernes destinés aux gouvernements fédéraux et locaux semblent souvent déconnectés, car ils sont créés par des équipes différentes, utilisant des plateformes variées. Un résident peut commencer son parcours sur un moteur de recherche, arriver sur un site principal, puis passer à un système distinct pour se connecter ou soumettre une demande.

Jesse Gardner est directeur de l’accessibilité et des systèmes de design au sein du New York State Office of Information Technology Services. Ses équipes servent plus de 45 agences de l’État et 20 millions de New-Yorkais. Ils savent que chaque étape peut avoir un aspect et une expérience différents. Résultat : cela peut créer une expérience fragmentée, augmentant l’effort nécessaire à l’utilisateur pour accomplir une tâche.

Quand la conception et le langage changent constamment, cela augmente la charge cognitive de la personne qui utilise le service. Ce n’est pas seulement déroutant : cela peut éroder activement la confiance envers l’organisation qui fournit le service. Si une personne trouve une interface numérique difficile à parcourir, elle peut abandonner et choisir des méthodes plus coûteuses ou plus longues, comme appeler un centre de services.

Cette fragmentation n’est que rarement intentionnelle. La plupart des équipes sont passionnées par leur travail, mais elles opèrent dans des contextes étroits. Elles doivent faire face à une logique métier spécifique, à des exigences de politique publique et à des limites de temps ou d’expertise.

Parce que la technologie évolue rapidement, il est difficile pour chaque développeur individuel de rester à jour sur toutes les bonnes pratiques. Cela conduit les équipes d’une même organisation à résoudre à répétition des problèmes de base identiques.

Intégrer l’inclusion comme fondation technique

Une inclusion numérique véritable exige un travail technique approfondi, qui va au-delà du design visuel. Même si beaucoup de personnes se concentrent sur l’aspect d’un site, il est tout aussi important de considérer l’expérience d’une personne qui utilise un lecteur d’écran ou une navigation au clavier. Par exemple, un bouton ne doit pas seulement être visible : il doit aussi être sélectionnable au clavier et correctement annoncé par les technologies d’assistance.

Beaucoup d’organisations s’attendent à ce que les développeurs soient experts en même temps dans de multiples langages et frameworks. Elles peuvent ne pas disposer de la connaissance spécialisée nécessaire pour mettre en œuvre des standards d’accessibilité complexes. Une équipe centralisée d’experts peut combler cet écart. En se concentrant à la fois sur la conception et l’ingénierie, les organisations peuvent s’assurer de traiter les contraintes techniques avant qu’un produit n’atteigne l’utilisateur.

Déplacer les tests d’accessibilité plus tôt dans le processus de développement est une stratégie plus rentable que de corriger des problèmes après le lancement d’un produit. Tester manuellement les parcours utilisateurs les plus importants permet d’identifier les problèmes majeurs et d’apporter des solutions concrètes aux équipes d’ingénierie. Cette approche collaborative favorise la relation entre équipes et contribue à accroître progressivement la maturité des différents groupes au sein d’une grande organisation.

Tirer parti d’un système de design centralisé

Un système de design, comme le New York State Design System, est un ensemble de composants partagés, de standards et de lignes directrices qui aident les équipes à construire rapidement des applications utilisables. Il comprend généralement une bibliothèque de code, une bibliothèque de prototypage et un site de référence pour la documentation. Ces outils fonctionnent ensemble pour garantir que chaque produit numérique soit compatible mobile et accessible.

La bibliothèque de code contient des éléments d’interface comme des boutons, des interrupteurs et des accordéons, qui ont été testés en profondeur pour la gestion du focus et la prise en charge par les lecteurs d’écran. Ces composants incluent des réglages accessibles intégrés. Lorsqu’un ingénieur utilise un composant de la bibliothèque, il n’a pas besoin de reconfigurer l’accessibilité lui-même. Cette approche encourage l’adoption en rendant le travail du développeur plus simple, tout en assurant un résultat de haute qualité.

Les design tokens sont un autre élément essentiel de cette base. Ce sont de petites décisions sémantiques pour des éléments comme les couleurs et l’espacement. Par exemple, une couleur spécifique « danger » pour les messages d’erreur peut être testée à l’avance pour le contraste. Même si une équipe ne peut pas utiliser une bibliothèque complète de composants, elle peut tout de même utiliser ces briques pour s’assurer que ses designs personnalisés respectent des standards d’inclusion de base.

Favoriser l’adoption grâce à des solutions concrètes

La clé d’un système de design réussi est de le rendre aussi simple que possible à adopter pour les équipes. La plupart des personnes visitent un site de référence de système de design parce qu’elles doivent construire une page ou livrer un service, pas forcément pour étudier l’accessibilité. En fournissant du code prêt à l’emploi et des « quick wins », le système résout le problème de l’assiduité : il répond directement à un besoin immédiat.

Une fois que les équipes utilisent le système, les informations sur l’accessibilité peuvent être intégrées directement à leur flux de travail. Les pages des composants peuvent inclure des checklists sur le comportement, l’interactivité et le contraste des couleurs. Ainsi, designers et ingénieurs apprennent des pratiques inclusives en travaillant. Avec le temps, cela crée une culture où l’accessibilité est considérée comme un élément central du processus de développement, plutôt que comme une réflexion après coup.

Pour les équipes qui travaillent sur des systèmes existants qu’elles ne peuvent pas migrer vers une nouvelle bibliothèque, fournir une guidance « construire accessible » est essentiel. Cela inclut de montrer comment obtenir les mêmes résultats à l’aide d’éléments HTML natifs et d’un CSS spécifique. Proposer plusieurs façons d’atteindre un objectif permet de faire profiter davantage d’équipes aux travaux de l’équipe centralisée, quelle que soit leur contrainte technique.

Standardiser les outils numériques crée une expérience d’interaction cohérente pour tout le monde. Même si tous les sites n’ont pas besoin de se ressembler visuellement, la manière dont une personne interagit avec un formulaire ou un menu doit être prévisible. Cette cohérence réduit les frictions et rend plus facile l’obtention de l’aide nécessaire auprès de son gouvernement ou de son organisation.

Se concentrer sur le parcours utilisateur et mettre à l’échelle des solutions techniques permet aux organisations de respecter les échéances de conformité tout en améliorant l’utilisabilité globale. Quand « le déclic » survient chez un ingénieur et qu’il comprend pourquoi l’ordre des en-têtes ou l’usage des landmarks a de l’importance, la qualité de tout ce qu’il construit s’améliore. Un système de design formalise ces meilleures pratiques, et les rend disponibles à tous.

Ce que les organisations peuvent faire ensuite

1. Mettre en place une équipe centralisée d’experts pour créer et maintenir une bibliothèque partagée de composants accessibles.
2. Réaliser des tests manuels d’accessibilité sur les parcours utilisateurs les plus courants pour identifier et prioriser les principaux obstacles.
3. Fournir aux ingénieurs des conseils clairs, en langage simple, qui expliquent à la fois comment corriger un problème et l’impact humain de ce problème.
4. Utiliser des design tokens pour les couleurs et les polices afin de garantir que même les éléments construits sur mesure respectent au minimum le contraste et les standards de marque.
5. Créer un site de référence proposant des exemples de code « copier-coller » afin de faciliter l’adoption de modèles accessibles.

Cultiver une culture de fiabilité

Mettre à l’échelle l’accessibilité est un engagement de long terme qui exige à la fois des outils techniques et des changements culturels. En fournissant des solutions de haute qualité qui rendent la vie des développeurs plus simple, les organisations peuvent naturellement favoriser l’adoption de pratiques inclusives. Cette approche s’éloigne d’un modèle de contrôle/police au profit d’un modèle d’habilitation.

Au final, il s’agit de s’assurer que chaque individu peut naviguer dans des services numériques avec dignité et autonomie. Quand l’accessibilité est intégrée à la base d’un système de design, elle devient naturellement une partie de chaque projet. Cette fiabilité discrète crée un monde numérique plus inclusif pour tous les utilisateurs.

Bio de Jesse Gardner

Jesse Gardner est directeur de l’accessibilité et des systèmes de design au New York State Office of Information Technology Services, où il dirige deux équipes au service de plus de 45 agences de l’État et de 20 millions de New-Yorkais. Il a construit le New York State Design System depuis zéro et a mené la réponse de l’État à la date limite de conformité à l’accessibilité exigée par le DOJ pour le Title II (récemment prolongée jusqu’en avril 2027).

Avant de rejoindre le secteur public, Jesse a passé plus de deux décennies dans l’ingénierie logicielle et le leadership en conception. Il parle régulièrement de l’intersection des systèmes de design, de l’accessibilité et de l’IA (plus récemment à Into Design Systems 2026) et écrit sur plasticmind.com. Il vit dans le nord de l’État de New York avec sa femme et leurs quatre enfants.

FAQ

Comment gérez-vous l’adoption progressive et l’évolution des composants dans un système de design ?

Les composants doivent être conçus pour être extensibles, afin de permettre aux équipes d’utiliser des surcharges CSS pour des besoins spécifiques comme les couleurs d’arrière-plan. Une stratégie de versionnement, comme l’utilisation d’un gestionnaire de paquets type NPM, permet aux équipes de mettre à jour leur bibliothèque à leur rythme, sans craindre des changements soudains et “cassants”.

Est-il possible d’utiliser les fonctionnalités d’accessibilité d’un système de design si mon organisation a sa propre charte graphique ?

Oui, si le système est open source, d’autres acteurs peuvent l’adapter pour répondre à leurs besoins. Les organisations peuvent remplacer les thèmes de couleurs dans des outils comme Figma tout en bénéficiant du travail d’accessibilité sous-jacent intégré aux composants.

Comment rendre des pages numériques plus accessibles si je n’ai pas de contrôle sur les composants sous-jacents du système ?

Commencer par les bases, comme éviter les PDF et les images inutiles, est un excellent premier pas. Vous pouvez aussi vous concentrer sur un contraste élevé pour le texte et les boutons. Utiliser des tests manuels avec un lecteur d’écran pour écouter exactement ce qui est annoncé sur la page peut aider à repérer des problèmes que les scanners automatisés manquent parfois.

Quelle est la meilleure façon de gérer la résistance au changement des parcours de travail établis entre différentes agences ?

Les échéances de conformité peuvent être un puissant moteur de changement. Il est utile de partir des besoins des utilisateurs et d’être le plus pragmatique possible lorsque vous proposez des correctifs. Donner aux équipes une meilleure compréhension de l’accessibilité grâce à la formation et à des consignes claires aide à faire passer la discussion de la simple conformité à l’amélioration réelle des services pour tout le monde.

Comment mesurer si un système de design améliore l’expérience utilisateur ?

L’adoption peut être suivie dans les flux de travail de conception et d’ingénierie. Au-delà de l’adoption technique, les organisations devraient mener des recherches utilisateurs pour tester comment ces modèles fonctionnent dans des scénarios réels. Formaliser les modèles qui ont fait leurs preuves dans le système de design garantit que même les projets avec un budget limité peuvent bénéficier de recherches utilisateurs validées et de haute qualité.

2 - Tests d’accessibilité web, bases et plus encore - Applause

Ce guide complet de test d’accessibilité web définit l’approche. Il clarifie les bénéfices essentiels — de la réduction des risques à l’élargissement de la base de clients — et explore la signification de termes comme « A11y », le design inclusif et le design universel. Plus important encore, nous poserons une base d’empathie et de compréhension en examinant les différents modèles théoriques du handicap.

Ce guide de test d’accessibilité web est conçu pour offrir une voie claire et concrète afin de publier des expériences digitales inclusives, conformes et optimisées pour tous les utilisateurs.

Ce guide de test d’accessibilité web en trois parties inclut les articles suivants :

• Tests d’accessibilité web : bases, parties prenantes et inclusivité
• Tests d’accessibilité web : plan d’action et intégration au SDLC
• Tests d’accessibilité web : audits, enseignements et écosystèmes

De nombreux professionnels du produit, de l’ingénierie et de l’assurance qualité ont une certaine compréhension de ce que sont les tests d’accessibilité web, mais une confusion peut apparaître autour de la terminologie associée. Commençons par quelques questions fréquemment posées sur les tests d’accessibilité.

Résumé

1. Les tests d’accessibilité web garantissent que les produits numériques sont utilisables par tous, y compris avec des technologies d’assistance.
2. L’accessibilité apporte des bénéfices business : réduction des risques, meilleure expérience utilisateur, plus de clients potentiels et renforcement de la confiance.
3. Elle diffère du design inclusif et du design universel : l’inclusif va plus loin que la conformité, en concevant pour la diversité dès le départ.
4. Les modèles théoriques du handicap (notamment le modèle social) rappellent la responsabilité des marques : supprimer les barrières, pas “corriger” les individus.
5. Une approche proactive d’audit et de tests intégrés au cycle de développement permet de passer d’une logique de défense à un leadership inclusif.

Qu’est-ce que le test d’accessibilité web ?

Le test d’accessibilité est une partie essentielle du développement logiciel qui aide à garantir que les logiciels, sites web, applications et produits digitaux peuvent être utilisés facilement par les personnes en situation de handicap (PSH) et par tout utilisateur recourant à une technologie d’assistance.

Les testeurs utilisent des technologies d’assistance ainsi que divers autres types de tests, comme des tests fonctionnels manuels ou automatisés, afin d’évaluer les fonctionnalités d’accessibilité et d’identifier les axes d’amélioration. En général, ces audits visent à repérer les problèmes d’accessibilité les plus critiques. Ils tiennent aussi compte de la sévérité et de l’impact des problèmes moins critiques par rapport au temps, à l’effort et aux ressources disponibles pour les corriger.

En général, chez Applause®, nous utilisons souvent des audits pour :

• déterminer les types et la fréquence des problèmes rencontrés sur les pages
• identifier les défauts d’accessibilité web les plus critiques
• établir une liste de problèmes d’accessibilité à fort impact que l’équipe de développement peut traiter immédiatement

Pourquoi les tests d’accessibilité web sont-ils importants ?

Les tests d’accessibilité répondent aux frictions rencontrées par les utilisateurs recourant à une technologie d’assistance. Par exemple, une page peut ne pas prendre en charge la navigation au clavier ou bloquer les connexions au compte. Ces manquements entraînent une perte de revenus et une atteinte à la marque. Les tests vérifient aussi le logiciel par rapport aux fonctionnalités qu’un client pourrait exiger, lesquelles sont encadrées par les Web Content Accessibility Guidelines (WCAG) et l’European Accessibility Act (EAA).

Il existe bien d’autres lois et politiques d’accessibilité web dans le monde. Les organisations ont un besoin constant de tester l’accessibilité ; et il n’existe pas de « certification d’accessibilité » légalement contraignante que l’on pourrait obtenir une fois puis ne plus prendre en compte.

Quels sont certains bénéfices des tests d’accessibilité web ?

Des tests d’accessibilité web complets procurent plusieurs avantages business clés. Ils offrent des incitations juridiques et financières intrinsèques en aidant les marques à éviter les procès et les sanctions en cas de non-conformité. Se concentrer sur l’accessibilité améliore l’expérience utilisateur pour tout le monde, pas seulement pour les personnes en situation de handicap. Cela élargit aussi votre base de clients potentielle en incluant des populations vieillissantes et 1,3 milliard de personnes présentant un handicap significatif. Enfin, cela renforce la confiance envers la marque et sa réputation sur le marché.

Passons en revue ces bénéfices individuellement.

Incitations juridiques et financières. Aux États-Unis, les poursuites liées à la non-conformité à l’ADA sont en hausse. La non-conformité à la Section 508 limite l’accès aux contrats publics, ce qui pousse les organisations conformes à pouvoir candidater dans cet espace. Dans l’UE, l’EAA impose aussi la conformité, avec des pénalités financières en cas de non-respect.

Le design d’expérience utilisateur inclusif aide tout le monde. En se focalisant sur l’accessibilité numérique, on améliore les expériences digitales pour tous et on favorise l’innovation produit et service. Des fonctionnalités comme les sous-titres, le texte alternatif, la dictée vocale et la navigation au clavier sont essentielles pour les personnes en situation de handicap, mais aident aussi d’autres utilisateurs dans différents contextes, comme des environnements bruyants ou des situations « mains libres ». Rendre les produits numériques plus faciles à interagir et à percevoir augmente la convivialité pour tous.

Élargir le potentiel de base de clients. Les tests d’accessibilité numérique peuvent aider les entreprises à toucher davantage de clients. Les utilisateurs plus âgés, les personnes ayant des limitations temporaires ou situationnelles et celles utilisant des technologies d’assistance bénéficient tous de fonctionnalités accessibles. Dans une population mondiale vieillissante, l’accessibilité numérique devient un investissement à long terme pour étendre la portée auprès des utilisateurs. De plus, on estime que 1,3 milliard de personnes dans le monde vivent avec un handicap significatif. Ajoutez-y des millions ou des milliards d’amis et de membres de leur famille qui en prennent note : il y a un véritable impact sur les revenus lorsque les marques priorisent l’accessibilité numérique.

Réputation et confiance renforcées. Les marques qui accordent la priorité à l’accessibilité web peuvent améliorer la perception publique en montrant un engagement envers l’inclusion et la diversité. Ces efforts, ainsi que des évaluations positives dans les stores d’applications et d’autres signaux positifs, résonnent auprès des consommateurs et des employés sensibles aux enjeux sociaux. En outre, l’accessibilité web peut améliorer des aspects techniques des propriétés digitales, comme les performances de l’optimisation pour les moteurs de recherche et une meilleure cohérence de conception.

Quelle est la différence entre tests d’accessibilité, design inclusif et design universel ?

Les tests d’accessibilité, le design inclusif et le design universel sont liés, mais diffèrent par leur portée. Le test d’accessibilité utilise des technologies d’assistance pour vérifier la conformité aux standards WCAG, selon les exigences du client. Le design inclusif est un processus centré utilisateur qui intègre des retours d’utilisateurs divers dès le début du développement. Le design universel crée des produits utilisables par tous les individus sans adaptation, comme les rampes d’accès. Ensemble, ces pratiques aident les entreprises à garantir que leurs produits sont accessibles fonctionnellement et réellement inclusifs pour tout le monde.

• Tests d’accessibilité. Les testeurs utilisent des technologies d’assistance pour évaluer les fonctionnalités d’accessibilité et repérer des axes d’amélioration. Les tests d’accessibilité sont réalisés manuellement avec technologie d’assistance et complétés par des tests automatisés. Les testeurs comparent les résultats aux normes définies par les WCAG et aux nombreuses lois internationales qui encadrent l’accessibilité web.
• Design inclusif. Le design inclusif est un processus centré utilisateur qui aide les organisations à construire des produits, services et environnements utilisables par le plus large ensemble possible de personnes. Il implique d’inclure, aussi tôt que possible, les utilisateurs visés du produit ou des services afin d’intégrer leurs retours dans la conception et le développement.
• Design universel. Lancé par Ronald Mace dans les années 1980, le design universel est un concept de conception applicable à tout secteur, y compris les applications logicielles. Le design universel impose une conception utilisable par toutes les personnes sans nécessiter d’adaptation ni de spécialisation. Les rampes d’accès sont l’exemple classique du design universel : elles aident tout le monde — personnes en fauteuil roulant, cyclistes, personnes qui poussent des chariots ou des poussettes, etc.

Les pratiques de design inclusif remettent en question l’approche traditionnelle du cycle de développement logiciel (SDLC), qui ne prend pas en compte le plus large ensemble de profils d’utilisateurs possible. Adopter le design inclusif permet aux équipes de conception d’intégrer dès les premières discussions des personnes qui utilisent des technologies d’assistance. L’organisation de développement consulte ces utilisateurs tout au long du SDLC, et pas seulement à la fin, quand il est difficile de corriger les problèmes et beaucoup plus coûteux.

Passer à des pratiques de design inclusif peut amener les organisations à adopter un nouvel objectif, plutôt que de privilégier des mises en production rapides et de retarder les correctifs. La plupart des organisations qui effectuent ce changement constatent rapidement des bénéfices à long terme. Une fois adoptées par la direction et soutenues par la formation et d’autres investissements, les pratiques de design inclusif prennent leur propre élan.

Qu’est-ce que les lettres de demande liées à l’ADA ?

Même si la tendance aux litiges liés à l’accessibilité web est heureusement légèrement en baisse, les États-Unis comptent toujours un grand nombre d’actions en justice. Beaucoup de ces poursuites sont déposées contre des organisations contre lesquelles des plaintes ont déjà été déposées.

Une pratique courante qui peut précéder un procès est l’envoi d’une lettre de demande. Ce sont des documents juridiques envoyés aux organisations par un avocat ou des groupes de défense qui allèguent que le site web ou les applications de l’organisation ne sont pas accessibles pour les personnes en situation de handicap. La lettre décrit les problèmes précis trouvés et demande qu’ils soient corrigés.

Le moyen le plus efficace d’éviter les lettres de demande consiste à travailler régulièrement pour se conformer aux standards d’accessibilité web. Les sites évoluent et des bugs d’accessibilité peuvent apparaître lors de chaque mise à jour ; même les meilleurs sites peuvent donc être ciblés dans le cadre d’un procès. Voici une liste de contrôle rapide pour éviter une lettre de demande :

• Compléter un Voluntary Product Accessibility Template (VPAT). Un VPAT est un modèle standardisé que vous remplissez pour montrer comment votre produit ou service répond aux exigences d’accessibilité. Une fois rempli, il devient un Accessibility Conformance Report (ACR).
• Même si vous n’êtes pas totalement conforme, un ACR montre où en est l’organisation concernant ses efforts d’accessibilité. Publier un ACR indique publiquement que l’organisation travaille à rendre les contenus accessibles numériquement. Cette déclaration publique d’efforts et un plan d’accessibilité peuvent contribuer à prévenir les lettres de demande.

Comment les personnes en situation de handicap abordent-elles l’usage de la technologie ?

Les personnes en situation de handicap veulent utiliser la technologie avec la même liberté et le même respect que tout le monde. Elles utilisent souvent des technologies d’assistance, comme les lecteurs d’écran ou la dictée vocale, pour naviguer dans le monde numérique. Ces outils réduisent les obstacles créés lorsque les standards ne sont pas inclusifs. Les organisations doivent aller au-delà des suppositions et étudier comment leurs clients utilisent concrètement les produits. Développer cette compréhension permet aux équipes de concevoir des produits qui répondent réellement aux besoins de tous les utilisateurs.

Les technologies d’assistance (AT) peuvent traiter des problèmes dans le monde physique, comme les rampes dans les bâtiments. Elles répondent aussi aux obstacles dans le monde numérique. Par exemple, les lecteurs d’écran aident les utilisateurs aveugles ou malvoyants à accéder aux contenus, à naviguer et à vivre l’expérience d’un site web. De même, la technologie de dictée vocale permet à une personne de parler et de voir ses mots traduits en texte écrit.

Au-delà de cette hypothèse de base, les organisations doivent faire le travail nécessaire pour comprendre comment leurs clients prévoient d’utiliser leurs produits et services. Plus vous pouvez favoriser une compréhension des personnes en situation de handicap au sein de l’ensemble de l’entreprise, plus vous pourrez réellement les servir.

Différence entre design inclusif et accessibilité

L’accessibilité numérique consiste à garantir que les produits, services et environnements digitaux sont utilisables par les personnes en situation de handicap. Elle vise à respecter des standards et recommandations établis, comme les WCAG, afin de supprimer les barrières qui empêchent l’accès équitable. Des plateformes comme Windows, macOS, Android ou iOS intègrent déjà des fonctionnalités d’accessibilité, comme les lecteurs d’écran et les loupes d’écran. Par exemple, ajouter un texte alternatif aux images (une description écrite de l’image) permet à une personne utilisant un lecteur d’écran de comprendre le contenu visuel. L’accessibilité concerne la conformité et la capacité technique à accéder et utiliser un produit, quelles que soient les capacités.

Le design inclusif va au-delà de l’accessibilité web en concevant proactivement des expériences qui tiennent compte dès le départ du plus large éventail possible de diversité humaine. Au lieu de traiter les barrières, il met l’accent sur l’empathie et la conception pour tous les utilisateurs, y compris (mais sans s’y limiter) les personnes en situation de handicap. Par exemple, inclure des sous-titres codés aide non seulement les personnes sourdes ou malentendantes, mais aussi celles qui regardent des vidéos dans des environnements bruyants ou celles qui apprennent une nouvelle langue. Le design inclusif consiste à créer des solutions flexibles et centrées utilisateur qui profitent à tout le monde.

En général, l’accessibilité numérique est considérée comme un sous-ensemble du design inclusif. L’accessibilité web vise à satisfaire des exigences techniques et fonctionnelles obligatoires, tandis que le design inclusif est reconnu comme une méthodologie plus large, centrée sur l’humain. Cette approche proactive exige de concevoir en tenant compte de la diversité humaine de manière complète. Il ne s’agit pas seulement de handicaps temporaires ou permanents. Des facteurs comme les capacités, la langue, la culture, l’âge et l’alphabétisation doivent tous influencer la conception du produit.

Un élément critique du design inclusif est l’approche « shift-left ». Cette démarche consiste à intégrer activement les personnes en situation de handicap et leurs retours très tôt dans le SDLC. L’accessibilité web représente souvent un niveau minimal. Le design inclusif vise à dépasser cette limite pour s’assurer que le produit est réellement utilisable. L’objectif est de favoriser l’innovation et de proposer une expérience utilisateur agréable qui profite à tout le monde.

Cadres dirigeants. Ces professionnels de haut niveau se concentrent sur la stratégie, la réputation et la gestion des risques. Ils soutiennent les étapes initiales des programmes d’accessibilité web et de design inclusif et fixent le ton culturel de l’organisation. Ils budgètent aussi les initiatives d’accessibilité numérique et veillent à leur alignement avec les priorités de l’entreprise. Les cadres dirigeants pourraient :

• considérer l’accessibilité numérique comme un différenciateur business, pas seulement comme une exigence de conformité
• reconnaître l’impact financier de l’accessibilité numérique, car elle améliore la portée sur le marché, la fidélité à la marque et la satisfaction client — en plus d’aider à éviter les procès
• s’assurer que les ressources, les délais et les KPI soutiennent des programmes d’accessibilité continus
• impulser un changement culturel où l’accessibilité devient une valeur partagée par toute l’entreprise

Pour les équipes qui lancent de nouveaux programmes d’accessibilité web dans une organisation, il est crucial d’obtenir l’adhésion de la direction dès le départ. Sans cela, les efforts d’accessibilité numérique peuvent rester en silos et manquer de financement.

Équipes juridiques et de conformité. Ces professionnels se concentrent sur la réduction des risques et sur le fait de garantir que l’organisation respecte ses obligations réglementaires. Ils suivent l’évolution des lois et fournissent des conseils pour éviter les litiges et maintenir la conformité. Ils se concentrent généralement sur :

• l’interprétation des lois sur l’accessibilité numérique, comme l’ADA, l’EAA et la Section 508, pour les politiques de l’organisation
• la collaboration avec des experts et des testeurs afin de confirmer la documentation de conformité
• le conseil à la direction sur les risques financiers et réputationnels potentiels
• la garantie que les vendeurs et partenaires tiers respectent les mêmes standards d’accessibilité

Le rôle de l’équipe juridique consiste principalement à protéger l’organisation tout en soutenant son engagement envers l’accessibilité numérique et l’égalité.

Quels sont les modèles théoriques du handicap ?

Les modèles théoriques du handicap fournissent un cadre pour comprendre comment les utilisateurs interagissent avec le monde. Ces modèles influencent la politique publique et la manière dont les organisations conçoivent leurs services. Certains modèles, comme le modèle médical, se concentrent sur le « fait de corriger » les individus. D’autres, comme le modèle social, soutiennent que des environnements inaccessibles produisent le handicap. En comprenant ces modèles, les marques peuvent mieux reconnaître leur responsabilité à supprimer les barrières. Cela garantit que leurs produits digitaux sont équitables et utilisables par chaque client.

Voici quelques modèles théoriques du handicap :

Médical. Considère le handicap principalement comme une condition médicale ou une déficience au sein de l’individu, qui doit être traitée, guérie ou prise en charge par des professionnels de santé. L’attention est portée sur la perception de la personne plutôt que sur l’adaptation de l’environnement.

Social. Déplace l’attention de la personne vers les barrières de la société. Le modèle social affirme que les personnes sont en situation de handicap à cause d’environnements inaccessibles, d’attitudes discriminatoires et du manque d’aménagements, et non à cause de leurs déficiences elles-mêmes.

Économie. Cadre le handicap en termes de participation au travail et de coût financier. Ce modèle théorique examine comment les déficiences et les barrières influencent la capacité d’une personne à travailler, et comment la société évalue le handicap via la productivité et l’impact économique.

Identité sociale ou appartenance culturelle. Interprète le handicap comme une identité positive et une expérience culturelle, de façon similaire à la race, au genre ou à l’ethnicité. Ce modèle théorique du handicap met l’accent sur la fierté, la communauté et la culture partagée.

Charité / tragédie. Envisage le handicap comme une malchance personnelle ou une tragédie qui suscite de la pitié et une réponse charitable. Il présente souvent les personnes en situation de handicap comme dépendantes ou ayant besoin d’aide extérieure, plutôt que comme capables de s’autonomiser.

Une entreprise qui fournit un site web, une application ou un service doit s’efforcer de veiller à ne pas ériger des barrières qui empêchent les personnes handicapées d’utiliser ses produits de manière équitable. À partir de là, nous pouvons nous appuyer sur les modèles sociaux du handicap pour comprendre notre responsabilité. Les marques doivent suivre les attentes — sinon, elles s’exposent à des conséquences.

Applause va au-delà du théorique. Nous proposons une solution complète d’évaluation de l’accessibilité numérique, de bout en bout, qui aide les marques à passer d’une défense juridique réactive à un leadership proactif et inclusif sur le marché. Plutôt que de compter sur des outils automatisés ou des correctifs/widgets d’accessibilité inefficaces, Applause intègre l’accessibilité directement dans votre cycle de développement logiciel en s’appuyant sur une communauté mondiale de personnes réelles en situation de handicap.

Ces testeurs évaluent vos produits numériques avec leurs propres technologies d’assistance, dans leurs environnements naturels, afin de fournir des retours concrets et exploitables. En combinant des évaluations de conformité menées par des experts, des tests pendant le sprint, des études UX centrées sur le design inclusif et une formation à l’empathie, Applause aide les marques à s’assurer que les expériences numériques ne sont pas seulement techniquement conformes, mais réellement équitables et utilisables par tous.

3 - La raison de l’« accessibility designer vibe coding » quand tous ses collègues font aussi du « vibe coding »

J’ai des sentiments compliqués à propos des LLM. Je veux dire, beaucoup de gens que je connais ressentent la même chose. Mais c’est aussi mon blog : j’ai donc le droit de bavarder pontifiquement sur ces émotions et sur ces personnes… de façon consentie, en plus ?

En ce qui concerne le « vibe coding », je dois séparer mes pensées et mes émotions personnelles de mon travail. Ce n’est pas amusant.

Sur le plan émotionnel, j’ai l’impression qu’on me tient une arme à feu sur la nuque, et que cette arme est, d’une manière ou d’une autre, reliée à trois billions de moteurs diesel d’un autre fabricant, qui tournent tous leurs cylindres à plein régime. Intellectuellement, je sais que je suis américain et que j’ai besoin de soins de santé sans interruption.

Qui est mis au centre ?

Pendant que l’industrie court contre la montre pour comprendre comment rendre tout cela productif ou rentable, la question que je ne cesse de me poser est la suivante : est-ce que je laisse mes croyances personnelles et mes biais influencer le résultat que je veux au final ?

Pour moi, le résultat souhaitable est de permettre aux personnes en situation de handicap d’utiliser la technologie là où elles ne le pouvaient pas auparavant.

Comment est-ce fait ?

Je travaille à corriger une expérience que GitHub finance massivement. Et cet effort est « dogfooddé », à 100 % orienté LLM, dans son approche. Du coup, j’ai aussi besoin de faire du vibe coding pour contribuer.

Au passage, quand j’utilise ici l’expression « vibe code », c’est un raccourci pour des demandes rapides en anglais, des plans plus techniques, des fichiers d’instructions correctives, des scripts, des compétences, et d’autres techniques applicables. Je ne fais pas du code directement.

Ce n’est pas une situation du type « quand on est à Rome ». Je suis poussé structurellement à travailler comme ça, et je suis aussi suivi et classé en fonction de la fréquence et du volume de l’utilisation de jetons.

Qu’est-ce qui est produit ?

Je dois l’avouer : en tant que personne douée pour rédiger des spécifications techniques détaillées et pas tellement douée pour écrire du JavaScript, je suis maintenant capable de non seulement corriger l’expérience, mais aussi de l’améliorer.

L’application s’éloigne lentement du simple fait d’être une gigantesque pile de buttons. J’ai ajouté des listes interactives, des treeviews, la navigation F6, la sélection de nœuds typeahead, et d’autres améliorations de qualité de vie. Ma logique de construction de aria-label dissocie désormais impitoyablement et met en premier les informations les plus saillantes, quelle que soit la configuration de l’application ou des composants, ou l’état dans lequel ils se trouvent.

Pour moi, c’est la partie « designer » de mon rôle d’« accessibility designer ».

Je ne crée pas quelque chose qui est techniquement conforme, mais pénible et impossible à utiliser concrètement. Je crée quelque chose qui est conforme et—j’espère—aussi intuitive à utiliser avec des technologies d’assistance.

Incitations et approches

Je pense aussi qu’il vaut la peine de souligner que la culture d’entreprise contemporaine n’incite pas à faire l’effort supplémentaire pour un travail que l’on ne perçoit pas comme ayant un lien direct et immédiat avec la rentabilité. Il n’y a pas de business case pour utiliser l’attribut lang, les gars.

Dans la conception de produits avant l’ère des LLM, les efforts en accessibilité se manifestaient par des négociations : le temps passé par rapport à la conformité légale minimale. En d’autres termes : faire passer ce qu’on peut dans le temps qui vous est accordé.

Dans la conception de produits après l’ère des LLM, le temps nécessaire pour créer et vérifier ces expériences historiquement plus coûteuses est compressé. Il m’a fallu seulement quelques jours—et parfois même quelques heures—pour réparer des composants et des expériences qui, traditionnellement, n’étaient même pas envisageables en termes de financement.

Ici, je me considère comme en train de faire mon travail, mais je sais aussi que l’organisation le perçoit comme un effort supplémentaire. Cependant, le délai de retour plus court fait que la préoccupation de l’organisation est incomparablement, incomparablement plus faible.

En pratique, je suis dans mon petit coin, à hacker sur la chose qui compte pour moi, exactement comme tous mes autres pairs. C’est une manière de travailler solitaire, que les LLM encouragent implicitement. Mais c’est une préoccupation distincte, pour un autre jour.

Interventions et mise en scène

Il vaut aussi la peine de mentionner que, au fur et à mesure, je crée des instructions correctives et des compétences (skills). Elles m’aident à orienter ce que le LLM génère, en le guidant vers des sorties plus spécifiques au domaine et accessibles par défaut.

Les instructions et les compétences me permettent d’amplifier de façon invisible et exponentielle mes efforts autrement presque sisyphiens. Cela me permet hypothétiquement de rester au rythme et à l’échelle de la charge de travail—au moins, jusqu’à ce que quelqu’un finisse par s’offusquer de quelque chose que j’ai écrit et écrive des ordres contraires.

Et en parlant d’anti-instructions et de l’énervement qu’elles causent : cette méthode de travail crée aussi beaucoup moins de friction et de conflits perçus, et c’est quelque chose qu’il faut reconnaître.

Des ajustements structurels invisibles, qui n’affectent pas les visuels de l’expérience, permettent à tout le monde de se sentir bien en voyant que des efforts d’accessibilité sont en cours. Cela réduit aussi l’importance de la tension inévitable quand la conformité légale se heurte aux sensibilités esthétiques.

Ce style d’ajustement indirect et de correction de trajectoire imposée par la machine me permet aussi d’aborder plus diplomatiquement ces moments tendus quand ils surviennent.

Je meurs sur moins de collines. J’ai beaucoup moins besoin de dépenser mon capital politique, et le travail de remédiation visuelle lui-même demande beaucoup moins de temps et d’efforts. C’est énorme.

Anecdote

Je connais aussi des personnes qui utilisent des technologies d’assistance et qui partagent mon point de vue sur les LLM. On parle de la manière dont elles utilisent la technologie pour créer et partager des contournements pour des choses sur le web qui, auparavant, leur étaient opaques et impossibles à comprendre.

Une personne en particulier a fait remarquer qu’avant ça, le seul vrai mouvement était de déposer un ticket d’assistance et d’espérer le meilleur. Et, lecteur, nous savons tous ce qui se passe dans ce cas.

À la lumière de la notion de pouvoir, il s’agit d’une démographie historiquement sous-servie utilisant des outils mis à sa disposition pour obtenir ce qu’elle veut ou ce dont elle a besoin. Cela s’inscrit dans une longue histoire où les personnes en situation de handicap ont été forcées de compter sur l’ingéniosité pour contourner des barrières systémiques.

En prenant du recul

Le travail d’accessibilité numérique exige un niveau extrême de détails et de précision, tout en gardant en tête l’ensemble plus large, holistique.

Écrire des correctifs, et aussi mettre en place des remparts conçus pour résister au futur, nécessite au total encore plus de puissance de calcul. C’est parce que vous luttez contre le biais inhérent des LLM entraînés sur du code majoritairement inaccessible.

Le développement basé sur les LLM rend indéniablement l’internet moins accessible (PDF). Mes efforts ne sont qu’une goutte d’eau.

Je n’ai aussi aucune patience pour la pensée magique—celle avec laquelle les gens, inévitablement, contre-argumentent quand on confronte ce fait à une réalité—où le fonctionnement agentique contourne soudainement ce problème entièrement.

Cela dit, je suis aussi pragmatique.

Les agents LLM peuvent lire et agir sur l’arbre d’accessibilité. Même si je n’aime pas que cela décentre l’expérience humaine pour laquelle tout ça existe, je comprends aussi que c’est l’argument le plus convaincant pour investir dans l’accessibilité numérique que nous obtiendrons. Au moins jusqu’à ce que les natifs du numérique vieillissent et finissent par devenir des personnes en situation de handicap—et ici aussi, je pense que cette façon de fonctionner est temporaire.

Je suis aussi très conscient du lien entre le changement climatique et le handicap, ainsi que de qui est laissé pour compte lors des catastrophes climatiques.

Il est difficile d’échapper au sentiment de culpabilité que je ressens : en tentant de traiter des obstacles à l’accès dans un périmètre étroit à court terme, je contribue aussi à des conditions de désaccessibilisation à grande échelle sur le long terme.

Faire n’est pas toujours apprendre

Il faut aussi dire clairement que je ne confonds pas produire avec apprendre.

J’ai apprécié la possibilité de créer des logiques et des structures que je ne pouvais pas produire auparavant, à cause de mes capacités limitées en JavaScript. Je sais aussi que cette façon de travailler ne me donne pas les compétences plus bénéfiques et plus fondamentales que je désire.

À la place, je m’améliore juste dans le fait d’amener une boîte noire à recracher des jackpots. Je trouve ça bien moins désirable.

Je ne suis qu’un petit gars

Il est, hum, difficile de reconnaître les émotions de mes croyances éthiques et idéologiques personnelles qui entrent en conflit avec des mandats d’entreprise indifférents, façon Crash at Crush-… Ce n’est même pas le fait que le décalage, le churn et l’avidité à découvert qui imprègnent tout depuis un moment ne sont même pas mentionnés.

Je suis une personne qui existe à l’intérieur de systèmes superposés, interconnectés et dysfonctionnels. Et ces systèmes font tous échouer les tentatives de les naviguer ou de les réparer quand elles vont à l’encontre de leurs objectifs.

Le livre Radical Acceptance nous apprend qu’il faut accepter le présent avant de pouvoir développer la résilience nécessaire pour engager de manière constructive une réalité que l’on perçoit comme négative. Mais aussi : il y a une grande partie de la réalité que nous devons accepter en ce moment, et cette acceptation ressemble de plus en plus à une capitulation.

Et non, je n’ai pas utilisé un LLM pour écrire ça.

Pour aller plus loin

• AI and brain-computer interface allow speechless ALS patient to work a full-time job (The Register)
• Screen readers do not need to be saved by AI (Craig Abbott)
• AI Job Grief: The Unnamed Psychological Crisis Hitting Tech Workers (Jack Maguire)

4 - Comprendre le "title II" de l'ADA et les exigences d'accessibilité numérique

L’accès numérique est une composante fondamentale de l’accès aux services publics. Pour les gouvernements d’État et locaux, les sites web, applications mobiles et autres services en ligne constituent souvent le principal moyen d’interaction des résidents avec les administrations : demander des prestations, recevoir des services, payer des factures, accéder à des informations essentielles et participer à la vie civique. Le titre II de l’Americans with Disabilities Act (ADA) établit une exigence juridique claire : les services et programmes des autorités publiques doivent être accessibles aux personnes en situation de handicap. Bien que le titre II existe depuis des décennies, la décision finale du Département de la Justice (DoJ) de 2024 a précisé la manière dont ces obligations s’appliquent aux services numériques, poussant de nombreuses entités publiques à réévaluer ce que la conformité exige et comment démontrer des programmes d’accessibilité numérique utilisables.

Pourquoi le titre II de l’ADA importe aujourd’hui

Les services numériques ne sont plus accessoires aux programmes gouvernementaux. Lorsque ces services sont inaccessibles, les résidents en situation de handicap sont effectivement exclus de la participation, même si l’administration propose techniquement le service. Imaginez un résident aveugle ou malvoyant tentant de payer ses impôts via un portail en ligne : si les champs du formulaire ne sont pas correctement étiquetés, il peut être dans l’incapacité de remplir le formulaire, créant une barrière d’accessibilité. Le résultat est un service numérique disponible et utilisable pour les personnes voyantes, mais qui ne fournit pas un accès égal et effectif au sens du titre II. Pour les utilisateurs aveugles ou malvoyants, l’accès aux services numériques dépend des technologies d’assistance (TA), comme les lecteurs d’écran et les loupes d’écran. Ces outils transforment le contenu numérique en parole, Braille ou affichage visuel agrandi, permettant aux utilisateurs de naviguer indépendamment et d’interagir avec les services en ligne. Lorsque les services numériques ne sont pas conçus pour fonctionner de façon fiable avec les TA, l’accès se brise. En vertu du titre II, l’indépendance et l’égalité d’accès ne sont pas des options ; ce sont des obligations fondamentales.

Ce que couvre le titre II de l’ADA dans les environnements numériques

Le titre II s’applique à tous les programmes, services et activités fournis ou financés par les gouvernements d’État et locaux, indépendamment du mode de prestation, et pas seulement aux bâtiments ou à des pages web isolées. À mesure que les administrations déplacent de plus en plus d’interactions en ligne, cette obligation s’étend pleinement aux environnements numériques. Cela inclut :

Sites web à destination du public fournissant des informations

Applications mobiles délivrant des services, informations ou notifications

Documents numériques, tels que fichiers PDF et Word, formulaires de demande, rapports, comptes rendus de réunions et avis publics

Applications supportant des transactions, portails de services et autres outils en libre-service

Ces propriétés numériques sont souvent interconnectées, et un même service peut dépendre de plusieurs systèmes, types de documents et workflows. En vertu du titre II, l’accessibilité s’évalue sur l’ensemble de l’expérience numérique fournie par un service ou un programme, et ne se limite pas à une page ou un document isolé. Ainsi, la conformité au titre II n’est pas évaluée au niveau d’une fonctionnalité, mais de manière programmatique : le service dans son ensemble est-il accessible ? Si un résident en situation de handicap ne peut pas accomplir de manière autonome une tâche requise — soumettre une demande, accéder à une information urgente ou payer une taxe — le service lui-même peut être considéré comme inaccessible selon le titre II, même si des pages ou composants individuels semblent respecter des normes techniques. Cette exigence est particulièrement pertinente pour les grands écosystèmes gouvernementaux, où les lacunes d’accessibilité apparaissent fréquemment aux points de transition entre systèmes, documents et workflows plutôt qu’au sein d’une seule page.

Accès programmatique et communication efficace

Le titre II oblige les entités publiques à fournir une communication efficace et un accès égal aux services pour les personnes en situation de handicap. Dans les environnements numériques, cela implique de garantir que le contenu, les workflows et les documents fonctionnent de manière fiable avec les lecteurs d’écran et les outils de grossissement, et qu’ils soutiennent l’usage réel par les personnes aveugles ou malvoyantes. Le DoJ a constamment souligné que la communication efficace est une obligation centrale du titre II, et non une simple bonne pratique. À un niveau minimal, la communication numérique efficace inclut :

Les utilisateurs de lecteurs d'écran peuvent naviguer dans le contenu et les workflows dans un ordre logique

Les utilisateurs de loupes d'écran peuvent zoomer, panoramiquer et naviguer sans perte d'information, de fonctionnalité ou de contexte

L'information est accessible sans reposer sur la perception des couleurs

Les éléments interactifs tels que les formulaires peuvent être remplis et soumis au clavier uniquement

Les documents sont structurés pour que l'information soit véhiculée via des titres, listes et en-têtes de tableaux en utilisant les styles de document appropriés

Les messages d'état, notifications, alertes d'erreur et confirmations sont disponibles pour les utilisateur·rice·s de TA

En vertu du titre II, l’accessibilité est une obligation au niveau du service : les utilisateurs doivent pouvoir utiliser les services numériques tels qu’ils sont destinés, sans barrières inutiles ni contournements. Cette distinction explique pourquoi les organisations qui s’appuient uniquement sur des tests automatisés peinent souvent à démontrer leur préparation au titre II. Les organisations doivent évaluer l’accessibilité numérique dans le contexte de l’usage réel des services, pas seulement de la manière dont les composants sont codés.

Comment WCAG s’intègre à la conformité au titre II de l’ADA

Pour clarifier les attentes en matière d’accessibilité numérique, la décision finale du DoJ précise que les sites et applications mobiles couverts doivent se conformer aux Web Content Accessibility Guidelines (WCAG) 2.1 Niveau AA. Développées par le World Wide Web Consortium (W3C), les WCAG fournissent un cadre technique commun pour identifier les barrières d’accessibilité fréquentes dans le contenu numérique. En vertu du titre II, WCAG 2.1 Niveau AA sert de référence minimale pour l’évaluation, mais n’exonère pas de l’obligation plus large d’assurer que les services sont accessibles en pratique. La conformité permet d’identifier des problèmes techniques, tandis que les tests avec TA et la validation des tâches déterminent si les services fonctionnent réellement pour les personnes en situation de handicap.

Comment la conformité au titre II est évaluée en pratique

Le titre II n’impose pas d’outils ou de technologies spécifiques. La conformité s’évalue plutôt sur les résultats : est-ce que les personnes en situation de handicap peuvent accéder et utiliser efficacement les services numériques ? C’est souvent là que les organisations rencontrent des difficultés. Les vérificateurs automatisés peuvent aider à détecter rapidement de nombreux problèmes, mais ils ne peuvent pas évaluer le contexte, le sens ou l’utilisabilité. Cela peut conduire à une conformité de surface produisant des expériences fragiles qui ne tiennent pas dans des situations réelles. En pratique, une évaluation efficace inclut :

Audits d'accessibilité manuels dirigés par des expert·e·s

Tests avec TA, incluant lecteurs d'écran et loupes d'écran

Validation que des utilisateur·rice·s en situation de handicap peuvent accomplir de manière autonome des tâches critiques de bout en bout, en utilisant des TA si nécessaire

Pourquoi la priorisation importe sous le titre II de l’ADA

La plupart des écosystèmes numériques gouvernementaux sont vastes et complexes. Sites, sous‑domaines, documents et systèmes tiers s’étendent souvent sur plusieurs départements et fournisseurs. De plus, de nombreuses entités publiques utilisent un mélange de clouds, systèmes sur site et solutions héritées, ce qui crée aisément des lacunes d’accessibilité. En conséquence, les problèmes d’accessibilité peuvent se compter par centaines ou milliers. Le Government Accountability Office (GAO) a souligné l’ampleur du défi : dans une revue de 2025, le GAO a identifié 11 systèmes IT fédéraux hérités, maintenus sur 10 agences, qui nécessitent une modernisation critique. Bien que ces constats concernent le niveau fédéral, soumis à des règles distinctes, ils illustrent le risque posé par des systèmes obsolètes et des architectures fragmentées qui compliquent la modernisation des services numériques selon une approche priorisée et fondée sur les risques. Répondre aux exigences du titre II dépasse la simple identification du nombre de problèmes : il s’agit de mettre en œuvre une stratégie de traitement priorisée. Une priorisation efficace prend en compte :

L'impact sur les personnes en situation de handicap

La criticité du service ou de la tâche

La fréquence d'utilisation

L'effort nécessaire pour corriger

Le risque juridique et opérationnel

Cette approche aide les organisations à concentrer des ressources limitées là où elles ont le plus d’impact, réduisant le risque tout en améliorant l’accès de manière significative.

De la prise de conscience à l’action

Comprendre le titre II de l’ADA est la première étape vers la préparation. Pour les gouvernements d’État et locaux, la conformité n’est pas un projet ponctuel : c’est une responsabilité continue liée à la manière dont les services numériques sont livrés, maintenus et faits évoluer. Les organisations adoptant une approche structurée et centrée sur l’utilisateur — fondée sur des audits dirigés par des expert·e·s, des tests d’utilisabilité et une priorisation stratégique des efforts de remédiation — sont mieux placées pour fournir et maintenir des services accessibles et démontrer une conformité de bonne foi. Bien que les entreprises privées ne soient pas couvertes par le titre II, les entités publiques doivent évaluer le risque posé par des solutions fournies par des prestataires qui pourraient ne pas satisfaire aux exigences du titre II. De leur côté, les fournisseurs d’outils numériques destinés aux organismes publics doivent être prêts à garantir la conformité de leurs produits au titre II.

Explorer les services d’accessibilité numérique

Les services numériques sont devenus synonymes d’accès public, mais rendre ces services suffisamment accessibles pour répondre aux exigences du titre II de l’ADA peut sembler intimidant. Un partenaire en accessibilité peut simplifier le processus de conformité et aider les organisations à naviguer des exigences réglementaires complexes avec confiance. Fort de plus de 30 ans d’expérience en technologies d’assistance et en mise en œuvre de l’accessibilité, les Digital Accessibility Services de Vispero aident les entités publiques à évaluer l’accessibilité actuelle, identifier les barrières à fort impact et prioriser la remédiation alignée sur le titre II de l’ADA. Notre approche pilotée par des expert·e·s favorise une accessibilité durable sur sites web, applications et contenus numériques, aidant les agences à réduire les risques tout en améliorant l’accès pour les administrés et le personnel. Découvrez comment les Digital Accessibility Services de Vispero soutiennent la préparation au titre II pour les organisations du secteur public.

5 - Achats : Restriction de l’utilisation de l’IA par les prestataires dans les missions clients

Lorsqu’un client fait appel à un prestataire tiers, il lui accorde sa confiance. La confiance que ses données seront protégées, que le travail sera effectué par des professionnels qualifiés, et que le prestataire opérera dans les mêmes limites juridiques et éthiques que lui. L’IA introduit une couche d’opacité susceptible de compromettre discrètement tous ces éléments. La plupart des clients n’apprennent l’utilisation de l’IA qu’au moment où un problème survient, et à ce stade, les dommages — qu’ils soient juridiques, réputationnels ou financiers — sont souvent déjà faits.

Le statut du droit d’auteur des contenus générés par l’IA reste incertain dans de nombreuses juridictions. Si un prestataire utilise secrètement l’IA, le client peut payer pour un travail dont il ne sera finalement pas propriétaire. Une clause contractuelle stipulant que tous les livrables sont rédigés par des humains et que l’intégralité des droits de propriété intellectuelle est transférée au client, libre de toute revendication d’une plateforme d’IA tierce, constitue le minimum indispensable.

Ceci ne constitue pas un conseil juridique, mais ce sont des sujets que toute personne travaillant avec des prestataires devrait aborder avec son conseiller juridique.

Pourquoi les clients limitent l’utilisation de l’IA par les prestataires

Il existe six raisons fréquentes pour lesquelles les clients souhaitent restreindre ou interdire l’utilisation de l’IA dans leurs projets. Chacune dépasse largement la simple case à cocher d’un formulaire d’achat.

Confidentialité et sécurité des données

Lorsqu’un prestataire colle des informations client dans un outil d’IA public, ces données peuvent être utilisées pour entraîner le modèle sous-jacent, conservées indéfiniment sur des serveurs tiers, réapparaître dans les résultats d’un concurrent ou être compromises lors d’un incident dont le client ne sera jamais informé. Pour les données réglementées — notamment les informations médicales protégées (HIPAA), les données personnelles soumises au RGPD, les dossiers étudiants (FERPA) ou les communications couvertes par le secret professionnel — un simple prompt peut constituer une violation déclarable.

Exactitude et responsabilité

L’IA générative produit des contenus qui paraissent convaincants mais peuvent être biaisés ou totalement erronés. Des références sont inventées, des statistiques fabriquées et des cas particuliers discrètement ignorés. Lorsqu’un professionnel qualifié commet une erreur, il existe une licence professionnelle, une assurance responsabilité et une chaîne de responsabilité clairement définie. Lorsqu’une hallucination de l’IA se retrouve dans un livrable, les responsabilités deviennent floues et le client se retrouve souvent à en assumer les conséquences.

Substitution du prestataire sans consentement

Les clients engagent des cabinets pour leur expertise, leurs méthodes et leurs références. Si le prestataire confie discrètement le travail à un grand modèle de langage, le client n’obtient pas ce pour quoi il a payé. Il paie des honoraires de consultant senior pour un contenu généré par un abonnement mensuel à quelques dizaines d’euros.

Risques réglementaires et de conformité

L’utilisation de l’IA fait l’objet d’une réglementation croissante et le cadre juridique évolue rapidement. L’AI Act européen, le Colorado Artificial Intelligence Act (SB 24-205), la loi locale 144 de New York sur les outils automatisés d’aide à la décision en matière d’emploi, ainsi que les directives sectorielles des autorités fédérales et des procureurs généraux des États créent des risques qui peuvent retomber sur le client, même si la décision d’utiliser l’IA provenait du prestataire.

Biais et risques réputationnels

Les modèles d’IA reflètent les biais présents dans leurs données d’entraînement. Les résultats utilisés pour le recrutement, le crédit, le triage médical, la modération de contenu ou l’évaluation de l’accessibilité peuvent produire des résultats discriminatoires, enfreindre les lois sur les droits civiques et nuire durablement à la réputation de l’organisation.

Manque de transparence et d’auditabilité

La plupart des outils d’IA commerciaux ne produisent pas de journaux fiables des prompts, des résultats ou des modifications effectuées avant la livraison. Sans ces traces, le client ne peut ni vérifier ce qui a été généré par l’IA, ni défendre un livrable dans le cadre d’un litige, ni remédier efficacement à un problème découvert ultérieurement.

Peut-on empêcher un prestataire d’utiliser l’IA ?

Oui, à condition de prévoir les clauses contractuelles adéquates. Le reste de cet article décrit les dispositions qui, combinées, permettent au client de conserver un contrôle significatif.

Divulgation avant la signature du contrat

La meilleure protection se met en place avant la signature. Les appels d’offres (RFP) et documents de consultation devraient exiger que les soumissionnaires déclarent par écrit :

• chaque outil d’IA qu’ils prévoient d’utiliser ;
• les tâches précises concernées ;
• les catégories de données susceptibles d’être exposées ;
• les politiques de résidence des données et d’entraînement des modèles de chaque plateforme.

Cela place les fournisseurs sur un pied d’égalité, permet de comparer les offres objectivement et évite de découvrir après coup que l’offre la moins chère reposait sur un usage intensif de l’IA.

Une remarque connexe sur les prix : un livrable réalisé entièrement par des humains coûtera plus cher qu’un livrable assisté par IA. Les clients qui imposent des restrictions à l’IA doivent s’attendre à recevoir des devis plus élevés et budgéter en conséquence. Faire comme si ce n’était pas le cas crée une pression incitant le prestataire à tricher.

Définir l’IA dans le contrat

Les définitions sont essentielles. Les tribunaux et arbitres rechercheront des définitions précises. Le contrat devrait couvrir :

• l’IA générative ;
• les grands modèles de langage (LLM) ;
• les modèles de machine learning ;
• les réseaux neuronaux ;
• les systèmes automatisés de prise de décision ;
• les outils de programmation assistée par IA.

Il devrait également distinguer trois catégories d’usage :

Utilisations interdites

• rédaction générative de livrables ;
• génération de code ;
• analyse de données dont les résultats alimentent le livrable ;
• résumés automatiques de réunions ou documents ;
• toute tâche produisant du texte, du code, des images ou des analyses intégrés au produit final.

Fonctionnalités d’assistance autorisées

• correcteurs orthographiques ;
• correction grammaticale non générative ;
• recherche simple ;
• calculatrices et conversions d’unités.

Utilisations soumises à approbation

Tout ce qui se situe entre les deux catégories précédentes, y compris les fonctions d’IA intégrées dans les outils déjà utilisés par le prestataire.

L’interdiction principale

La clause centrale pourrait être formulée ainsi :

Le Prestataire ne doit utiliser, déployer ou intégrer aucun outil d’intelligence artificielle, de machine learning, de grand modèle de langage, d’IA générative ou de prise de décision automatisée dans l’exécution des services prévus par le présent Contrat, y compris, sans s’y limiter, des outils tels que ChatGPT, GitHub Copilot, Claude, Gemini ou toute technologie similaire, sans l’accord écrit préalable du Client. Cette interdiction s’applique à toutes les phases de la mission, y compris la découverte, l’analyse, la rédaction, la révision et la livraison.

Exceptions possibles (« carve-outs »)

L’IA est désormais omniprésente : fonctionnalités génératives de Grammarly, remplissage génératif d’Adobe, autocomplétion dans les IDE, assistants de réunion, résumés automatiques ou résultats de recherche enrichis par l’IA.

Le contrat devrait prévoir un mécanisme clair d’approbation pour ces cas limites.

Exemple :

Nonobstant l’interdiction précédente, le Prestataire peut utiliser les outils d’assistance autorisés suivants : correcteurs orthographiques et grammaticaux fonctionnant localement et ne transmettant pas d’informations confidentielles du Client à des tiers ; moteurs de recherche utilisés uniquement à titre de référence générale ; calculatrices et outils de conversion d’unités. Toute fonctionnalité d’IA intégrée à un outil utilisé par le Prestataire et non mentionnée ci-dessus est interdite tant qu’elle n’a pas été expressément approuvée par écrit par le Client. Le fait qu’une fonctionnalité d’IA soit activée par défaut ne constitue pas une approbation du Client.

Sous-traitants et personnel

Les restrictions doivent s’appliquer à tous les sous-traitants, freelances et ressources externalisées.

Exemple :

Recours aux sous-traitants. Le Prestataire veille à ce que tous les sous-traitants, consultants et tiers participant à l’exécution du Contrat soient soumis aux mêmes restrictions et fournit, sur demande du Client, copie des dispositions contractuelles pertinentes.

Sécurité des données, confidentialité et données d’entraînement

C’est généralement là que surviennent les préjudices concrets.

La clause de confidentialité devrait :

• interdire explicitement l’introduction de données du client dans toute plateforme d’IA ou de machine learning tierce ;
• interdire l’utilisation des données, livrables ou travaux du client comme données d’entraînement ;
• exiger des garanties écrites des fournisseurs d’IA indiquant que les données du client ne seront utilisées ni pour l’entraînement, ni pour l’évaluation, ni pour l’amélioration des modèles.

Assurance et couverture cyber

Le contrat devrait exiger du prestataire qu’il confirme par écrit que son assurance couvre :

• l’utilisation non autorisée de l’IA ;
• les erreurs liées aux hallucinations ;
• les litiges de propriété intellectuelle liés aux données d’entraînement.

Le client devrait être désigné comme assuré additionnel et être informé de toute modification de couverture.

Conservation des preuves

Le prestataire devrait être tenu de conserver :

• les prompts ;
• les résultats générés ;
• les journaux API ;
• l’historique de navigation pertinent ;
• les licences logicielles ;
• les inventaires logiciels.

Ces informations devraient être conservées pendant toute la durée de la mission et pendant une période définie après son achèvement.

Droits d’audit

Le droit d’audit devrait inclure explicitement l’accès aux :

• outils utilisés ;
• licences logicielles ;
• historiques de navigation ;
• journaux API ;
• historiques de prompts et de résultats ;
• processus de travail.

Déclarations, garanties et obligations de divulgation

Le prestataire devrait garantir :

• à la signature ;
• et à chaque étape de livraison,

qu’aucun outil d’IA non autorisé n’a été utilisé.

Il devrait également être tenu de signaler immédiatement toute utilisation volontaire ou involontaire de l’IA, en précisant :

• la date ;
• l’étendue ;
• les livrables concernés ;
• les données exposées ;
• les mesures correctives prises.

Résiliation

L’utilisation non autorisée de l’IA devrait constituer un motif de résiliation pour faute.

Le contrat peut également :

• supprimer tout droit à correction (« cure period ») pour ce type de violation ;
• permettre au client d’exiger une nouvelle certification des anciens livrables ;
• imposer au prestataire le coût de toute réexécution humaine des travaux concernés.

Dommages-intérêts forfaitaires

Les préjudices liés à l’utilisation secrète de l’IA sont difficiles à quantifier.

Des clauses prévoyant des dommages-intérêts forfaitaires par incident ou par livrable permettent d’offrir un recours sans exiger la preuve détaillée du préjudice.

Indemnisation et propriété intellectuelle

Le prestataire devrait indemniser le client contre :

• les actions en contrefaçon liées aux données d’entraînement ;
• les erreurs introduites par l’IA ;
• les sanctions réglementaires résultant d’une utilisation illégale de l’IA.

Il devrait également garantir qu’aucun livrable ne contient de contenu généré par IA non autorisé.

Droit applicable et règlement des litiges

Les réglementations sur l’IA varient fortement selon les juridictions.

Le choix du droit applicable et du tribunal compétent devrait être effectué en tenant compte :

• des intérêts du client ;
• des exigences réglementaires applicables ;
• du secteur d’activité concerné.

Survie des clauses

Les clauses relatives à :

• la confidentialité ;
• l’indemnisation ;
• l’audit ;
• la conservation des documents ;
• la garantie de non-utilisation de l’IA ;
• la vérification rétrospective,

devraient continuer à produire leurs effets après la fin du contrat.

Conclusion

L’IA ne disparaîtra pas. De nombreux prestataires l’utiliseront, que le contrat l’autorise ou non, sauf si les conséquences d’une utilisation non autorisée sont clairement définies.

Les différentes clauses décrites ci-dessus — définitions, interdictions, exceptions, obligations de divulgation, droits d’audit, exigences d’assurance, conservation des preuves, indemnisation, dommages-intérêts forfaitaires, survie des clauses et motifs explicites de résiliation — forment un ensemble cohérent. Individuellement, chacune peut être contestée. Ensemble, elles créent un cadre dans lequel les incitations du prestataire sont alignées sur les attentes du client.

Trois actions concrètes pour les clients

1. Réviser les contrats fournisseurs existants lors de leur renouvellement et y intégrer des dispositions relatives à l’IA.
2. Mettre à jour les modèles d’appels d’offres et former les équipes achats à l’évaluation des déclarations d’usage de l’IA.
3. Consulter un conseiller juridique pour adapter les clauses aux juridictions concernées, notamment dans les secteurs réglementés ou les régions disposant déjà d’une législation active sur l’IA.

L’objectif n’est pas d’interdire toute utilisation de l’IA par les prestataires. Il est de s’assurer que toute utilisation soit déclarée, approuvée, encadrée, journalisée, assurée et imputable. Faites confiance, mais vérifiez — et mettez cette vérification par écrit.

6 - Cadre de compétences pour le métier « Gouvernement – Numérique et Données »

Résumé des postes (spécialiste de l’accessibilité)

Ce que fait un spécialiste de l’accessibilité

Un spécialiste de l’accessibilité apporte un soutien, des conseils et une expertise aux autres rôles de la profession « Gouvernement – Numérique et Données » sur la manière de créer des services numériques accessibles.

Vous utiliserez des connaissances en matière de directives d’accessibilité, fournirez une expertise technique et donnerez la voix des utilisateurs en situation de handicap afin de veiller à ce que les équipes produit conçoivent des services numériques utilisables par tous.

Niveaux du rôle de spécialiste de l’accessibilité

Il existe 4 niveaux de rôle de spécialiste de l’accessibilité, du niveau junior au niveau de responsable.

Les responsabilités et compétences typiques pour chaque niveau sont décrites dans les sections ci-dessous. Vous pouvez vous en servir pour identifier les compétences à développer pour progresser dans votre carrière, ou simplement pour en savoir plus sur chaque rôle au sein de la profession « Gouvernement – Numérique et Données ».

1. Spécialiste de l’accessibilité junior

Un spécialiste de l’accessibilité junior apprend sur le terrain en aidant aux tests d’accessibilité.

À ce niveau, vous devez :

• développer vos compétences en travaillant sous supervision afin de fournir des tests d’accessibilité
• comprendre et utiliser différents types de tests
• être conscient(e) mais ne pas être responsable des tests liés aux technologies d’assistance
• participer à la communauté interministérielle de l’accessibilité et y contribuer

2. Spécialiste de l’accessibilité

Un spécialiste de l’accessibilité peut aider des équipes à créer des services accessibles.

À ce niveau, vous devez :

• coacher et encadrer des collègues plus juniors
• soutenir la fourniture de supports de formation et de contenus d’apprentissage
• réaliser des audits d’accessibilité
• participer à la communauté interministérielle de l’accessibilité et y contribuer

3. Spécialiste de l’accessibilité senior

Un spécialiste de l’accessibilité senior travaille avec des personnes à différents niveaux de rôle afin d’intégrer l’accessibilité dans la production des équipes.

À ce niveau, vous devez :

• coacher et encadrer des collègues plus juniors
• contribuer à la stratégie d’accessibilité avec les domaines/équipes « business »
• créer et dispenser des formations sur l’accessibilité
• interagir avec des équipes de niveaux et de capacités différents
• potentiellement gérer ou diriger des individus ou des sous-équipes
• participer à la communauté interministérielle de l’accessibilité et y contribuer

4. Responsable de l’accessibilité

Un responsable de l’accessibilité est un praticien(ne) expert(e) capable de créer une vision ou une stratégie d’accessibilité pour une organisation.

À ce niveau, vous devez :

• définir et assurer les meilleures pratiques tout en influençant, en menant et en encadrant les autres
• influencer et développer la stratégie et les priorités organisationnelles, en travaillant avec des homologues à travers l’administration
• s’assurer que les conditions et l’environnement sont appropriés pour que les spécialistes de l’accessibilité puissent travailler efficacement
• développer les capacités du département en soutenant la mobilité interne des collaborateurs entre les rôles, en structurant les parcours de carrière et en recrutant des talents
• comprendre et assumer la gestion globale du risque lié à l’accessibilité (y compris la façon dont le risque d’accessibilité est communiqué et comment le risque de conformité juridique d’entreprise est géré)
• participer à la communauté interministérielle de l’accessibilité et y contribuer

Rôles partageant des compétences de spécialiste de l’accessibilité

7 - Gouvernance des design systems accessibles à l’ère de l’IA - Anna E. Cook

TL;DR :

L’IA et l’accessibilité sont généralement considérées comme un problème d’outillage. Ce n’est pas le cas. C’est un problème de gouvernance — celui qui détermine si votre design system peut supporter l’IA.

Les design systems gouvernaient autrefois ce qui est construit et comment c’est construit. Ils doivent désormais gouverner ce que l’IA est autorisée à générer à partir de ce qui a été construit. Cet article propose un cadre pour penser ce changement : six questions qui déterminent si votre système peut héberger de l’IA sans amplifier ses problèmes :

1. Quels sont mes biais de conception ?
2. Qu’est-ce qui est protégé dans ce système ?
3. À qui appartiennent les sorties de l’IA ?
4. Quelle est l’expérience par défaut ?
5. Quels signaux les utilisateurs envoient-ils déjà ?
6. L’IA peut‑elle réellement résoudre ce problème ?

Ce texte accompagne l’article « AI Doesn’t Fix Accessible Systems. It Depends on Them » . J’ai aussi créé un workbook basé sur ce cadre pour évaluer votre propre système.

Si vous dirigez ou travaillez sur un design system, vous avez probablement eu cette conversation dans les douze derniers mois :

Une équipe produit veut lancer une fonctionnalité IA, et quelqu’un demande qui est responsable de l’accessibilité des sorties de l’IA. La réponse est souvent insatisfaisante — non pas parce que l’équipe ne s’en préoccupe pas, mais parce que la question révèle quelque chose que le système n’a pas été construit pour gérer. Quand un composant statique est cassé, on sait qui corrige. Quand une variante générée par l’IA est cassée, la chaîne de responsabilité s’estompe. Le composant appartient techniquement au design system, le modèle à l’équipe IA. La sortie n’appartient à personne.

Ce n’est pas un problème d’outillage. C’est un problème de gouvernance. Et c’est celui qui détermine si votre système peut porter l’IA.

Si vous vous demandez pourquoi une question sur l’IA devient une question de gouvernance, c’est le sujet de l’article compagnon — « AI Doesn’t Fix Accessible Systems. It Depends on Them ». Cet autre texte explique pourquoi l’accessibilité est la fondation dont l’IA dépend.

Celui‑ci explique comment construire et évaluer cette fondation.

Ce qui change à l’ère de l’IA, ce ne sont pas les composants. Ils doivent toujours être accessibles, documentés et livrés. Ce qui change, c’est l’étendue des décisions que le système doit gouverner. Le système gouvernait ce qui est construit. Maintenant il doit gouverner ce que l’IA est autorisée à générer à partir de ce qui a été construit.

C’est un problème différent, qui requiert un nouvel ensemble de questions. Le reste de ce texte propose six dimensions de gouvernance qui déterminent si votre design system peut héberger l’IA sans amplifier ses problèmes. Pour chacune : ce que la question implique vraiment, à quoi ressemble une bonne pratique, une mauvaise pratique, et les actions opérationnelles pour combler l’écart.

Questions à résoudre

La gouvernance, c’est comment nous protégeons l’utilisabilité et l’accès à grande échelle. Il ne s’agit pas de bureaucratie pour la forme, mais de règles délibérées qui empêchent la dérive.

Ces dernières années, j’ai beaucoup réfléchi à ces problèmes. Ce sont des questions difficiles, mais essentielles pour construire des systems accessibles et pratiques à l’ère de l’IA.

Je partage ici les six questions que j’utilise :

Question 1 : Quels sont nos biais de conception ?

Avant de définir quoi que ce soit, commencez par un examen de soi. La gouvernance requiert des règles intentionnelles, mais définir des règles exige d’examiner les hypothèses qui risquent d’y être intégrées.

Souvent, quand on qualifie quelque chose d’« intuitif », on veut dire que c’était intuitif pour des personnes comme nous. C’est l’hypothèse à interroger avant de concevoir.

Démanteler nos biais est encore plus important aujourd’hui. Quand l’IA fait partie du produit, les biais se propagent plus vite. Le modèle hérite des hypothèses non examinées et les reproduit sur chaque sortie.

Beaucoup de nos conceptions reposent sur l’idée de l’utilisateur « moyen ». Mais l’utilisateur moyen est une fiction. L’US Air Force l’a découvert en concevant des cockpits autour des mensurations du « pilote moyen » et a constaté que ces cockpits ne convenaient à personne.

Le même principe s’applique aux interfaces.

J’ai vu des designers se concentrer sur l’utilisateur « moyen » et le « happy path ». Mais connaissez‑vous vraiment quelqu’un qui corresponde parfaitement à vos personas ?

Même les designers bien intentionnés intègrent des biais en essayant de ne pas le faire. Par exemple, beaucoup d’entre nous supposent ce qui serait utile aux utilisateurs de lecteurs d’écran. On écrit alors des labels très verbeux, souvent redondants, parce qu’on ne comprend pas comment ces utilisateurs naviguent dans nos produits.

On ne peut pas supposer les besoins d’autrui quand on ne les partage pas, et même quand on les partage, ils peuvent se manifester différemment.

Le concept d’affordance reflète aussi un biais. Les affordances sont relationnelles, pas universelles. On dit qu’une tasse « permet » de boire, mais cela n’est vrai que pour certains corps, dans certains contextes. Qu’en est‑il d’une personne avec une prise faible ? D’un enfant ? D’une personne avec des sensibilités sensorielles ? Pour eux, la tasse n’offre pas forcément la possibilité de boire.

Que faire pour réduire les biais dans nos systèmes ?

Concevoir pour la variabilité des affordances. Anticiper plusieurs manières valides d’utiliser le même objet : ajouter une paille, une anse, un bouchon, ou repenser la tasse dès l’origine.

Ne pas supposer que l’utilisateur doit s’adapter à l’objet. Permettre à l’objet ou au système de s’adapter à l’utilisateur.

Les systèmes numériques sont identiques. Une zone de texte permet de taper, mais taper n’est pas la voie la plus facile pour tout le monde. On prend donc en charge la saisie vocale, l’autocomplétion, des labels clairs dans le code, des messages d’erreur utiles. Même objectif, plusieurs chemins valides.

Un moyen direct : suivre les WCAG et intégrer des personnes en situation de handicap ou neurodivergentes dans le processus — comme membres permanents de l’équipe ou collaborateurs rémunérés.

Les équipes système et produit voient un retour sur investissement immédiat en pratiquant le design inclusif et le co‑design. Et les biais intégrés au système diminuent.

Quand l’IA fait partie de la construction, les invariants protègent le système contre l’érosion probabiliste. Un modèle peut proposer mille variations de bouton. L’invariant garantit que chaque variation reste opérable, étiquetée et accessible. Sans ce plancher, le modèle ne personnalise pas — il dérive.

La conformité aux WCAG est essentielle, mais elle ne tient que si la structure sous‑jacente est protégée. On ne peut pas réussir un audit sur un système dont les fondations sont négociables. Quand la structure est stable, les systèmes peuvent s’adapter en sécurité. Variabilité sans contraintes = chaos. Variabilité avec garde‑fous = design adaptatif.

Question 2 : Qu’est‑ce qui est protégé dans notre système ?

Avant d’introduire de la variabilité — personnalisation, génération par IA, toute adaptation — définissez nos invariants. Ce sont les éléments qui ne peuvent pas changer, quelle que soit la flexibilité de la surface. Ce sont des garanties pour les personnes qui utilisent notre plateforme.

Imaginez une couche de personnalisation qui conclut « cet utilisateur semble préférer le tactile, l’opérabilité clavier n’est pas nécessaire ». Ce n’est pas de l’adaptation : c’est un invariant qui est écrasé silencieusement par une inférence. L’utilisateur vient de perdre une garantie dont il ignorait l’existence, sans moyen de la récupérer.

Ce sont les éléments dont dépendent les technologies d’assistance pour fonctionner. Ce sont aussi ce dont l’IA a besoin pour interpréter correctement la structure. Quand les invariants tiennent, le système peut se « plier » par-dessus sans danger — pour les utilisateurs voyants, les utilisateurs de lecteurs d’écran, et les modèles qui apprennent des schémas. Quand ils ne tiennent pas, aucune couche de personnalisation ne peut restaurer ce qui a été perdu dans les fondations.

Quelques éléments ne sont pas négociables, par exemple :

• Les paramètres par défaut à plus faible barrière (voir section suivante)
• Hiérarchie sémantique
• Opérabilité au clavier
• Étiquettes programmatiques (et ARIA seulement quand la sémantique HTML est insuffisante)
• Ordre du focus et de lecture

Certains éléments peuvent varier :

• Densité de mise en page (ex. : compacte, confortable)
• Thèmes de couleur (ex. : clair, sombre, contraste élevé)
• Ton du contenu (ex. : bref, détaillé)
• Visuels (ex. : afficher/masquer les visuels, mode niveaux de gris)

Quand l’IA fait partie du produit, ce sont les invariants qui protègent le système de l’érosion probabiliste. Un modèle peut proposer mille variations de bouton : l’invariant garantit que chaque variation reste opérable, étiquetée et atteignable. Sans ce plancher, le modèle ne personnalise pas — il dérive.

La conformité aux WCAG est essentielle, mais elle ne tient que si la structure sous‑jacente est protégée. On ne peut pas réussir un audit sur un système dont les fondations sont négociables. Quand la structure est stable, les systèmes peuvent s’adapter en sécurité. Variabilité sans contraintes = chaos. Variabilité avec garde‑fous = design adaptatif.

Question 3 : À qui appartiennent les sorties de l’IA ?

Une fois les invariants définis, la question suivante est qui est responsable de les faire respecter — pas en théorie, mais le jour où un modèle livre une variante cassée un vendredi à 16 h.

Quand un composant statique tombe en panne, la chaîne de responsabilité est claire : un designer ou ingénieur possède le composant, une équipe design system possède le pattern, et le processus de release attrape la régression. Quand une variante générée par l’IA échoue, la chaîne s’effiloche. Le composant appartient techniquement à l’équipe design system. Le modèle appartient techniquement à l’équipe IA. La sortie n’appartient techniquement à personne.

Cette ambiguïté est la défaillance.

La propriété ne peut pas être héritée de surfaces adjacentes ; elle doit être assignée. Sans propriétaire, la sortie de l’IA opère hors gouvernance — même quand le reste du système est bien gouverné. Le modèle devient une quatrième équipe qui publie dans votre produit sans manager.

Imaginez une équipe design system qui a passé deux ans à rendre ses composants conformes à WCAG 2.2 AA, avec documentation et cadres pour assurer une bonne utilisation par les consommateurs du système. Puis, une fonctionnalité IA génère un nouveau pattern de mise en page, le publie, et casse silencieusement les labels programmatiques sur tout le tableau de bord. L’équipe produit publie, et six mois plus tard, un auditeur découvre les bugs d’accessibilité.

L’information finit peut‑être par revenir à l’équipe design system. Celle‑ci ouvre un ticket. L’équipe IA répond que le modèle produit des patterns dans les paramètres fournis. L’équipe design system révise les paramètres. Le modèle produit d’autres patterns qui respectent ces paramètres mais introduisent une régression d’accessibilité différente. Répéter. Des mois passent. Personne n’a tort. Rien ne s’améliore.

Cette boucle ne se brise que lorsque quelqu’un a une autorité explicite sur les sorties IA — y compris l’autorité de les bloquer avant livraison.

Ce que la propriété des sorties IA exige réellement :

• Un propriétaire nommé (ou des propriétaires), par rôle, pour les artefacts générés par l’IA. Pas le modèle. Une personne.
• Un périmètre d’autorité clair : que peut bloquer le propriétaire, que peut‑il réviser, que doit‑il escalader ?
• Une relation définie entre la propriété des sorties IA et les équipes existantes (design system, accessibilité, IA/ML). Qui consulte qui, et sur quoi ?
• Un chemin pour que les sorties IA entrent dans les mêmes processus de revue et de correction que les artefacts humains, y compris la capacité d’empêcher la release quand l’accessibilité échoue.
• Un enregistrement documenté de ce que l’IA a généré, quand, et des changements effectués en réponse aux problèmes. La même trace d’audit qu’on attendrait pour un travail humain.

Quand on demande « qui possède la sortie de l’IA », on demande en réalité si quelqu’un a le pouvoir de dire non. Si personne ne l’a, le modèle a plus de droits décisionnels que les personnes responsables du produit.

Question 4 : Quelle est l’expérience par défaut ?

Une fois nos invariants clairs, définissons l’expérience par défaut. Un défaut est une base — l’expérience avec le plus faible niveau de barrières possible, accessible à tous sans configuration ni personnalisation.

Chaque système a des paramètres par défaut. La question est de savoir si le chemin accessible est le défaut, ou s’il s’agit d’un réglage que l’utilisateur doit connaître pour l’activer. Le défaut est ce que reçoit tout utilisateur avant toute personnalisation, inférence IA ou demande d’accommodement — et c’est l’expérience sur laquelle on doit pouvoir compter sans médiation par l’IA.

La décision de GitHub d’identifier les liens par un soulignement par défaut en est un exemple simple : cela garantit que les liens sont distincts pour les utilisateurs qui s’appuient sur des indices visuels au‑delà de la couleur. Puis ils ont rendu ce choix personnalisable. Mais l’état à plus faible barrière vient d’abord.

Comparez cela au défaut de la plupart des CAPTCHA : le chemin « le plus simple » est visuel. L’alternative clavier ou audio est plus difficile, plus lente, et souvent cassée. Le chemin accessible existe, mais ce n’est pas le défaut. C’est un système où l’accessibilité est une option, pas une fondation.

Même si l’IA personnalise notre système, il doit toujours exister une base prévisible : un état de référence testable, une expérience partagée qui fonctionne sans médiation IA. L’accessibilité garantit que le système fonctionne avant d’ajouter l’IA.

Si l’IA devine qu’un utilisateur « préfère une interface minimaliste » et supprime les soulignements de lien, elle réintroduit une barrière. Le défaut doit pouvoir annuler ce que l’IA devine.

Que se passe‑t‑il si l’IA suppose qu’une personne qui préfère une UI minimale n’a pas besoin d’un contraste élevé ? Ou si elle modifie sans consentement l’espacement et la mise en page ? Que fait l’utilisateur quand le modèle devine ses besoins, change sans demander et masque les réglages ?

Même quand l’IA agit ainsi, le défaut et les réglages contrôlables par l’utilisateur offrent un chemin de retour. Le modèle peut deviner. Les utilisateurs doivent pouvoir inverser. Le système doit soutenir les deux.

Les utilisateurs doivent pouvoir accéder à notre plateforme sans médiation IA, sans divulgation de données personnelles, et sans ajustement probabiliste. L’accessibilité garantit que le système fonctionne que l’IA soit présente ou non.

Question 5 : Que signalent déjà les utilisateurs ?

Une fois la base stable, les premiers signaux à interpréter sont ceux que les utilisateurs nous ont déjà donnés — explicitement, au niveau de l’OS ou du navigateur, sans qu’on ait à demander.

Imaginez une application de productivité alimentée par l’IA qui détecte qu’un utilisateur a bougé sa souris doucement pendant deux minutes et décide que son réglage prefers‑reduced‑motion était « probablement accidentel ». Elle réactive les animations en parallaxe que l’utilisateur avait désactivées au niveau de l’OS — animations qui provoquent chez lui des nausées vestibulaires. Le modèle n’a pas demandé. Il a inféré. L’utilisateur doit désactiver les animations encore et encore à chaque session.

L’inférence IA est conçue pour trouver des patterns dans le comportement. Il est tentant de laisser le modèle « apprendre » qu’un utilisateur « n’a pas vraiment besoin » de reduced motion parce qu’il ne la désactive pas manuellement pendant une session. Mais le réglage au niveau OS est le commutateur. L’utilisateur a appuyé sur le bouton. Le modèle n’a pas le droit de le remettre en question.

Ce sont des préférences déclarées par l’utilisateur. Elles sont l’indication la plus directe de ce dont quelqu’un a besoin — sans entretiens ni inférence. Il suffit de respecter ces signaux.

Interrogez‑vous : notre plateforme respecte‑t‑elle des signaux comme :

• prefers‑reduced‑motion
• modes de couleur
• réglages haut contraste
• mise à l’échelle des polices
• préférences de langue
• préférences de cookies et de partage des données

Rappel : l’IA ne doit jamais outrepasser un choix explicite de l’utilisateur. Elle ne doit jamais contredire des réglages d’accessibilité au niveau du système.

La différence entre adaptation et supposition, c’est le consentement. Une personnalisation basée sur des signaux donnés par l’utilisateur est du design adaptatif. Une personnalisation basée sur une inférence non autorisée par l’utilisateur n’est qu’une imposition bien présentée.

Question 6 : L’IA peut‑elle réellement résoudre ce problème ?

Après avoir examiné nos biais, protégé nos invariants, défini un défaut stable et promis de respecter les signaux réels — posez la question plus difficile :

L’IA résout‑elle réellement un problème ici ? Ou concevons‑nous un problème pour justifier la solution que nous avons déjà construite ?

Évitons‑nous le travail structurel lent ? La gouvernance n’est pas spectaculaire. Le refactoring n’est pas toujours excitant. Nettoyer la sémantique ne fait pas la une. Pourtant, c’est le travail. L’IA ne le remplace pas. Elle apprend à partir de la structure qu’on lui donne. Elle ne corrige pas cette structure.

Il y a aussi une question de consentement. Si l’IA est intégrée aux workflows de base, les utilisateurs peuvent‑ils vraiment se désengager ? Ou le fait d’opter‑out dégrade‑t‑il l’expérience au point de supprimer le choix réel ? Certains utilisateurs veulent le contrôle total. D’autres aucun IA. L’accessibilité est fondamentalement une question d’agence — et l’imposition, même bien conçue, n’en est pas.

Nous devons aussi reconnaître que l’IA ajoute des coûts : financiers, opérationnels et environnementaux. Mal utilisée, elle introduit des risques — biais, sécurité, fiabilité. Elle a des limites documentées dans son état actuel. La pression pour l’intégrer partout ne doit pas primer sur la question de sa pertinence.

Les décisions technologiques ne sont pas neutres. Elles déterminent qui bénéficie, qui porte les risques et qui est exclu. Je ne dis pas d’utiliser ou non l’IA. Mais je vous encourage à choisir délibérément.

Décidez de manière responsable si l’IA a sa place dans le système — et si oui, comment l’intégrer. Si vous l’utilisez, faites‑le avec des contraintes claires, une structure protégée et une gouvernance explicite.

L’IA amplifie la structure qu’on lui donne. Y compris nos échecs.

8 - Idées reçues courantes sur les tests d'accessibilité - Ela Gorla

Publié le mercredi 7 janvier 2026 par Ela Gorla dans Design and development , Testing

Tags : Assistive Technology

Les tests d’accessibilité sont souvent mal compris. Les équipes surestiment ce que les outils peuvent faire, sous-estiment leur propre rôle, ou supposent que les tests ne se font qu’une seule fois, à la fin du processus de développement.

Dans cet article, nous abordons quelques-unes des idées reçues les plus fréquentes concernant les tests d’accessibilité.

Avec tant d’outils et de méthodologies de test disponibles, il n’est pas facile de savoir quelle est la meilleure approche pour tester l’accessibilité de vos produits. Nous examinons certaines de ces idées reçues et comment y remédier.

Si vous les avez manqués, vous pouvez lire les autres articles de notre série « Common misconceptions » :

• Common misconceptions about screen readers
• Common misconceptions about disability
• Common misconceptions about WCAG
• Common misconceptions about implementing accessibility

Idée reçue 1 : je peux me fier aux outils de test automatisés

Vous avez peut‑être rencontré des outils automatisés qui promettent d’identifier tous les problèmes d’accessibilité. Il est tentant de s’y fier uniquement, mais aucun outil automatisé ne peut tester tous les aspects de l’accessibilité. Au mieux, ils couvrent 20 à 40 % des exigences de la Web Content Accessibility Guidelines (WCAG).

L’accessibilité, c’est plus que du code accessible

Les outils automatisés se concentrent surtout sur le code des sites et applications. L’accessibilité englobe aussi un bon design visuel, des médias inclusifs, une rédaction soignée, un langage inclusif, etc. Beaucoup de ces aspects échappent aux outils automatisés.

Le jugement humain reste nécessaire

De nombreux tests exigent un jugement humain : un outil peut‑il écrire une description contextuelle pertinente ? Peut‑il juger si un message d’erreur est clair et propose des solutions utiles ? Les outils aident à repérer rapidement des problèmes courants, mais ils doivent être utilisés avec des tests manuels et des tests d’utilisabilité impliquant des personnes en situation de handicap.

Idée reçue 2 : les tests doivent se faire en fin de développement

Dans certaines organisations, les tests d’accessibilité sont laissés au QA et effectués en fin de cycle. Les problèmes détectés si tard sont coûteux et difficiles à corriger.

Tout le monde travaillant sur un produit numérique est responsable de son accessibilité : designers, producteurs de contenu, développeurs, QA. Chacun doit vérifier l’accessibilité à chaque étape : les designs doivent être contrôlés avant d’arriver en dev, les contenus avant publication, etc.

Tester tôt et à chaque étape réduit les problèmes détectés en QA.

Idée reçue 3 : seuls les spécialistes accessibilité peuvent tester

Pour les débutants, les tests peuvent sembler complexes, menant à l’idée que seuls les spécialistes peuvent les réaliser. Ce n’est pas vrai.

Chacun dans les équipes digitales doit pouvoir effectuer des tests de base pertinents à son rôle. Bien sûr, un spécialiste est utile pour des composants complexes ou innovants, mais la plupart des tests quotidiens peuvent être faits en interne si les équipes disposent de la formation et des outils nécessaires.

Idée reçue 4 : je dois tester sur tous les OS, navigateurs et technologies d’assistance

Les produits numériques sont accessibles via de nombreux OS, navigateurs, AT et dispositifs d’entrée, ce qui pousse certains à vouloir tester toutes les combinaisons — coûteux et irréaliste.

Si un produit respecte les standards (WCAG, Inclusive Design Principles), il fonctionnera bien sur la plupart des configurations. Concentrez‑vous sur les dispositifs, navigateurs et AT les plus courants ; testez plus largement seulement pour des composants non standards. Le WebAIM Screen Reader User Survey aide à prioriser les technologies à tester.

Idée reçue 5 : je peux simplement demander des retours à des personnes en situation de handicap

Observer des personnes utiliser un produit apporte des enseignements précieux. L’Agile Usability Testing permet d’obtenir des retours de personnes ayant divers handicaps. Il peut aussi y avoir des collègues à solliciter pour un feedback rapide.

Cependant, s’appuyer uniquement sur ces retours n’est pas suffisant.

Les personnes sont uniques

Chaque personne a des besoins et préférences différents ; des retours variés voire contradictoires sont normaux. Sans expertise, on peut confondre préférence personnelle et problème d’accessibilité (par ex. un nouvel utilisateur d’un lecteur d’écran peut avoir des difficultés qui ne reflètent pas un bug).

Certains critères risquent de ne pas être couverts

Avec un panel limité, vous ne testerez pas toutes les exigences. Par exemple, le success criterion 1.4.10 Reflow de WCAG exige qu’un contenu puisse être présenté sans perte d’information ni besoin de défilement bidimensionnel à certaines dimensions : sans un participant qui utilise précisément ces paramètres, vous ne pourrez pas tester ce cas.

La recherche utilisateur est très utile mais doit être combinée avec des tests automatisés et des évaluations manuelles.

Prochaines étapes

Consultez Assessments pour savoir comment nous pouvons aider votre organisation à valider l’accessibilité de vos produits, ou découvrez nos services d’ Agile Usability Testing et de User Research Mentoring .

9 - Il est impossible de simuler l’expérience du handicap dans toute sa complexité, ses nuances et sa richesse

Il est impossible de simuler l’expérience du handicap dans toute sa complexité, ses nuances et sa richesse, affirme Robyn Hunt.

Il y a de nombreuses années, avant de savoir ce que je sais aujourd’hui, j’ai organisé seule un exercice de simulation du handicap sur mon lieu de travail. Cela s’est très mal passé. J’ai regardé avec une inquiétude croissante mes adorables collègues essayer d’utiliser leurs ordinateurs ou de se déplacer dans leurs bureaux avec des lunettes conçues pour simuler diverses pathologies visuelles graves ou la cécité.

J’ai rapidement compris que je faisais du tort en créant une situation artificielle. En plaçant les participants dans une situation rare dans la vie réelle, je renforçais leurs perceptions erronées des effets de la cécité et de la déficience visuelle. Selon la manière dont ils interprétaient l’expérience, ils pouvaient croire que le sentiment d’impuissance totale, de perte de pouvoir, de confusion, d’embarras, de vulnérabilité et d’incapacité qu’ils ressentaient dans cette situation inhabituelle constituait le quotidien de toutes les personnes handicapées. C’est à la fois contre-productif et faux. Ces conséquences involontaires et ces réactions émotionnelles peuvent causer des dommages durables, même lorsqu’un débriefing approfondi est prévu.

Même une personne qui perdrait soudainement la vue — sans parler de quelqu’un confronté à une dégradation progressive — ne serait pas censée accomplir seule ses tâches quotidiennes sans soutien. Elle bénéficierait d’un accompagnement en orientation et mobilité afin d’apprendre à se déplacer en sécurité dans son domicile et dans son environnement. Elle pourrait apprendre à utiliser des technologies accessibles pour intégrer ou réintégrer le marché du travail, voire apprendre le braille. Elle pourrait alors participer à la vie sociale et professionnelle comme elle le souhaite.

J’ai rapidement compris que je faisais du tort en créant une situation artificielle, qui renforçait les perceptions erronées des effets de la cécité et de la déficience visuelle.

Ce que je faisais me semblait malhonnête et exploiteur. Je ne recommencerai jamais. Pourtant, ces simulations continuent d’être pratiquées malgré l’opposition des personnes handicapées. J’ai été déçue de constater que Blind Low Vision New Zealand continue encore à les organiser.

Ce que les exercices de simulation du handicap ne montrent pas — et ne pourront jamais montrer —, c’est le contexte social du handicap, qui influence profondément notre manière de nous déplacer dans le monde. Ils ne peuvent pas non plus reproduire la dépression, parfois la douleur chronique ou l’épuisement, ni le validisme intériorisé qui peuvent résulter du fait de vivre durablement avec une déficience ou un handicap. Ils ignorent également l’ingéniosité, les capacités de résolution de problèmes et l’humour noir que les personnes handicapées développent par nécessité au sein de leurs communautés.

Les exercices de simulation du handicap sont largement considérés comme mal conçus et contraires aux bonnes pratiques, pour diverses raisons, comme le montrent plusieurs études.

Ce que les exercices de simulation du handicap ne montrent pas — et ne peuvent pas montrer —, c’est le contexte social du handicap qui influence notre manière d’évoluer dans le monde.

Des recherches menées aux États-Unis confirment les effets négatifs et l’absence de bénéfices significatifs de ces formations fondées sur la simulation. La seule étude néo-zélandaise que j’ai trouvée, réalisée à Dunedin, a révélé peu de preuves d’un changement d’attitude à la suite d’exercices de simulation de déficience visuelle. Elle concluait qu’un cadre de compétence culturelle pouvait aider à comprendre comment utiliser ces simulations dans un contexte éducatif. Tout dépend parfois de ceux qui conduisent la recherche.

Il est impossible de simuler l’expérience du handicap et de la déficience dans toute sa complexité, ses nuances et sa richesse. Les simulations sont issues d’une culture marquée par des rapports de pouvoir inégaux et par l’idée que les problèmes individuels sont causés par des déficits individuels qu’il faudrait corriger. Elles ne favorisent pas nécessairement l’empathie ni l’imagination. Ces exercices sont artificiels, car il est impossible de reproduire une expérience humaine aussi profonde de manière aussi grossière. Réduire le handicap à une simple dimension physique contribue peu à un véritable changement.

La participation de responsables politiques ou d’autres personnalités publiques à ce type de simulation relève davantage du gadget, du paternalisme et de la recherche de publicité que d’un réel engagement envers la cause. Ces exercices produisent peu ou pas de changements concrets, parce que les transformations durables ne résultent généralement pas de solutions rapides. Chercher à résoudre des problèmes environnementaux collectifs par des simulations individuelles ne conduit pas à des changements durables. En revanche, associer des experts handicapés sur un pied d’égalité à la planification, à la conception et à la mise en œuvre des projets peut réellement faire la différence.

Ces exercices sont artificiels parce qu’il est impossible de reproduire l’expérience profondément humaine des personnes handicapées d’une manière aussi simpliste. Réduire le handicap à sa seule dimension physique ne produit guère de changement réel.

En participant à ces exercices, comme beaucoup d’entre nous l’ont fait, nous contribuons malgré nous à notre propre dépossession et à l’appropriation de notre parole.

Aucun autre groupe social n’accepterait de telles pratiques. Certes, j’ai vu une vidéo montrant un homme courageux subissant une simulation électrique des douleurs de l’accouchement sous les rires des observatrices. Mais personne n’oserait sérieusement tenter de simuler aujourd’hui l’expérience vécue par une autre race ou une autre culture. Ce serait tout aussi insultant, superficiel et dégradant que ce que vivent les personnes handicapées face à ces simulations. Aux États-Unis, certaines personnes ont comparé les simulations du handicap au « blackface ». Nous ne devrions pas être le seul groupe dont on attend qu’il tolère cela. Personne ne devrait avoir à vivre physiquement une expérience pour y croire. Il faut plutôt nous écouter et travailler avec nous.

Le handicap n’est pas non plus un jeu. Participer à une simulation très limitée n’offre qu’une expérience temporaire à une personne valide, expérience qui sera rapidement oubliée.

Faire en sorte que le monde fonctionne pour tout le monde devrait constituer un défi à l’ingéniosité et à la créativité humaines : une entreprise coopérative et innovante menée entre partenaires égaux. Écouter les personnes handicapées comme des égales implique d’accepter que nous remettions en question certaines normes établies, que nous apportions des expériences différentes et que nous sachions ce qui doit changer.

Faire en sorte que le monde fonctionne pour tout le monde devrait être un défi à l’ingéniosité et à la créativité humaines, une entreprise coopérative et innovante menée entre partenaires égaux.

L’intention de montrer aux personnes valides les obstacles auxquels nous faisons face et de susciter l’empathie est louable, mais la méthode est mauvaise. Trouver des ressources pédagogiques locales de qualité qui dépassent la simple simulation ou la « sensibilisation » pour conduire à l’action et au changement n’est pas facile. Nous pouvons privilégier les ressources conçues, dirigées et contrôlées par des personnes handicapées et leurs organisations. Les personnes qui souhaitent réellement apprendre peuvent lire, regarder et écouter une diversité de voix handicapées, au-delà des récits inspirants ou centrés sur soi. Le handicap est merveilleusement complexe ; il n’existe donc aucune ressource simple et rapide qui permettrait d’apprendre tout ce qu’il faut savoir en un après-midi.

Si les personnes valides souhaitent réellement améliorer la vie des personnes handicapées dans un monde qui crée lui-même le handicap, elles devraient rechercher ces voix, les écouter et agir à partir de ce qu’elles apprennent de l’expérience des personnes handicapées, plutôt que d’essayer de se l’approprier et de la refléter à travers un regard valide.

10 - L’accessibilité, l’IA et le combat pour rester inclusif

L’article explique que l’accessibilité devient une exigence centrale du numérique (lois, normes et marchés publics) plutôt qu’un simple “plus”. Il souligne que l’IA doit elle-même être rendue accessible et responsable, et que les outils grand public ne remplacent pas toujours les technologies d’assistance spécialisées. La recherche évolue aussi : on ne cherche plus seulement la conformité technique, mais l’utilisabilité, l’inclusion réelle et la participation des personnes handicapées. Enfin, l’accessibilité est présentée comme un enjeu économique et politique, et l’auteur conclut que les décisions actuelles en matière de réglementation et de financement détermineront l’inclusion future.

Au cours du mois écoulé, un certain nombre d’évolutions partout dans le monde ont renforcé un message qui se fait entendre de plus en plus fort depuis quelques années : l’accessibilité n’est plus une préoccupation de niche. Elle devient une exigence centrale de la transformation numérique, de l’intelligence artificielle, de l’éducation, des services publics et des marchés technologiques mondiaux.

Pour celles et ceux d’entre nous qui travaillent dans le domaine des technologies d’assistance et de l’accessibilité depuis des décennies, ce changement est à la fois encourageant et stimulant. Encouragent, parce que les principes défendus par les militants pour le handicap finissent enfin par trouver leur place dans la législation, les normes et la technologie grand public. Stimultant, parce que le rythme du changement s’accélère et qu’il existe un risque réel que l’accessibilité soit à nouveau laissée de côté si elle n’est pas intégrée, de façon délibérée, à la génération suivante de systèmes numériques.

Les évolutions du mois dernier donnent un aperçu utile de la direction prise.

La réglementation passe de l’intention à l’application

Pendant de nombreuses années, les lois sur l’accessibilité ont surtout existé comme une déclaration d’intention. Les organisations savaient qu’elles devaient être accessibles, mais l’application était souvent inégale et la mise en œuvre pratique variait fortement.

Cela commence à changer.

Dans toute l’Europe, les organisations continuent de se préparer à l’impact complet de l’European Accessibility Act (EAA). La loi concerne un large éventail de produits et services, notamment les ordinateurs, les smartphones, les services bancaires, les systèmes de transport, les plateformes de commerce électronique et les communications numériques. Pour de nombreuses organisations, l’accessibilité n’est plus seulement une question de responsabilité sociale de l’entreprise. Elle devient une exigence d’accès au marché.

En parallèle à l’EAA, les travaux se poursuivent sur la révision de la norme EN 301 549, la norme d’accessibilité utilisée dans toute l’Europe pour les marchés publics et les exigences d’accessibilité numérique. La norme mise à jour devrait s’aligner davantage sur les WCAG 2.2 et renforcer les attentes en matière d’accessibilité pour un ensemble de technologies numériques.

Pendant ce temps, aux États-Unis, les prestataires de soins de santé, les organismes publics et les organisations recevant des financements fédéraux se préparent à des exigences de conformité à l’accessibilité de plus en plus explicites, touchant les sites web, les applications mobiles et les services numériques.

Pris ensemble, ces éléments indiquent un avenir où l’accessibilité est traitée de la même façon que la confidentialité, la cybersécurité ou la sécurité : une exigence fondamentale plutôt qu’un simple complément optionnel.

L’IA devient un enjeu d’accessibilité

L’intelligence artificielle a dominé les discussions technologiques tout au long de 2025 et continue de le faire en 2026. Ce qui change, en revanche, c’est la reconnaissance croissante que l’IA elle-même est désormais un problème d’accessibilité.

Au début du “boom” de l’IA, les discussions portaient souvent sur la façon dont l’IA pourrait aider les personnes handicapées. Aujourd’hui, on réalise de plus en plus que les systèmes d’IA eux-mêmes doivent être accessibles, inclusifs et responsables.

Ce changement se reflète dans des initiatives émergentes comme Disability Inclusion and Accessible AI (DIAAI) et dans des études menées par des organisations telles que la Funka Foundation, qui explorent à la fois les opportunités et les risques associés aux solutions d’accessibilité alimentées par l’IA.

Des questions qui étaient autrefois considérées comme des sujets spécialisés deviennent rapidement courantes :

• Les personnes handicapées peuvent-elles utiliser efficacement des systèmes d’IA ?
• Les ensembles de données d’entraînement sont-ils représentatifs des utilisateurs handicapés ?
• Comment s’assurer que le contenu généré par l’IA est accessible ?
• Qui est responsable lorsque des systèmes d’IA créent des barrières à l’accessibilité ?
• Comment prévenir les biais et la discrimination envers les personnes handicapées ?

Ces questions ne sont pas théoriques. Elles deviennent de plus en plus pertinentes pour les achats publics, la réglementation et le développement de produits.

La communauté des personnes handicapées a plaidé pendant des décennies pour que l’accessibilité soit intégrée dès le départ plutôt que “ajoutée” après coup. L’émergence de l’IA offre l’occasion de tirer cette leçon avant que des systèmes inaccessibles ne soient profondément ancrés.

Les technologies d’assistance spécialisées restent essentielles

Parmi les histoires les plus marquantes du mois, il y en a une qui vient d’Angleterre : des changements proposés au financement de l’Allocation pour étudiants handicapés (Disabled Students Allowance, DSA) ont suscité de fortes inquiétudes.

Les propositions viseraient à réduire le soutien pour certains logiciels spécialisés de technologies d’assistance, en s’appuyant en partie sur des hypothèses selon lesquelles des outils d’IA grand public et des fonctionnalités d’accessibilité intégrées pourraient remplacer les produits de technologies d’assistance traditionnels.

À première vue, cela peut sembler raisonnable. Après tout, les grandes entreprises technologiques ont fait des progrès importants en reconnaissance vocale, synthèse vocale, prise de notes, synthèse/summarisation et d’autres fonctions liées à l’accessibilité.

Cependant, la réaction des étudiants handicapés, des fournisseurs de technologies d’assistance et des organisations de défense du handicap met en évidence un point crucial : les fonctionnalités d’accessibilité “grand public” ne remplacent pas toujours adéquatement des solutions spécialisées.

Les technologies d’assistance ne sont que rarement de simples questions de fonctionnalité. Il s’agit aussi de fiabilité, de personnalisation, d’entraînement/formation, de support et d’adéquation aux besoins individuels.

Un assistant d’IA “générique” peut être capable d’accomplir certaines tâches que des logiciels spécialisés faisaient autrefois, mais cela ne signifie pas automatiquement qu’il offre le même niveau d’accès ou d’autonomie.

Ce débat reflète un défi plus large auquel sont confrontés, partout dans le monde, les gouvernements, les établissements d’enseignement et les financeurs. À mesure que les fonctionnalités d’accessibilité s’intègrent de plus en plus aux produits grand public, comment déterminer ce qui nécessite encore un accompagnement spécialisé ?

La réponse n’est probablement pas un choix simple “soit l’un soit l’autre”. Il faut plutôt des approches fondées sur des preuves, centrées sur les résultats plutôt que sur des hypothèses.

La recherche s’intéresse désormais au-delà de la conformité

Autre tendance notable : l’évolution de l’orientation de la recherche sur l’accessibilité.

Historiquement, une grande partie de la recherche sur l’accessibilité se concentrait sur la conformité technique. Les chercheurs étudiaient si les sites web répondaient aux critères des WCAG ou si les logiciels passaient des tests d’accessibilité.

Ces questions restent importantes, mais des recherches récentes indiquent que le champ s’élargit.

Une revue systématique récente portant sur de grands modèles de langage et l’accessibilité du web a montré qu’une grande partie des travaux actuels se concentre encore sur des tâches d’accessibilité liées au texte. Toutefois, la revue a aussi identifié des lacunes importantes concernant l’accessibilité cognitive et la participation significative des personnes handicapées aux activités d’évaluation.

Cela reflète un changement plus large dans la recherche en accessibilité. De plus en plus, les chercheurs ne demandent pas seulement si les systèmes sont techniquement accessibles, mais aussi s’ils sont réellement utilisables, utiles et porteurs d’autonomisation.

La participation, l’expérience vécue et le co-design deviennent des thèmes centraux.

C’est une évolution bienvenue, car la conformité seule ne garantit pas l’inclusion.

L’accessibilité devient un enjeu économique

Peut-être la tendance de fond la plus importante est que l’accessibilité est de plus en plus envisagée à travers un prisme économique.

Le marché mondial des technologies d’assistance continue de croître, tandis que la demande en spécialistes de l’accessibilité, en professionnels du design inclusif et en experts des tests d’accessibilité augmente dans de nombreux secteurs.

Les raisons sont simples :

• Les réglementations sur l’accessibilité s’étendent.
• Les exigences en matière de marchés publics se renforcent.
• Les services numériques deviennent de plus en plus essentiels.
• Les organisations reconnaissent que les produits accessibles touchent souvent un public plus large.

Ce qui était autrefois considéré comme un marché de niche est de plus en plus reconnu comme un élément fondamental de l’innovation numérique et de la participation économique.

Pour les entreprises technologiques, l’accessibilité devient un enjeu commercial.

Pour les gouvernements, elle devient un enjeu politique.

Pour les personnes handicapées, elle reste ce qu’elle a toujours été : une question de droits, de participation et d’opportunité.

Vers la suite

S’il y a une seule leçon à retenir du mois passé, c’est que l’accessibilité et l’inclusion ne peuvent plus être traitées séparément des discussions plus larges sur la technologie.

Que l’on parle d’intelligence artificielle, de réglementation numérique, de technologies éducatives, de services publics ou d’écosystèmes d’innovation, l’accessibilité fait de plus en plus partie des conversations.

C’est un progrès.

Mais ce progrès n’est pas inévitable.

Les décisions prises aujourd’hui concernant la gouvernance de l’IA, les priorités de financement, les normes d’achat et la réglementation sur l’accessibilité façonneront les opportunités des personnes handicapées pendant de nombreuses années.

Le défi pour toutes celles et tous ceux qui travaillent dans le domaine de l’accessibilité, des technologies d’assistance et de l’inclusion est de veiller à ce que les personnes handicapées ne soient pas seulement considérées comme des utilisatrices des technologies futures, mais comme des participantes actives dans leur conception, leur gouvernance et leur évaluation.

La technologie continue d’évoluer rapidement.

La question n’est pas de savoir si le changement arrive.

La question est de savoir si ce changement sera inclusif.

Une version plus approfondie de cette newsletter est disponible à l’adresse suivante : https://zcmp.eu/xPZE?m=0

11 - Les échecs de conformité déclenchent-ils l'urgence ou le calcul budgétaire ?

Les manquements à la conformité déclenchent moins souvent une urgence ou une remise en question organisationnelle interne. Ils entraînent plutôt des discussions budgétaires, des modélisations juridiques et des exercices d’acceptation du risque. Amendes, frais juridiques et coûts d’accords transactionnels apparaissent dans les budgets. Les équipes juridiques estiment des fourchettes d’exposition. Les finances comparent le coût de la conformité au coût combiné des actions d’exécution, des accords et de la gestion de la réputation. La direction approuve le risque avec la même détachement qu’un budget d’assurance ou des frais de licence.

Cette approche requalifie la réglementation en option et rend le préjudice acceptable tant qu’il reste dans des contraintes financières jugées tolérables. Sur une feuille de calcul, cela peut sembler efficace ; mais à long terme, cela introduit des risques opérationnels, éthiques et stratégiques profonds.

Comment les amendes et accords transactionnels ont remplacé la responsabilité

La plupart des réglementations sont réactives : elles existent parce que des personnes ont été lésées. Des infrastructures ont failli de façons causant des dommages financiers ou humains durables. Chaque règle reflète des leçons tirées de ces préjudices, ainsi que des litiges et pressions publiques qui s’ensuivirent.

Quand des organisations décident d’absorber les amendes ou de régler les violations plutôt que de respecter les obligations réglementaires, la logique s’inverse. Le préjudice devient un calcul mathématique théorique plutôt que concret. L’impact devient abstrait au lieu d’être personnel. Les projets passent de la prévention du préjudice via la conformité à la simple limitation des pertes.

Avec le temps, ce basculement redessine le comportement organisationnel de façon prévisible.

Les dirigeants se focalisent sur la probabilité d’une action d’exécution plutôt que sur la possibilité d’un préjudice. L’attitude « nous n’avons pas encore été pris, donc le risque est faible » devient fréquente. Si on pense à un excès de vitesse (je n’ai pas été pris hier, donc mon risque aujourd’hui est faible), on reconnaît la fausseté du raisonnement. Malgré cela, les équipes produit vont plus vite en acceptant que la remédiation de conformité puisse être repoussée, voire ignorée.

On continue de récompenser les livraisons à l’heure malgré la non-conformité. Quand un dommage survient, les équipes juridiques négocient des accords sans admission de faute, avec peu de changements opérationnels et une surveillance limitée ou inexistante. Surtout, les victimes sont souvent réduites au silence. L’organisation poursuit son activité comme avant, tandis que les risques sous-jacents restent inchangés.

C’est la réalité nouvelle pour la plupart des exigences réglementaires, surtout dans les entreprises détenues par des fonds de private equity, qui cherchent à maximiser la valeur avec un investissement minimum et à court terme. Le private equity aggrave le phénomène, car on suppose souvent que l’entreprise sera revendue et que les préjudices accumulés seront alors transférés à d’autres.

Pourquoi cette stratégie amplifie le préjudice

Payer des amendes ou conclure des accords résout des incidents isolés sans corriger les systèmes qui les ont causés.

Les accords traitent généralement une violation précise tout en laissant les incitations intactes. Les pipelines de données fragiles restent fragiles. Les contrôles de sécurité restent sous-financés. La couverture des tests demeure incomplète. Les barrières d’accessibilité persistent. Les biais restent intégrés. Les failles de sécurité sont documentées mais non résolues. Même les accords exigeant une conformité future sont rarement réévalués pour vérifier cette conformité.

Chaque cycle renforce la leçon que les conséquences des violations sont survivables, négociables et rarement transformatrices pour l’entreprise fautive. On ne peut pas en dire autant des personnes lésées.

C’est ainsi que des violations isolées deviennent des schémas et que des cas limites deviennent des échecs routiniers. Les risques gérables s’accumulent jusqu’à produire des dommages systémiques qu’aucun accord ou rappel isolé ne peut corriger.

Les organisations qui s’appuient sur ce modèle le qualifient souvent de pragmatique. Elles affirment que la conformité ralentit la livraison, que la réglementation entrave l’innovation et que l’exécution est une friction plutôt qu’une protection client.

Ce que ces arguments ignorent systématiquement, c’est le coût cumulatif des préjudices répétés.

Le coût humain ne reste jamais externe

Dans une salle de conseil, amendes et accords semblent distants et gérables. Hors de cette salle, l’impact est immédiat et personnel.

Les employés s’épuisent quand on leur demande de livrer des travaux qu’ils savent risqués et évitables. Les clients perdent confiance quand les défaillances se répètent, accompagnées d’excuses qui sonnent comme des scripts. Les communautés souffrent quand des infrastructures échouent à plusieurs reprises. Les régulateurs intensifient la surveillance quand les schémas deviennent impossibles à ignorer.

Finalement, la responsabilité prend des formes souvent non prévues par les modèles de risque initiaux : départs de dirigeants, dégâts durables à la marque, instabilité du marché, perte de talents et surveillance réglementaire accrue. Ces conséquences sont bien plus perturbatrices que la conformité faite dès le départ.

Payer des amendes ou régler retarde la responsabilité, mais ne l’annule pas.

La conformité est un choix de conception

Les organisations qui prennent la réglementation au sérieux se comportent différemment bien avant qu’une sanction ne paraisse probable.

Elles impliquent des experts qualité, sécurité, accessibilité, confidentialité et gestion du risque dès la prise de décision. Elles documentent les choix et remettent en question les hypothèses. Elles traitent l’incertitude comme quelque chose à tester plutôt qu’à ignorer. Elles investissent dans la gouvernance, la surveillance et la validation pour que les défaillances apparaissent en interne plutôt qu’après un dommage client. Elles font ces choix non par peur des pénalités, mais parce qu’elles savent réduire les risques dans des systèmes complexes.

Les erreurs surviennent toujours. La différence tient à la rapidité de détection, de reconnaissance et de correction. L’échec devient un signal d’amélioration plutôt qu’un sous-produit toléré qui déclenche un jeu de blâme.

Ce que les régulateurs ne peuvent pas réparer

Les régulateurs peuvent imposer des amendes et approuver des accords, mais ils ne peuvent pas concevoir des systèmes internes. Juges et jurys peuvent attribuer la faute et chiffrer des pénalités, mais ne peuvent pas modifier les processus et politiques internes. L’intervention réglementaire reste réactive, après qu’un dommage est survenu. Les régulateurs, juges et jurys ne peuvent pas imposer des stratégies de test, des incitations ou des calendriers produits. Ils ne peuvent pas non plus annuler des décisions de direction prises bien avant la violation. Enfin, ils ne peuvent empêcher l’entreprise pénalisée de reproduire le même comportement le lendemain.

Quand les dirigeants traitent amendes et accords comme des coûts courants, la réglementation seule ne crée pas sécurité, équité ou fiabilité. L’organisation cherchera toujours la défaillance la moins coûteuse acceptable.

La vraie conformité commence par une autre question. Pas « combien cela coûtera-t-il si nous sommes pris ? », mais :

1. Qui pourrait être lésé si cela échoue ?

suivie de

2. Existe-t-il un groupe qui serait disproportionnellement lésé si cela échoue ?

Tant que les organisations ne posent pas systématiquement ces questions, amendes et accords resteront une taxe sur des préjudices évitables, et le public continuera d’en supporter le coût réel.

Pensées finales

Traiter amendes et accords comme des charges d’exploitation régulières affaiblit la conformité. Cela redéfinit la responsabilité. Quand le préjudice devient un poste budgétaire plutôt qu’un échec à prévenir, la prévention cesse d’être l’objectif. Le système privilégie la rentabilité sur la sécurité, la légalité ou l’équité.

Ce choix a des conséquences cumulatives. Chaque violation acceptée renforce les incitations à différer les corrections, à restreindre la responsabilité et à externaliser le risque. Chaque accord qui laisse les systèmes inchangés enseigne à l’organisation qu’elle peut poursuivre. À terme, l’écart entre le modèle de la direction et l’expérience publique devient impossible à contenir.

La conformité ne faillit pas parce que les règles seraient floues. Elle faillit parce que les organisations décident que les respecter est optionnel tant que l’application ne devient inévitable. Quand les régulateurs interviennent, le dommage est déjà fait, la confiance érodée et le coût de la réparation bien supérieur à ce qu’aurait nécessité une prévention précoce.

La question n’est pas de savoir si amendes et accords peuvent être absorbés — la plupart des grandes organisations le peuvent pendant des années — mais combien de temps une organisation peut répéter le choix de ne pas prévenir un préjudice connu avant que celui-ci ne devienne irréversible.

Les organisations qui veulent éviter ce résultat doivent rejeter l’idée que la conformité est un calcul financier après coup. C’est une décision d’architecture et de gouvernance prise au départ. Tant que la direction ne traitera pas la prévention des préjudices comme non négociable, amendes et accords continueront de fonctionner comme un prix à payer pour l’autorisation d’échouer.

12 - Les offres d'emploi sur l'accessibilité sont en hausse

Sur a11yjobs.com , même à la fin de l’année, lorsque les choses ralentissent généralement, le volume diffère de manière significative de ce qu’il était il y a même six mois. Récemment, j’ai vu 17 nouveaux rôles en une seule journée. C’était plus proche de ce qui s’est présenté sur deux semaines.

D’autres annonces sonnent comme une bonne nouvelle, non? Les détails à l’intérieur des listes racontent une histoire plus compliquée. De nombreuses organisations embauchent. Moins d’employeurs embauchent de manière à signaler que leurs programmes d’accessibilité sont durables. Et encore moins fournissent encore un salaire de subsistance dans des zones coûteuses.

Le volume a augmenté, mais la conception du rôle est souvent restée bloquée

Un pic d’affichage peut indiquer des investissements dans des programmes d’accessibilité. Cependant, cela peut également signifier que les organisations réagissent aux délais, aux risques d’application de la loi, aux changements de politique ou à la pression exercée par les arriérés. Quelle qu’en soit la cause, la façon dont les professionnels de l’embauche décrivent le travail dans les publications révèle comment ils pensent que l’accessibilité se produit.

À l’heure actuelle, de nombreux postes suggèrent que les organisations considèrent toujours l’accessibilité comme une fonction complémentaire plutôt que comme une capacité de produit qui nécessite de la dotation, des processus et une attention soutenue du leadership.

Il y a sept modèles que je vois dans les publications récentes sur l’accessibilité.

Modèle n ° 1: Beaucoup d’équipes veulent des compétences de licorne combinées avec des arachides pour le salaire

Une grande partie des descriptions de poste lisent comme un programme complet compressé en un seul rôle. Stratégie et gouvernance. Examen de la conception et expérience du système de conception. Consultation d’ingénierie. QA et exécution d’audit. formation. Soutien à l’achat. Remédiation du document. Gestion des fournisseurs. Reporting et métriques. Parfois, même la coordination juridique et la réponse aux incidents. Si vous pouvez faire ce type de travail et le faire bien, c’est génial, mais la plupart n’ont pas cette expérience.

Voici pourquoi c’est problématique: lorsqu’on s’attend à ce qu’un rôle soit mené à bien tout un programme, l’organisation n’embauche pas un employé. Il s’agit de sous-traiter la conception du programme à celui qui accepte l’offre. Cela conduit généralement à l’un des deux résultats.

• Soit le rôle devient triage, et l’organisation ne construit jamais de capacité durable.

• Alternativement, la location brûle et part, et l’organisation reposte le même rôle.

Quel que soit le résultat, c’est aussi un signal que le financement sera une bataille, et les heures supplémentaires non rémunérées sont presque garanties. De plus, vous ne pourrez jamais « dépasser les attentes » dans votre revue, puisque les attentes sont clairement irréalistes.

Modèle n ° 2: «niveau d’entrée» signifie salaire d’entrée de gamme, pas qualifications d’entrée de niveau

Un autre modèle apparaît dans les rôles étiquetés « entrée de gamme » avec des titres et une rémunération au niveau « starter role », combinés à des exigences pour des années d’expérience, une maîtrise technique avancée et un désir de certifications. Les exigences décrivent quelqu’un qui peut fonctionner de manière indépendante le premier jour, influencer les équipes interfonctionnelles et gérer les compromis de mise en œuvre complexes. La rémunération est comparable à celle de la gestion d’un restaurant de restauration rapide.

Cette inadéquation n’est pas seulement frustrante pour les candidats; elle est coûteuse pour les employeurs. Le chiffre d’affaires est le facteur le plus coûteux qui n’apparaît pas sur un poste de ligne budgétaire. Les gens prennent le travail parce qu’ils sont désespérés, puis partent le plus rapidement possible. De plus, les personnes qualifiées s’auto-sélectionnent souvent lorsqu’elles rencontrent une description de poste qui signale un sous-niveau, car c’est un signe de croissance de carrière limitée.

Si une équipe veut un talent d’entrée de gamme, l’affichage devrait refléter cela. Portée claire, mentorat structuré, budget de formation et responsabilités qui augmentent au fil du temps. Si l’équipe a besoin de quelqu’un qui peut livrer de manière indépendante, le titre et la rémunération doivent refléter cette réalité.

Modèle n ° 3: Le titre II indique souvent un désir de conformité à l’accessibilité, et non de compétence en matière d’accessibilité

Most Title II organizations have real accessibility obligations, timelines, and public accountability. Accessibility work in that context can carry high operational and reputational risks. Yet compensation for these roles often does not match the scope implied by the posting.

Low pay communicates that accessibility is treated as a compliance line item rather than infrastructure. It becomes harder to recruit experienced practitioners who have already learned, often the hard way, what it takes to build sustainable programs that get organizations where they want to go.

Public sector budgets are real constraints. Still, organizations can improve outcomes by defining roles realistically, building teams rather than assigning single points of responsibility, and investing in systems that reduce repetitive remediation work.

Pattern #4: In office requirements are rigidly common

Vous avez trouvé le travail parfait. On dirait que la description de poste a été écrite pour vous, et la rémunération est ce que vous recherchez. Et puis, boom, vous arrivez à la partie où il dit que vous devez être physiquement au bureau trois à cinq jours par semaine, à 1500 miles de distance. Même lorsque le travail quotidien est l’examen de la documentation, la collaboration de conception, l’examen du code, la coordination des tests et la formation, de nombreux affichages nécessitent toujours une présence au bureau. Parfois, l’exigence est encadrée en termes culturels. Parfois, elle est conçue comme une collaboration. Il n’est jamais encadré comme facultatif.

L’impact est simple. En particulier dans le domaine de l’accessibilité, le travail en cabinet requis réduit le bassin de candidats et filtre de manière disproportionnée les praticiens qualifiés handicapés, les responsabilités en matière de soins ou les contraintes de localisation. Il pousse les organisations vers des entonnoirs de recrutement plus petits et plus chers, puis le leadership se demande pourquoi il faut si longtemps pour trouver un candidat qualifié.

Hybrid and remote models are not perfect. They do, however, align well with the core workflows of most mid to senior-level accessibility roles. If an organization insists on maintaining an office presence, it should be prepared to justify the operational need and then accept the recruiting trade-offs.

Pattern #5: Jobs are moving to lower-cost areas

Another trend is the increase in roles tied to lower-cost locations, either through location-based salary bands or explicit requirements that candidates be based in specific regions. Sometimes this shows up as a subtle narrowing of approved work locations. Sometimes, it is a clear shift in where teams are building accessibility headcount.

Organizations will always manage compensation budgets. The risk to the employer is when location-based decisions override the desire to build a competent program.

Si le travail sert un produit national ou mondial, l’organisation a toujours besoin de capacités de haut niveau et d’une influence transversale. Le déplacement du rôle dans une zone à moindre coût ne change rien à la complexité du travail. Cela change le bassin de candidats qui peuvent se permettre de prendre le poste.

Pattern #6: Reposts raise uncomfortable questions

Some organizations repeatedly repost the same role every month. At a certain point, that pattern becomes a signal that can indicate a number of things about the program, most of them bad.

1. The compensation is not competitive.
2. La portée de l’emploi est trop large.
3. The hiring process is not doing a good job at skills assessment.
4. The role is not supported internally, and hires leave quickly.
5. There is no alignment on what success looks like.
6. The organization really doesn’t know what it’s looking for
7. The organization doesn’t have a “real” job and is collecting resumes for future needs or visa requirements.

Candidates notice. So do other hiring managers. A monthly repost becomes part of the employer brand, whether the organization intends that or not. There are well-known companies I will never apply to because they repeatedly post the same job, and there are no social media announcements about people accepting the previously posted position.

Pattern #7: Jobs are with agencies and are short-term 1099 contracts, not benefited employee positions

Short-term 1099 accessibility roles create real risk for practitioners with disabilities who rely on stable health insurance. C This is a poverty trap when pay exceeds the Medicaid eligibility threshold, especially given the recent elimination of health care subsidies on the federal exchange. Contract work without benefits frequently forces candidates with disabilities to choose between employment and health insurance.

Agency-based contracts often result in noticeably lower take-home pay because a significant portion of the rate gets skimmed off the top and never reaches the worker. The organization pays a premium, the agency takes its share, and the person doing the work gets whatever is leftover.

There is a deeper morale cost as well. Many contract roles focus on logging issues, writing reports, and moving on before remediation happens. When you never see fixes land, accountability blurs, and the work starts to feel transactional rather than meaningful. Accessibility work needs continuity to succeed, and short-term contracting undermines that continuity at every level.

What these patterns cost

Lorsque la conception de l’emploi est mal alignée, les coûts apparaissent rapidement.

Le temps de remplir le poste augmente à mesure que moins de candidats répondent aux exigences au niveau offert. Les résultats du programme se dégradent parce que le rôle devient réactif et motivé par l’arriéré. La rétention souffre parce que le travail s’étend plus vite que le soutien. Les intervenants perdent confiance parce que l’accessibilité ressemble à une urgence constante plutôt qu’à une capacité gérée.

Dans les contextes du titre II, le coût peut inclure des manquements de responsabilité publique. Dans les contextes du secteur privé, il peut englober le risque de litige, le risque contractuel et le risque d’accès au marché. Dans tous les contextes, cela implique souvent une livraison retardée des produits car les équipes redécouvrent à plusieurs reprises les mêmes problèmes d’accessibilité tard dans le cycle de publication.

À quoi ressemble une meilleure embauche d’accessibilité

Les offres d’emploi de meilleure accessibilité partagent plusieurs traits.

Le rôle est défini comme faisant partie d’un système. La description de travail clarifie ce que le rôle possède et ce qu’il influence. Il nomme les équipes partenaires. Il décrit comment les décisions sont prises. Le travail sépare le leadership des programmes de l’exécution pratique. Plus important encore, le travail n’a pas d’agence au milieu faisant très peu pour leur coupe.

Si un rôle définit la stratégie et la gouvernance, il ne devrait pas non plus être responsable de l’exécution de chaque vérification et de chaque plan d’assainissement. Si un rôle est un exécutant, il ne devrait pas être demandé d’assurer la gouvernance à l’échelle du programme sans autorisation.

L’emploi aligne l’ancienneté, la rémunération et les attentes. Les rôles d’entrée de gamme devraient inclure la formation et le mentorat. Les rôles de direction ont l’autorité, le soutien interfonctionnel, un budget et une rémunération à la mesure des responsabilités.

Si le travail peut être fait efficacement à distance, dites-le. Si une présence en bureau est nécessaire, expliquez pourquoi en termes opérationnels. N’appelez pas une télécommande de travail si elle est hybride. Ce ne sont pas les mêmes choses.

Dernières Pensées

L’augmentation des offres d’emploi pour l’accessibilité est réelle. La question est de savoir si les organisations renforcent la capacité d’accessibilité ou augmentent le nombre de rôles avec des défauts mortels, ce qui signifie qu’elles ne réussiront jamais.

L’embauche d’accessibilité est un renforcement des capacités. Les équipes qui le traitent comme une infrastructure vont embaucher, soutenir et retenir différemment. Les organisations qui ne continueront pas à publier, à rechercher et à se demander pourquoi le pipeline semble occupé alors que les résultats restent inégaux.

13 - Les personnes en situation de handicap sont plus susceptibles que les autres d’avoir une expérience judiciaire (United States of America)

Aperçu

Près de la moitié des adultes en situation de handicap vivent dans un foyer où quelqu’un a été impliqué dans une affaire judiciaire, selon un récent sondage national réalisé par The Pew Charitable Trusts. Il s’agit des premières données connues sur la fréquence des interactions de cette population avec les tribunaux, fréquence nettement plus élevée que pour les personnes sans handicap.¹ Le sondage montre également que les personnes en situation de handicap trouvent les tribunaux difficiles à appréhender et leur attribuent des avis moins favorables que les personnes sans handicap.

Build Communities — Experience With State Courts Highlights Areas for Improvement

Note d’information — 4 août 2025

Le sondage, réalisé par la société de sondages d’opinion publique SSRS, visait à comprendre comment les personnes aux États‑Unis interagissent avec et perçoivent les tribunaux d’État et locaux dans leurs communautés. Il a intégré les points de vue d’adultes en situation de handicap — ayant ou non une expérience judiciaire.² Les résultats offrent aux responsables des tribunaux des informations sur la performance des tribunaux, l’adoption des technologies et la facilité d’accès, utiles pour moderniser l’accès et établir la confiance avec cette communauté.³ Ils soulignent aussi l’importance de comprendre les perspectives et expériences de populations démographiques distinctes afin de garantir que les efforts de modernisation reflètent les besoins et réalités de tous les groupes servis par les tribunaux.

Prévalence élevée des personnes en situation de handicap dont le foyer a eu une affaire judiciaire

Près d’un adulte sur deux aux États‑Unis en situation de handicap (49 %) vit dans un foyer où quelqu’un a eu une affaire judiciaire (civile, pénale, familiale ou pour infraction routière). Ce taux est nettement supérieur à celui des adultes sans handicap (29 %). Au total, les adultes en situation de handicap représentent environ 30 % de la population générale.⁴

Les réponses varient selon les caractéristiques démographiques parmi les personnes en situation de handicap. Les hommes ont déclaré des participations judiciaires à des taux plus élevés que les femmes (55 % contre 46 %). Les répondants noirs et hispaniques étaient plus susceptibles de déclarer une expérience judiciaire — 57 % et 55 % respectivement — que les répondants blancs (47 %). Et les républicains déclaraient plus souvent une expérience judiciaire que les démocrates (57 % contre 45 %).

Les adultes en situation de handicap attribuent des notes moins favorables aux tribunaux que les autres

Plus de répondants en situation de handicap — qu’ils aient ou non une expérience judiciaire — ont donné la note « C » aux tribunaux (40 %) que toute autre note ; c’est légèrement supérieur à la proportion chez les adultes sans handicap (37 %).

Seulement 29 % des personnes en situation de handicap ont attribué un « A » ou « B » aux tribunaux, contre 35 % chez les personnes sans handicap. Par ailleurs, 21 % des répondants en situation de handicap ont donné une note « D » ou « F », contre 15 % des répondants sans handicap.

Les adultes en situation de handicap ont également déclaré une moindre confiance dans l’équité des tribunaux. Si la majorité (63 %) a déclaré être confiante que les tribunaux de leur communauté traitent les personnes équitablement, que celles‑ci aient un handicap ou non, ce taux est notablement inférieur à celui des adultes sans handicap (73 %).

Aller au tribunal a aussi affecté la confiance dans le système : 40 % des personnes en situation de handicap ont déclaré que leur confiance a quelque peu ou fortement diminué après leur expérience judiciaire récente. Treize pour cent ont déclaré que leur confiance a quelque peu ou fortement augmenté.⁵

Les adultes en situation de handicap ont une opinion moins favorable de l’adoption des technologies par les tribunaux

Les personnes en situation de handicap (57 %) — qui comptent souvent sur la technologie pour l’accès, comme la visioconférence ou téléconférence, les sous‑titres, les logiciels de reconnaissance vocale, les outils d’orientation et les équipements activés par capteurs — étaient plus susceptibles que les personnes sans handicap (49 %) d’évaluer la capacité des tribunaux à adopter et utiliser de nouvelles technologies comme « passable » ou « faible ».⁶

La flexibilité est essentielle pour l’accessibilité judiciaire, car il n’existe pas de solution universelle. Lorsqu’on leur a demandé leur avis sur la comparution virtuelle ou en personne, près de 65 % des adultes en situation de handicap ont déclaré que les tribunaux devraient permettre de choisir la comparution virtuelle pour la plupart des types d’affaires, exprimant un léger penchant plus marqué que les personnes sans handicap (59 %).

La plupart des adultes en situation de handicap ayant une expérience judiciaire ont trouvé le tribunal difficile à appréhender

La majorité (55 %) des adultes en situation de handicap dont le foyer a eu une affaire judiciaire ont déclaré que le tribunal était difficile à appréhender, notamment pour comprendre les étapes de la procédure ou les formulaires.⁷

Malgré l’effet de l’expérience judiciaire sur leur confiance envers les tribunaux, 60 % des adultes en situation de handicap ont déclaré avoir ressenti un peu ou beaucoup de respect de la part des juges tout au long du processus judiciaire ; et la plupart — 56 % — ont déclaré faire confiance au fait que les juges et le personnel du tribunal avaient essayé de faire ce qui était juste pour tous les participants.⁸

Parmi les personnes en situation de handicap ayant eu une affaire judiciaire, les réponses selon des groupes démographiques (tels que race/ethnicité, sexe, affiliation politique et niveau d’études) n’ont pas donné de résultats statistiquement significatifs, possiblement en raison de la taille de l’échantillon, et ne sont pas présentées ici. Toutefois, comme la recherche indique des différences démographiques dans la manière dont les personnes en situation de handicap vivent certaines parties du système de justice, ces facteurs demeurent importants à considérer dans de futures recherches sur les perspectives et expériences judiciaires.⁹

Les responsables des tribunaux peuvent utiliser ces résultats pour renforcer les efforts d’accessibilité

Les personnes en situation de handicap font souvent face à des obstacles d’attitude et d’accessibilité lorsqu’elles interagissent avec les tribunaux d’État et locaux.¹⁰ Ceci, couplé à leur surreprésentation parmi les foyers ayant eu une affaire judiciaire, souligne l’importance pour les tribunaux de s’assurer que cette population puisse naviguer efficacement dans le système et participer pleinement à leurs affaires.

D’autres recherches sont nécessaires pour relier directement ces résultats de sondage aux barrières d’attitude et d’accessibilité, et à la manière dont ces barrières peuvent affecter les résultats judiciaires. Mais les différences de réponses entre les adultes en situation de handicap et ceux sans handicap suggèrent que le statut de handicap peut façonner les perceptions des tribunaux ainsi que les expériences au sein de ces tribunaux. Ces constats offrent donc aux responsables des tribunaux des éléments pour orienter les efforts d’accessibilité et de modernisation afin de favoriser une plus grande confiance parmi les personnes en situation de handicap et garantir l’égalité de la justice pour tous.

14 - Shifting Left: Comment intégrer l'accessibilité dans les processus quotidiens de création de documents

📌 Introduction et contexte

• Modérateur : Eugene Wu (CEO de Venngage ), un outil de design axé sur les documents accessibles (export en PDF accessibles).
• Format :
  • Questions/réponses via le bouton Q&A sur Zoom.
  • Objectif : Discuter de l’intégration de l’accessibilité dès le début des processus (“shifting left”).

🎤 Présentation des intervenants

Intervenants

💡 Définition du “Shifting Left”

🔹 Rob Carr

“Pousser l’accessibilité dans les phases les plus précoces d’un projet. L’objectif est d’éviter que l’accessibilité ne soit reléguée aux équipes d’implémentation, de test ou de QA. Cela s’applique à la conception de documents, au design web, à la passation de marchés, etc.”

🔹 Neil Milliken

“Le terme vient des diagrammes de Gantt : si le projet se termine à droite, il faut agir à gauche (au début). En accessibilité, cela signifie intégrer ces réflexions dès l’idéation pour éviter de corriger des erreurs coûteuses plus tard.”

🔹 Samantha Evans

“La plupart des organisations traitent encore l’accessibilité comme une case à cocher en fin de processus. Le problème ? Elle n’est pas perçue comme un pilier de la gouvernance (au même titre que la sécurité ou la confidentialité).”

❓ Pourquoi ce problème persiste-t-il ?

Causes identifiées :

1. Manque de culture organisationnelle (Rob Carr) :

   • L’accessibilité n’est pas une norme ancrée dans les processus.
   • Manque de leadership actif pour en faire une priorité.

2. Approche fragmentée (Samantha Evans) :

   • Les organisations se concentrent sur des audits ou formations ponctuelles, sans vision globale.
   • L’accessibilité est souvent vue comme un coût plutôt qu’un investissement.

3. Churn constant (Neil Milliken) :

   • Même avec des processus en place, le turnover dans les grandes organisations nécessite une formation continue.

4. Manque de scaffolding (Rob Carr) :

   • Scaffolding = Échafaudage organisationnel (outils, temps, ressources) pour soutenir l’accessibilité.
   • Exemple : Former une équipe sans lui donner le temps d’appliquer ces connaissances.

🏗️ Comment construire un “scaffolding” efficace ?

🔹 Rob Carr

• Ne pas se limiter à la formation :
  • Il faut aussi :
    • Du temps pour pratiquer.
    • Des outils adaptés.
    • Une intégration dans les workflows existants (ex. : tests d’accessibilité dès la phase de recherche utilisateur).
• Éviter de surcharger les équipes :
  • Ne pas imposer une formation ou un audit à une équipe en pleine deadline.

🔹 Neil Milliken

• S’inspirer des cultures existantes :
  • Exemple chez Atos : La culture sustainability/green IT était déjà ancrée.
  • Stratégie : Associer l’accessibilité à cette culture en la présentant comme une réduction des externalités négatives (ex. : “L’inaccessibilité, c’est comme la pollution”).
  • Résultat : Utiliser les mêmes processus de gouvernance pour les deux enjeux.

🔹 Samantha Evans

• Commencer petit :
  • Étape 1 : Identifier des actions réalisables (ex. : former une équipe sur les outils existants).
  • Étape 2 : Documenter les progrès pour montrer l’impact (ex. : réduction des coûts de remédiation).
  • Étape 3 : Intégrer dans les KPIs des équipes (ex. : “Ce projet a économisé X heures de rework grâce à l’accessibilité”).

👔 Rôles clés pour l’accessibilité

🔹 Le “Unicorn Role” : Un piège ?

• Problème : Les offres d’emploi recherchent souvent un expert tout-en-un (technique, juridique, design, etc.) pour un salaire modéré.
• Conséquence : Burnout des généralistes, qui doivent tout gérer seuls.

Solutions proposées :

“Si l’accessibilité est la responsabilité de tous, c’est souvent la responsabilité de personne.” — Neil Milliken

🛠️ Outils et systèmes pour “Shifter Left”

🔹 Types d’outils nécessaires :

1. Outils intégrés :

   • Ex. : Vérificateurs d’accessibilité natifs (Microsoft Office, Adobe Acrobat).
   • Activation par défaut des notifications d’accessibilité (ex. : Neil a demandé à son CIO d’activer le vérificateur pour tout le domaine).

2. Templates accessibles :

   • Documents : Modèles Word/PDF pré-remplis avec des styles accessibles.
   • Presentations : Templates PowerPoint/Google Slides avec contrastes de couleurs validés.
   • Web : Design systems avec composants accessibles par défaut.

3. Outils de collaboration :

   • Procurement : Évaluer l’accessibilité des outils avant achat (ex. : CMS, LMS).
   • Brand Guidelines : Intégrer l’accessibilité dans les chartes graphiques (ex. : palettes de couleurs contrastées, dark mode).

🔹 Exemple concret (Neil Milliken) :

• Eco-brand chez Atos :
  • Réduction de la consommation énergétique + accessibilité (ex. : dark mode + contrastes validés).
  • Bénéfice : Double gain (RSE + inclusion) pour justifier les budgets.

📊 Mesurer l’impact et convaincre la direction

🔹 Arguments clés :

1. Économies :

   • 1 heure de test en amont = 5 heures de rework évitées (étude citée par Rob Carr).
   • Coût de la non-accessibilité : Litiges, remédiation, perte de clients.

2. Alignement avec d’autres enjeux :

   • Sécurité/Confidentialité : Une interface inaccessible peut exposer à des risques de sécurité (ex. : impossibilité de saisir un mot de passe de manière autonome).
   • RSE : L’accessibilité renforce l’image socialement responsable de l’entreprise.

3. Conformité légale :

   • 400+ lois dans 70 pays imposent l’accessibilité (directement ou indirectement).
   • Exemples :
     • ADA Title II (États-Unis) : Deadline en avril 2026 pour les organisations publiques.
     • European Accessibility Act : Obligations pour les entreprises européennes.

🔹 Conseils pour les “unicorns” isolés :

• Documenter les efforts :
  • Envoyer des emails/rapports aux équipes pour prouver les avertissements donnés.
  • Calculer le ROI : Montrer les économies réalisées (ex. : “Ce projet a évité X€ de coûts de remédiation”).
• Laisser les erreurs se produire (parfois) :
  • Si une équipe ignore les conseils, laisser le problème survenir pour qu’elle en assume la responsabilité (Neil Milliken).

🔮 Tendances futures (2026 et au-delà)

🔹 Régulations à venir :

• ADA Title II (Avril 2026) :

  • Les organisations publiques américaines devront soumettre un plan d’accessibilité annuel.
  • Prévision : Pénurie de ressources et demande accrue pour les généralistes (Rob Carr).

• Marché de l’accessibilité :

  • Augmentation des contrats pour les experts, mais risque de rôles mal définis (ex. : “unicorn roles”).
  • Opportunité : Les organisations vont réaliser qu’elles ont besoin de rôles dédiés.

🔹 Évolution des outils :

• Intégration native : Les outils (CMS, suites bureautiques) intègreront de plus en plus de fonctionnalités accessibles par défaut.
• Automatisation : Développement de bots (ex. : “Reggie” chez Atos pour répondre aux questions réglementaires).

🎯 Conseils pratiques pour démarrer

Pour les organisations en “Step 0” :

1. Ne pas viser la perfection :
   • Commencer par des actions simples et mesurables (ex. : former une équipe sur les outils existants).
2. Identifier des alliés :
   • Trouver des champions internes (même informels) pour distribuer la charge.
3. Intégrer dans les processus existants :
   • Ex. : Ajouter l’accessibilité aux checklists de projet ou aux critères de procurement.

Pour les “unicorns” :

• Former des relais :
  • Partager des bonnes pratiques avec d’autres équipes pour créer une culture collective.
• Montrer l’impact :
  • Chiffrer les économies (temps, argent) pour justifier des budgets supplémentaires.

🔗 Ressources mentionnées

• WebAIM Million : webaim.org/projects/million/
• AXS Chat (Podcast) : axschat.com
• IAAP (Certifications) : accessibilityprofessionals.org
• Lady Fineold (Régulations mondiales) : fineold.com

💬 Conclusion

“L’accessibilité, ce n’est pas une case à cocher. C’est un processus continu qui nécessite une culture, des outils, et un leadership engagé.” — Eugene Wu

15 - Solving for the Edges – Gerard K. Cohen (A11yTalks - May 2026) - Accessibility Talks

Message clé : *“Résoudre pour les extrêmes (handicaps) = innover pour tous.”*3 leçons :

1. L’accessibilité drive l’innovation (ex. : téléphone, email, OCR… nés de besoins spécifiques).
2. La “moyenne” n’existe pas → Design pour la variabilité (ex. : cockpits réglables).
3. Données trompeuses : Si personne ne se plaint, c’est que les exclus ne peuvent pas parler.

3 actions prioritaires :

1. Intégrer l’accessibilité dès la conception (shift left + équipes diversifiées).
2. Tester avec de vrais utilisateurs (y compris en situation de handicap).
3. Quick wins :
   • Contraste WCAG AA (4.5:1),
   • Navigation clavier,
   • Textes alternatifs,
   • Media Queries (prefers-reduced-motion, prefers-color-scheme).

** Objectif** : Passer d’une logique “coût” à une logique “investissement” (marché élargi, UX améliorée, conformité).

Bonjour à tous et bienvenue à une nouvelle édition des Accessibility Talks ! Nous sommes ravis que vous puissiez nous rejoindre pour notre rencontre virtuelle mensuelle sur l’accessibilité, l’inclusion et l’utilisabilité. C’est un espace où nous apprenons des intervenants invités et où nous nous connectons en tant que communauté. Je suis votre hôtesse, Aubrey Sambor, et je suis lead front-end developer. Pour une description visuelle : je suis une femme blanche aux longs cheveux violets et bleus, et je porte un pull jaune tricoté à la main. Mes pronoms sont elle et elle (she/her).

Avant de commencer, un petit rappel : A11y Talks s’engage à maintenir un environnement sûr et accueillant. Nous demandons à chacun d’entre vous — intervenants comme participants — de respecter notre code de conduite dans le chat et pendant les discussions. Vous trouverez la version complète sur notre site web. Notre objectif est de garantir un espace respectueux pour un dialogue ouvert et un apprentissage mutuel.

Nous tenons également à remercier les partenaires qui rendent A11y Talks possible. Un merci spécial à notre sponsor bronze, Principal Financial Group. Nous souhaitons aussi saluer les membres mensuels de notre A11y Cat Club. Chaque contribution nous aide à faire grandir cette communauté, à garder nos contenus gratuits et nos conférences accessibles à tous. Si vous souhaitez soutenir A11y Talks en tant que sponsor, visitez notre site web pour en savoir plus. Vos contributions servent directement à rémunérer les intervenants et à améliorer nos événements. Vous pouvez aussi doubler votre impact grâce à des programmes de contrepartie d’entreprise comme Benevity. Il suffit de nous chercher sous le nom A11y Talks by Midwest Open Source Alliance.

Comment poser des questions à notre intervenant ?

• Si vous regardez la première diffusion en direct sur YouTube, posez vos questions dans le chat en direct.
• Si vous ne regardez pas en direct, vous pouvez laisser un commentaire sous la vidéo YouTube ou poursuivre la discussion sur LinkedIn ou d’autres réseaux sociaux par la suite.

Présentation de l’intervenant

Aujourd’hui, nous accueillons Gerard K. Cohen, Defenseur de l’accessibilité numérique et Engineering Manager. Il nous présente une conférence intitulée « Résoudre pour les extrêmes » (Solving for the Edges). Je suis vraiment impatiente d’assister à cette présentation. Gerard, une petite anecdote sur toi : tu es un introverti amateur de sensations fortes, et ta série préférée est Les Craquantes (The Golden Girls). Veux-tu nous en parler ? Je suis très curieuse de savoir quels types de sensations fortes tu recherches !

Gerard : Merci, Aubrey. Parfois, ma femme déteste quand je dis ça, mais… parfois, j’ai l’impression de ne pas vraiment vivre si je n’ai pas l’impression de mourir. J’aime sauter de choses, nager et plonger avec des animaux dangereux, les observer. Bref, tout ce qui fait monter mon rythme cardiaque, c’est amusant pour moi.

Aubrey : Quels types de choses as-tu déjà sautés ? Du saut à l’élastique, du parachutisme, ce genre de choses ?

Gerard : Oui, et le saut à l’élastique ! Il n’y a que quelques endroits aux États-Unis qui sont certifiés pour du vrai saut à l’élastique légitime. Je ne l’ai pas encore essayé, mais je cherche quelqu’un pour le faire avec moi. Si ça vous tente, faites-moi signe !

Aubrey : Et Les Craquantes ? Tu les regardais quand tu étais enfant, ou c’est juste une série que tu aimes ?

Gerard : Oui, ça me rappelle mon enfance. Le samedi soir, ça passait à la télé, et maintenant, c’est juste une bonne série pour se détendre après avoir sauté de quelque chose. On peut se calmer en regardant Les Craquantes. Elles sont hilarantes.

Aubrey : C’est vrai, c’est une excellente façon de se détendre après une montée d’adrénaline. Merci pour ces confidences, Gerard. À toi la parole !### Introduction de Gerard K. Cohen Merci beaucoup, Aubrey, et bienvenue à tous pour cette conférence « Résoudre pour les extrêmes ». Je sais que vous auriez pu être ailleurs, faire autre chose en ce moment, alors merci d’être là. Cette présentation sera un peu différente pour moi : ce ne sera pas une conférence très technique. Espérons que tout le monde y trouvera quelque chose à apprendre.

Pour ceux qui ne me connaissent pas encore, je m’appelle Gerard K. Cohen, et actuellement, je suis au chômage. Donc, si vous avez un besoin, n’hésitez pas à me contacter. Jusqu’à récemment, je dirigeais l’accessibilité pour le design system d’Atlassian, où j’ai collaboré avec une équipe exceptionnelle de designers et d’ingénieurs pour améliorer l’accessibilité des composants que nous utilisons pour construire des outils de productivité d’équipe — certains que vous critiquez peut-être souvent, comme Jira, Confluence ou Trello. Avant cela, j’étais engineering manager pour l’équipe accessibilité de Twitter, avant que le propriétaire actuel ne nous licencie tous.

Je vais épeler mon nom, car c’est comme ça que vous me trouverez partout : G-E-R-A-R-D K C-O-H-E-N. Vous pouvez me contacter via LinkedIn en cherchant mon nom, ou consulter mon site web : GerardKCohen.me .

Enfin, j’ai aussi des cours techniques sur la plateforme d’apprentissage Pluralsight, dont je suis très fier, car ils s’adressent à tous :

• Product Managers (PM),
• designers visuels,
• designers de contenu,
• ingénieurs,
• testeurs QA.

Ces cours ont été utilisés par de grandes organisations comme l’État de Californie ou le Google Africa Developer Scholarship pour des développeurs en début de carrière. Il y a au total quatre cours, commençant par « Les bases du design web accessible ».#### Mes cours sur Pluralsight

1. « Les bases du design web accessible » : Ce cours vous aidera à acquérir les connaissances et compétences pour respecter les directives d’accessibilité du web. Particularité : Je vais jusqu’au niveau WCAG AAA (alors que la plupart s’arrêtent à AA). Je pense que le niveau AA est le minimum, mais on ne dit jamais où aller après. Le niveau AAA n’est pas adapté à tout le monde, mais si vous vous concentrez sur une bonne utilisabilité pour tous, alors AAA n’est pas si loin. Durée : un peu plus de 2 heures. Parfait pour les débutants.

2. « Techniques de test pour l’accessibilité web » : Un cours de 2 heures pour apprendre aux designers, rédacteurs, développeurs et testeurs QA des méthodes rapides et simples pour tester l’accessibilité, sans avoir besoin d’utiliser des technologies d’assistance comme les lecteurs d’écran. Il y a tellement de choses à tester sans même toucher à un lecteur d’écran (qui peut être difficile à apprendre et à utiliser correctement).

3. « Test de compatibilité avec les lecteurs d’écran pour l’accessibilité web » : Un cours avancé sur les tests. En tant qu’utilisateur non natif des technologies d’assistance comme les lecteurs d’écran, j’essaie de partager comment tester de manière plus proche de la façon dont les gens utilisent réellement ces outils, plutôt que de simplement tester avec un lecteur d’écran (ce qui est différent). Je couvre VoiceOver, JAWS, NVDA, ainsi que les tests sur iOS et TalkBack sur Android, y compris l’utilisation du clavier avec les téléphones. Durée : environ 2 heures. Je n’ai vu aucun autre cours de test aller aussi loin. J’en suis vraiment fier.

4. « Les bases de l’ARIA pour l’accessibilité web » : Ce cours expose les fondamentaux et concepts qui vous permettront de construire en toute confiance des composants personnalisés accessibles avec ARIA, à travers des exemples pratiques pour offrir des expériences inclusives. Je passe en revue :

   • la spécification ARIA,
   • les dangers de l’ARIA,
   • les pièges de l’utilisation de ressources comme le guide des bonnes pratiques de rédaction. Enfin, je détaille un exemple pour créer un simple bouton de menu, y compris comment l’expérience varie selon les combinaisons de navigateurs et technologies d’assistance, et comment gérer ces différences. Durée : environ 1h30.

En moins de 8 heures, vous pouvez obtenir une formation complète en accessibilité, basée sur mes 10 ans d’expérience, d’apprentissage et d’erreurs, pour que vous n’ayez pas à les reproduire. Vous pouvez les trouver sur pluralsight.com/authors/Gerard-Cohen . (Et comme je suis actuellement au chômage, ces cours sont ma seule source de revenus, alors merci de votre patience pendant que je les promeus !)

Accès aux supports de la conférence

Si vous souhaitez suivre avec vos propres notes, à l’écran, il y a un code QR qui mène aux diapositives. Sinon, voici une URL raccourcie : bit.ly/47NHXPPY (B-I-T dot L-Y / 4 7 N H X P Y)## Résoudre pour les extrêmes : des innovations qui changent tout

Je vais commencer par des exemples d’innovations révolutionnaires qui, à l’origine, résolvaient des problèmes spécifiques (pour les “extrêmes”), mais qui ont fini par améliorer la vie de tous.### 1. La machine à écrire (1801) – Pellegrino Turri

• Contexte : À l’époque, une personne aveugle devait dicter ses lettres à quelqu’un d’autre pour qu’elles soient écrites.
• Histoire : Turri, un inventeur italien, est tombé amoureux d’une comtesse qui perdait la vue. Pour qu’elle puisse lui écrire des lettres en privé (sans avoir à les dicter), il a inventé la première machine à écrire (appelée “writing machine”), ainsi que le papier carbone pour l’encre.
• Impact : Les lettres de la comtesse écrites avec cette machine existent encore aujourd’hui.
• Évolution : La machine à écrire a évolué vers les claviers, que nous utilisons encore aujourd’hui.### 2. Le téléphone (1856) – Antonio Meucci
• Contexte : Meucci, un inventeur italien, voulait communiquer avec sa femme, alitée à cause d’une arthrite rhumatoïde sévère.
• Invention : Il crée le Teletrafono, un dispositif de communication précoce (une version très primitive du téléphone).
• Controverse : En 1876, Alexander Graham Bell obtient le brevet du téléphone, bien que Meucci et d’autres aient revendiqué l’invention avant lui.
  • En 2002, le Congrès américain a officiellement reconnu Meucci comme l’inventeur du téléphone.
  • Pourquoi ? Meucci n’avait pas les 10 dollars nécessaires pour finaliser son brevet.
• Inspiration de Bell : Sa mère et sa femme étaient sourdes. Il voulait amplifier le son pour elles.
• Impact : Aujourd’hui, nous utilisons toujours le téléphone.### 3. Le phonographe (1877) – Thomas Edison
• Invention : Edison invente le phonographe, un appareil capable d’enregistrer et de reproduire des sons.
• Utilisation prévue : Créer des livres audio pour les aveugles, afin qu’ils n’aient plus besoin de dépendre de leur famille pour leur faire la lecture.
• Impact : Aujourd’hui, les livres audio sont une ressource essentielle pour de nombreuses personnes.### 4. L’Optophone (1913) – Edmund Fournier d’Albe
• Invention : Un appareil qui scannait les pages et détectait le contraste entre lumière et obscurité pour distinguer les caractères.
  • Il produisait ensuite des tons audibles correspondant aux lettres.
• Objectif : Permettre aux aveugles de lire des livres de manière autonome.
• Limite : Très lent (environ 1 mot par minute).
• Impact : Bien que l’Optophone n’ait pas perduré, il a marqué la naissance de la reconnaissance optique de caractères (OCR), une technologie toujours utilisée aujourd’hui.### 5. Le transistor (1948) – Bell Labs
• Invention : Le transistor, un composant capable d’amplifier le courant électrique.
• Utilisation initiale : Réduire la taille des appareils auditifs pour les personnes malentendantes.
• Impact : Les transistors sont aujourd’hui omniprésents dans l’électronique moderne (smartphones, ordinateurs, etc.).### 6. La synthèse vocale (1975) – TSI (Speech Plus)
• Invention : Le Speech Plus, une calculatrice parlante pour les aveugles.
• Impact : Aujourd’hui, la synthèse vocale est utilisée dans de nombreuses interfaces vocales (assistants vocaux, GPS, etc.).### 7. L’email commercial (1982) – Vint Cerf
• Contexte : Vint Cerf, l’un des pères d’Internet, crée le premier système d’email commercial (MCI Mail) alors qu’il travaille pour MCI.
• Inspiration : Cerf est malentendant et sa femme est sourde. Il voulait pouvoir communiquer avec sa famille.
• Impact : Aujourd’hui, l’email est un outil de communication indispensable.
• Fun fact : Cerf porte un appareil auditif… qui n’existerait pas sans le transistor inventé par Bell Labs !### 8. Le World Wide Web (1989) – Tim Berners-Lee
• Invention : Le World Wide Web, qui repose sur le protocole TCP (inventé par Vint Cerf).
• 1990 : Il crée le premier serveur web et le premier navigateur.
  • Vous pouvez toujours voir le premier site web (il explique ce qu’est le World Wide Web).
• 1994 : Il fonde le W3C (World Wide Web Consortium), l’organisme de standardisation du web.
  • Le W3C abrite aussi le WAI (Web Accessibility Initiative), qui publie :
    • Les WCAG (Web Content Accessibility Guidelines),
    • La spécification ARIA,
    • D’autres ressources liées à l’accessibilité.
• Citation célèbre de Berners-Lee :

  « Le pouvoir du web réside dans son universalité. L’accès pour tous, indépendamment du handicap, est un aspect essentiel. »

  • Son intention : Le web a toujours été conçu pour être accessible à tous.

Synthèse : L’innovation par l’accessibilité

Si on combine toutes ces innovations :

• Typographie (machine à écrire),
• Amplification du son (téléphone, transistor),
• Reproduction du son (phonographe),
• OCR (Optophone),
• Synthèse vocale,
• Internet (email, web),

… on obtient l’informatique mobile (smartphones, tablettes, etc.).

Point commun : Ces innovations ont résolu des problèmes pour les “extrêmes” (personnes en situation de handicap), mais ont fini par bénéficier à tous.## Le piège de la “moyenne” : pourquoi résoudre pour l’“utilisateur moyen” est une erreur

1. Le cas des cockpits de l’US Air Force (années 1940-1950)

• Problème : Dans les années 1940, l’US Air Force perdait des pilotes expérimentés dans des accidents, alors que les avions fonctionnaient parfaitement.
• Hypothèse initiale : Erreur de pilotage.
• Réalité : Le problème venait du cockpit, conçu pour un “pilote moyen”.
  • Depuis les années 1920, les cockpits étaient basés sur les dimensions moyennes de centaines de pilotes américains (hauteur du siège, distance des pédales, portée des commandes, etc.).
• Étude de 1950 :
  • L’US Air Force mesure 4 000 pilotes sur 140 dimensions différentes.
  • Résultat : Aucun pilote ne correspondait à la moyenne sur les 10 dimensions clés.
    • Même sur 3 dimensions seulement, moins de 5 % des pilotes correspondaient à la moyenne.
• Conclusion : Le “pilote moyen” n’existe pas.
  • Les humains sont variables : une personne peut avoir une taille moyenne, mais des bras plus longs, un torse plus court, etc.
  • C’est ce qu’on appelle la « malédiction de la dimensionnalité » : plus on ajoute de dimensions, moins la moyenne représente des personnes réelles.

Solution de l’US Air Force :

• Au lieu de chercher une meilleure moyenne, ils ont résolu pour la variabilité :
  • Sièges réglables,
  • Pédales ajustables,
  • Commandes flexibles,
  • Équipement personnalisable.
• Résultat : Les performances des pilotes se sont améliorées, et les accidents ont diminué.
• Fun fact : Ce n’est qu’en 2022 que l’US Air Force a supprimé les exigences de taille pour les pilotes de chasse, car elles excluaient des femmes et des personnes de certaines ethnies qualifiées.### 2. Le biais du survivant : l’histoire des avions de la Seconde Guerre mondiale
• Contexte : Pendant la Seconde Guerre mondiale, l’US Navy étudiait les avions endommagés qui revenaient de mission pour savoir où ajouter du blindage.
• Observation : Les impacts de balles étaient concentrés sur les ailes et le fuselage.
• Conclusion initiale : Renforcer ces zones.
• Problème : Abraham Wald, un statisticien, a souligné le biais du survivant :
  • Les avions qui avaient été touchés au moteur ou au cockpit n’étaient pas revenus.
  • Le blindage devait être ajouté là où il n’y avait PAS de trous (car ces zones étaient fatales).
• Leçon : Ce qu’on ne voit pas est souvent plus important que ce qu’on voit.

Application à l’accessibilité et au design

1. Le biais du survivant dans le design produit

Nous commettons la même erreur en nous basant sur :

• Les analytics : Si une personne ne peut pas naviguer dans votre appli, comment peut-elle être comptabilisée ?
• Les tests d’utilisabilité :
  • Les prototypes (même haute fidélité) ne génèrent pas de code accessible.
  • Combien de personnes en situation de handicap sont invitées à ces tests ?
  • Questions à poser :
    • « Est-ce que quelqu’un a testé cela uniquement avec le clavier ? »
    • « Est-ce que cela a été testé à différentes tailles d’écran ? »
    • (Réponse habituelle : silence.)
• Les retours clients :
  • « Personne ne s’est plaint, donc ça doit marcher. » → Faux.
    • Les personnes en situation de handicap ne se plaignent pas toujours :
      • Parce que les méthodes de feedback ne sont pas accessibles (formulaires, numéros de téléphone, chatbots).
      • Parce qu’elles ont peur des représailles (licenciement, discrimination).
      • Parce qu’elles travaillent plus dur et plus longtemps sans rien dire.

2. La menace des poursuites judiciaires

• Beaucoup pensent que la peur des poursuites suffira à rendre les produits accessibles.
• Réalité :
  • Les accords à l’amiable incluent souvent des clauses de confidentialité.
  • Même dans des entreprises ayant fait l’objet de poursuites publiques pour accessibilité, il reste difficile de rendre les produits accessibles.

Conclusion : Si on ne résout que pour les personnes qu’on peut compter, on exclut systématiquement celles qu’on ne peut pas compter.## Comment résoudre pour les extrêmes ?

1. Poser la bonne question : « Qui excluons-nous ? »

• Vous ne connaîtrez peut-être pas la réponse tout de suite, mais poser la question est la première étape.
• Ne pas paniquer : La solution n’est pas de créer des versions différentes pour chaque type de handicap.
• Solution : Penser à la personnalisation et à la variabilité, comme l’a fait l’US Air Force avec les cockpits.### 2. Facteurs à considérer en design et développement

A. Méthodes d’entrée (input)

• Tout le monde n’utilise pas uniquement la souris.
  • Clavier,
  • Tactile,
  • Voix,
  • Suivi oculaire (eye tracking),
  • Agents (IA).
• À éviter :
  • Tout rendre interactif par défaut (ex. : éléments cachés derrière des hover).
    • Problème : Cela peut créer des centaines d’éléments focusables et de tabulations inutiles.
  • Le drag and drop n’est pas toujours nécessaire.

B. Visibilité

• Certaines personnes préfèrent :
  • Un texte plus grand ou plus petit,
  • Des couleurs à fort contraste (ou non),
  • Des polices plus lisibles.
• Alternatives textuelles :
  • Descriptions d’images,
  • Transcriptions audio,
  • Sous-titres.

C. Cognition

• Simplifier le design :
  • Réduire le nombre d’étapes,
  • Éviter les interfaces surchargées.
• Éviter les conventions brisées :
  • « Ne faites pas réfléchir les gens. » (principe de Steve Krug).
• Attention aux animations :
  • Certaines peuvent provoquer des maux de tête (ex. : épilepsie photosensible).
  • D’autres peuvent distraire (ex. : TDAH).

D. Audition

• Ne pas se fier uniquement aux notifications sonores :
  • Certaines personnes ne les entendent pas.
  • D’autres peuvent être dérangées (ex. : notifications Slack).
• Alternatives :
  • Sous-titres,
  • Transcriptions,
  • Notifications visuelles.### 3. Solutions concrètes : les Media Queries CSS pour la personnalisation Les media queries permettent d’appliquer des styles conditionnellement, en fonction :
• Des caractéristiques de l’appareil (responsive design),
• Des préférences utilisateur ou paramètres système.

A. Media Queries multiplateformes

| Media Query | Description | Utilité | |-||| | prefers-color-scheme | Détecte la préférence pour le mode sombre. | Utile pour les personnes sensibles à la lumière ou qui passent beaucoup de temps devant un écran. Économise aussi la batterie. | | prefers-reduced-motion | Détecte la préférence pour réduire les animations non essentielles. | Évite les problèmes pour les personnes sensibles aux mouvements (ex. : vertiges, TDAH). | | prefers-contrast | Détecte la préférence pour un contraste élevé ou faible. | Utile pour les personnes malvoyantes ou sensibles à la lumière. (Disponible sur macOS/iOS, mais pas de préférence pour un contraste faible.) | | forced-colors | Détecte si l’utilisateur utilise un thème de couleurs forcé (ex. : mode haute contraste sur Windows). | Permet des ajustements mineurs (arrière-plans, bordures). Ne pas redéfinir les couleurs du système ! | | inverted-colors | Détecte la préférence pour inverser les couleurs. | Utile pour certaines formes de basse vision. (Support limité : Safari sur macOS/iOS en 2026.) |

B. Media Queries expérimentales

| Media Query | Description | Support (2026) | |-||-| | prefers-reduced-transparency | Réduit les effets de transparence/opacité. | Chrome, Edge (basé sur Blink). Dépend aussi des paramètres système (Windows, macOS, iOS). |

C. Personnalisation de base (sans media query)

• Taille de la police :
  • Utiliser des unités relatives (em, rem, %) ou des tailles nommées (xx-small à xx-large).
  • Respecte les préférences de l’utilisateur dans les paramètres du navigateur.### 4. Exemples de personnalisations utiles (à implémenter) | Personnalisation | Description | Pourquoi ? | |||| | Raccourcis clavier | Permettre de les activer/désactiver. | Les designers aiment les raccourcis, mais tout le monde n’en a pas besoin. | | Soulignement des liens | Option pour les désactiver (mais activés par défaut). | Les designers trouvent souvent les soulignements moches, mais ils sont essentiels pour l’accessibilité. | | Densité de l’interface | Permettre de choisir entre haute, moyenne, faible densité. | Certaines personnes préfèrent plus d’espace, d’autres plus d’informations à l’écran. | | Cartes au survol (hover cards) | Option pour les désactiver. | Évite la surcharge visuelle (ex. : GitHub le propose). |### 5. Personnalisations à éviter | Personnalisation | Pourquoi ? | ||| | Thèmes pour le daltonisme | Le daltonisme couvre un spectre de couleurs. Impossible de choisir les bonnes valeurs pour tout le monde. Solution : Ne pas se fier uniquement à la couleur pour transmettre une information. | | Mode lecteur d’écran | Les lecteurs d’écran sont déjà des technologies d’assistance. Ne pas réinventer la roue : suivez les standards et laissez les utilisateurs configurer leurs propres outils. | | Mettre l’accessibilité de base derrière des paramètres | Exemples : | | | - Contraste minimum : Doit être respecté par défaut. | | | - Soulignement des liens : Doit être activé par défaut. | | | - Support des lecteurs d’écran : Ne doit jamais être désactivable. |

6. Optimisations de base à appliquer par défaut

A. Couleur

• Choisir des couleurs accessibles :
  • Exemple : Meta (Facebook) utilise du bleu parce que Mark Zuckerberg est deutéranope (daltonisme rouge-vert). Le bleu est la couleur qu’il distingue le mieux.
• Contraste :
  • Vérifier que le texte est lisible sur le fond (outils : WebAIM Contrast Checker ).
• Ne pas utiliser la couleur seule pour transmettre une information :
  • Exemple : Rouge = erreur, Vert = succès → Ajouter du texte ou des icônes.

B. Langage

• Utiliser un langage simple :
  • Adapté à différents niveaux de lecture et de compréhension.
  • Penser à l’internationalisation (même si vous ne traduisez pas tout de suite, prévoyez une architecture multilingue).
• Éviter les champs inutiles dans les formulaires :
  • Genre, âge, préfixe (ex. : “M.”/“Mme”) → Inutiles dans la plupart des cas.
  • Si nécessaire, permettre de les modifier (ces informations peuvent changer).

C. Interfaces tactiles

• Taille des cibles tactiles :
  • Minimum 48x48 pixels (recommandation WCAG).
  • Doivent ressembler à des éléments interactifs.
• Éviter les gestes complexes :
  • Exemple : Des mouvements de main dignes d’un magicien.
• Ne pas imposer de délais :
  • Éviter les actions à compléter dans un temps limité.
• Toujours fournir des alternatives :
  • Un simple tap ou swipe doit suffire.

D. Interfaces vocales

• Reconnaître différents accents et schémas de parole :
  • Exemple : Siri ne reconnaît pas l’accent mexicain de la mère de Gerard.
• Utiliser des commandes courtes et faciles à retenir :
  • Exemple : « Timer 15 minutes » au lieu de « Régler un minuteur à 15 minutes ».
• Toujours fournir des alternatives :
  • Accepter les commandes textuelles en plus de la voix.

E. Reconnaissance faciale

• Problèmes récurrents :
  • Biais algorithmiques (ex. : distributeurs de papier toilette ne reconnaissant que les mains claires, technologies de scan oculaire ne reconnaissant pas les visages asiatiques).
  • Variations : Lumière, barbe, angle du visage.
• Toujours fournir des alternatives :
  • Exemple : Pendant le COVID, les masques ont rendu la reconnaissance faciale inefficace → Heureusement qu’il y avait d’autres méthodes de déverrouillage (code PIN, empreinte digitale).

7. Embaucher correctement : la diversité comme solution

• Problème : Si tout le monde dans une pièce vous ressemble ou vient du même milieu, quelque chose ne va pas.
• Solution :
  • Ne pas embaucher pour “s’intégrer à la culture” → Élargir la culture.
  • Représentation = meilleure conception :
    • « Rien ne se fait sans représentation. »
    • « Nous ne voulons pas faire des choses POUR les humains, mais AVEC les humains. »
• Bénéfice : Travailler avec des vrais humains (y compris en situation de handicap) élargit votre sphère de conscience et vous rapproche des “extrêmes”.## Conclusion : Résoudre pour les extrêmes, c’est résoudre pour tous
• Le but n’est pas de viser la moyenne → La moyenne n’existe pas.
• Le but est de gérer les extrêmes → C’est là que vivent les vrais humains.
• Comment ?
  • Poser la question : « Qui excluons-nous ? »
  • Penser variabilité : Offrir des options (comme les cockpits réglables).
  • Travailler avec des humains : Représentation et diversité dans les équipes.
  • Suivre les standards : WCAG, ARIA, etc.
  • Tester avec de vrais utilisateurs : Y compris des personnes en situation de handicap.Citation finale de Gerard :

« Nous ne voulons pas juste faire des choses pour les humains. Nous voulons faire des choses AVEC les humains. »## Questions/Réponses avec Gerard K. Cohen

1. Comment es-tu entré dans l’accessibilité numérique ?

• Parcours : J’ai toujours été passionné par la technologie (matériel, logiciel, réseaux), mais j’ai gravité vers le front-end car c’était plus fun de partager cette expérience avec les utilisateurs.
• Déclic :
  • Je pensais déjà faire de l’accessibilité en suivant les standards du web (grâce à Jeffrey Zeldman).
  • Un jour, dans un nouveau job, un collègue de l’équipe design (Kevin Kalahiki) m’a demandé : « Connais-tu ARIA ? » → Je ne savais pas de quoi il parlait.
  • J’ai pris cela comme un défi et suis devenu la personne référente en accessibilité dans mon équipe.
• Moment clé :
  • Lors d’un événement pour la Journée mondiale de sensibilisation à l’accessibilité, j’ai vu des vidéos de personnes utilisant nos logiciels et les difficultés qu’elles rencontraient.
  • J’ai réalisé que mon travail avait un impact énorme sur leur vie quotidienne.
  • Depuis, c’est devenu une passion : permettre aux gens de travailler, vivre indépendamment et subvenir à leurs besoins.

2. D’où vient l’idée de cette conférence ?

• Motivation personnelle :
  • Il y a beaucoup d’informations sur la technique (sémantique, ARIA, etc.), mais l’accessibilité, c’est beaucoup plus que ça.
  • En vieillissant, j’ai réalisé que c’est une question humaine : il y a tellement de façons différentes d’interagir avec le monde.
• Objectif :
  • Élargir la conscience des développeurs et designers.
  • Penser différemment : le monde change (navigateurs, technologies d’assistance, interfaces), et nous devons nous adapter.
  • Aller plus loin que le code : comprendre les besoins humains.

3. Par où commencer pour apprendre le design accessible ?

• Ressources :
  • Réseaux sociaux : Suivre des designers spécialisés en accessibilité (pas juste des designers qui font parfois de l’accessibilité).
    • Exemple : Chercher des experts en accessibilité qui conçoivent (ex. : Adrian Roselli , Sara Soueidan ).
  • Rencontres et conférences :
    • En ligne : Beaucoup d’événements gratuits (ex. : A11y Talks , Accessibility Camp ).
    • En personne : Meilleur moyen de rencontrer des personnes en situation de handicap et de voir comment elles interagissent avec le web.
• Conseil clé :

  « Parlez à de vrais humains. Travaillez avec des personnes en situation de handicap. »

4. Quel est le message principal à retenir de cette conférence ?

• Message 1 : « Vous n’êtes pas vos utilisateurs. » (cliché, mais vrai).
• Message 2 :
  • Les données peuvent être trompeuses :
    • Elles ne montrent souvent que ce qui fonctionne, pas ce qui échoue.
    • Creuser les données : « Qui ? Quoi ? Où ? Pourquoi ? »
• Message 3 :
  • L’accessibilité, c’est une question de design, pas juste de technique.
  • Penser aux extrêmes = améliorer l’expérience pour tous.## Clôture par Aubrey Sambor
• Remerciements à Gerard pour cette conférence exceptionnelle.
• Points marquants :
  • La suppression des exigences de taille pour les pilotes de chasse en 2022 (une révélation pour beaucoup).
  • L’importance de poser des questions et de remettre en cause les données.
• Appel à l’action :
  • Rejoignez la conversation sur LinkedIn : linkedin.com/company/A11YTALKS .
  • Devenez intervenant : A11y Talks cherche toujours de nouvelles voix, surtout issues de groupes marginalisés dans la tech.
    • Contact : team@a11ytalks.com ou via le site web .
  • Abonnez-vous à la chaîne YouTube pour ne manquer aucune conférence.
  • Suivez-nous sur LinkedIn, Bluesky et Mastodon.

« Merci d’avoir été là. À la prochaine ! »