Une meilleure UX pour les outils web adaptatifs

Les outils de l’interaction

Pour les personnes qui dépendent d’outils web adaptatifs pour naviguer sur Internet, la manière dont le contenu est construit et présenté est primordiale. La technologie d’assistance la plus sophistiquée au monde ne peut ni lire, ni annoncer, ni manipuler un contenu qui n’existe pas sous une forme accessible. Un bouton qui n’est en réalité qu’une <div> stylisée, une image sans alternative textuelle ou une liste déroulante personnalisée sans prise en charge du clavier est tout simplement invisible — ou pire, une impasse — pour les personnes qui dépendent de ces outils chaque jour.

QualiBooth vous aide à comprendre deux choses à la fois : comment les outils d’un utilisateur interprètent réellement votre contenu, et quel contenu ou quelle structure est manquant, défaillant ou ambigu. C’est cette combinaison qui distingue un site qui se charge techniquement d’un site qui fonctionne véritablement pour tout le monde.

Ce guide passe en revue les principales catégories de technologies d’assistance et adaptatives, la manière dont chacune attend qu’un site se comporte, et les étapes concrètes que vous pouvez suivre pour concevoir avec ces outils plutôt que contre eux. Il établit aussi une distinction claire entre les véritables technologies d’assistance et les overlays d’accessibilité — car les deux sont souvent confondus, et cette confusion a de réelles conséquences pour de vrais utilisateurs.

Ce que signifient réellement les « outils web adaptatifs »

Les outils web adaptatifs — plus couramment appelés technologies d’assistance (TA) — sont des logiciels et des matériels qui modifient la façon dont une personne perçoit ou utilise une interface numérique. Ce ne sont pas des modules complémentaires de votre site ; ils constituent l’environnement propre à l’utilisateur, configuré selon ses besoins et souvent utilisé pendant des heures chaque jour sur des milliers de sites.

Les principales catégories comprennent :

Les lecteurs d’écran qui convertissent le contenu affiché en parole synthétisée ou en braille rafraîchissable.
L’agrandissement d’écran qui agrandit et réorganise une partie ou la totalité de l’affichage.
Les dispositifs d’accès par contacteur pour les personnes qui ne peuvent pas utiliser un clavier ou une souris standard.
Le contrôle vocal qui pilote entièrement l’interface par commande orale.
Les fonctionnalités intégrées au navigateur et au système d’exploitation telles que les modes à contraste élevé, le mouvement réduit et les outils de lecture.
Les aides à la lecture et à la compréhension qui simplifient, narrent ou restructurent le texte.

Chacun de ces outils repose sur le même socle : une page bien structurée, sémantique et utilisable au clavier, qui respecte les standards établis. Lorsque vous construisez selon WCAG 2.2, vous établissez le contrat dont chacun de ces outils dépend.

Lecteurs d’écran : la structure est l’interface

Les lecteurs d’écran sont la technologie d’assistance la plus connue et, pour beaucoup d’équipes, la plus difficile à concevoir — précisément parce que la mise en page visuelle que vous voyez ne vous dit presque rien de ce qu’un lecteur d’écran annonce.

Les lecteurs d’écran les plus utilisés sont NVDA et JAWS sous Windows, VoiceOver sous macOS et iOS, et TalkBack sous Android. Ils ne « voient » pas votre page ; ils construisent un modèle à partir de l’arbre d’accessibilité, lui-même dérivé de la sémantique de votre HTML et de tout ARIA que vous y ajoutez.

Ce dont les lecteurs d’écran ont besoin de votre part

De véritables éléments sémantiques. Utilisez <button>, <a>, <nav>, <main>, <h1>–<h6> et <table> pour ce qu’ils sont. Un titre doit être un titre pour que les utilisateurs puissent passer d’une section à l’autre ; un lien doit être un lien pour qu’il apparaisse dans la liste des liens.
Des alternatives textuelles pertinentes. Chaque image informative a besoin d’un attribut alt qui décrit son objet. Les images décoratives doivent avoir un alt="" vide afin d’être ignorées plutôt qu’annoncées comme du bruit.
Des étiquettes programmatiques pour les contrôles. Les champs de formulaire ont besoin d’éléments <label> associés ; les boutons composés uniquement d’une icône ont besoin d’un nom accessible via aria-label ou un texte masqué visuellement.
Une hiérarchie de titres logique. Les titres sont le principal moyen pour les utilisateurs de lecteurs d’écran de parcourir une page. Sauter des niveaux ou utiliser des titres uniquement pour leur taille visuelle casse cette navigation.
Un ARIA correct — et uniquement lorsque nécessaire. ARIA peut communiquer des états (déplié, sélectionné, désactivé) et des rôles pour des widgets personnalisés, mais un mauvais ARIA est pire que pas d’ARIA du tout. La première règle d’ARIA est d’utiliser le HTML natif chaque fois que c’est possible.

Une confusion fréquente concerne la différence entre un lecteur d’écran et une simple synthèse vocale. Un outil de lecture narre du texte ; un lecteur d’écran expose et manipule l’interface entière, y compris les contrôles, les états et la navigation. Nous abordons cette distinction en détail dans synthèse vocale versus lecteurs d’écran.

Comme les outils automatisés ne peuvent détecter qu’une fraction des problèmes liés aux lecteurs d’écran, le seul moyen fiable de savoir comment votre site sonne est de le tester comme le font les utilisateurs. Notre guide de test avec lecteur d’écran décrit le flux de travail concret, et une évaluation par lecteur d’écran dédiée fait passer vos parcours les plus importants par ce processus avec des testeurs expérimentés.

Agrandissement d’écran : concevoir pour la vue zoomée

Les personnes malvoyantes agrandissent souvent l’écran de 200 % à 800 % ou plus, ne visualisant qu’une petite portion de la page à la fois. Certaines utilisent la loupe du système d’exploitation ; d’autres s’appuient sur le zoom du navigateur ou sur un logiciel spécialisé.

À fort grossissement, des choix de mise en page auxquels vous ne pensez jamais deviennent critiques :

La réorganisation (reflow). Le contenu doit se réorganiser en une seule colonne à un zoom de 400 % (critère de succès WCAG 2.2 1.4.10) afin que les utilisateurs n’aient pas à défiler dans deux directions pour lire une phrase.
La proximité des éléments liés. Si un message d’erreur apparaît loin du champ qu’il décrit, un utilisateur en mode agrandi risque de ne jamais les voir dans la même fenêtre d’affichage. Gardez les étiquettes, les champs et les retours d’information ensemble.
Un focus visible. Un indicateur de focus clair et à fort contraste permet à un utilisateur en mode agrandi de retrouver sa position après un saut de la vue.
Aucune perte de contenu ni de fonction. Rien ne doit être tronqué, chevauché ou rendu inutilisable lorsque le texte est agrandi jusqu’à 200 % (critère de succès 1.4.4).

L’agrandissement récompense les mises en page épurées et adaptatives et pénalise les conceptions en pixels fixes et le contenu qui dépend du survol.

Accès par contacteur et utilisabilité au clavier

Les dispositifs à contacteur permettent aux personnes d’utiliser un ordinateur avec une ou deux entrées simples — un bouton, un dispositif à souffle ou un mouvement de la tête — généralement en balayant les éléments interactifs un par un. L’accès par contacteur repose sur la prise en charge du clavier : si votre site fonctionne entièrement au clavier, il fonctionne presque certainement aussi avec des contacteurs.

C’est ce qui fait de la pleine utilisabilité au clavier l’un des éléments les plus rentables à réussir :

Tout doit être atteignable. Chaque élément interactif doit pouvoir recevoir le focus et être manipulable sans souris — liens, boutons, contrôles de formulaire, menus, fenêtres modales, carrousels et widgets personnalisés.
Un ordre de focus visible et logique. Le focus doit se déplacer dans la page selon un ordre correspondant au flux visuel et de lecture, et l’élément ayant le focus doit toujours être clairement indiqué.
Aucun piège au clavier. Les utilisateurs doivent pouvoir déplacer le focus hors de tout composant, y compris les médias intégrés et les boîtes de dialogue.
Liens d’évitement. Un lien « aller au contenu principal » permet aux personnes de contourner la navigation répétée au lieu de la parcourir sur chaque page.

Si un client remplit un formulaire, peut-il tabuler à travers chaque champ, déclencher une liste déroulante, choisir un produit et valider — le tout sans toucher une souris ? Le remplissage automatique du navigateur coopérera-t-il avec votre balisage ? Ce sont les questions auxquelles les utilisateurs de contacteurs et de clavier répondent à propos de votre site, que vous les posiez ou non.

Contrôle vocal : les noms et les étiquettes visibles comptent

Les outils de contrôle vocal tels que Dragon, Voice Control et Voice Access permettent aux utilisateurs de prononcer des commandes comme « cliquer sur Envoyer » ou « défiler vers le bas ». Pour que ces commandes fonctionnent, l’étiquette visible d’un contrôle doit correspondre à son nom accessible. C’est la base du critère de succès WCAG 2.2 2.5.3, Étiquette dans le nom.

Conseils pratiques :

Le nom accessible doit contenir le texte visible. Si un bouton affiche « Envoyer le message », ne lui donnez pas un aria-label de « Soumettre le formulaire » — l’utilisateur qui dit « cliquer sur Envoyer le message » sera ignoré.
Évitez les contrôles composés uniquement d’une icône sans texte, ou donnez-leur un nom accessible correspondant à une commande vocale probable.
Gardez les cibles cliquables suffisamment grandes pour être sélectionnées de manière fiable, ce qui satisfait également au critère de taille des cibles de WCAG 2.2.

Fonctionnalités d’accessibilité du navigateur et du système d’exploitation

Tous les outils adaptatifs ne sont pas des produits distincts. Les navigateurs et systèmes d’exploitation modernes intègrent de puissantes fonctionnalités que les utilisateurs activent à l’échelle du système, et votre site devrait les respecter automatiquement :

Mouvement réduit. Respectez la requête média prefers-reduced-motion pour désactiver ou atténuer les animations pour les utilisateurs gênés par les nausées ou la distraction liées au mouvement.
Mode sombre et contraste élevé. Prenez en charge prefers-color-scheme ainsi que le mode contraste élevé / couleurs forcées de Windows afin que votre interface reste lisible sans lutter contre les réglages de l’utilisateur.
Redimensionnement du texte et zoom. Utilisez des unités relatives pour que la mise à l’échelle du texte du navigateur fonctionne, plutôt que de figer les tailles en pixels.
Modes lecture et outils de lecture. Les vues de lecture des navigateurs et des outils comme Immersive Reader réduisent une page à son contenu essentiel — ce qui fonctionne bien mieux lorsque votre HTML est sémantique et exempt d’encombrement.

Ces fonctionnalités ne coûtent rien de plus à l’utilisateur et très peu à vous, et pourtant elles améliorent considérablement le confort d’un large public, y compris des personnes sans handicap diagnostiqué.

Outils de lecture et de compréhension

Les outils de lecture servent les personnes dyslexiques, atteintes de TDAH, présentant des handicaps cognitifs ou ayant une maîtrise limitée de la langue de la page. Ils comprennent les narrateurs de synthèse vocale, les règles de lecture, la surbrillance des mots, les outils de résumé et les outils de traduction.

Pour bien fonctionner avec eux :

Rédigez dans une langue claire et bien organisée, avec des titres descriptifs et des paragraphes courts.
Balisez la page de sorte que le contenu principal soit clairement identifiable et que l’ordre de lecture soit correct.
Évitez de transmettre du sens uniquement par la couleur, la mise en page ou les images — fournissez un équivalent textuel.
Assurez-vous que votre langue est déclarée (attribut lang) afin que la narration et la traduction utilisent la prononciation et les règles appropriées.

Une bonne structure de contenu aide à la fois tous les outils de cet article, car ils s’appuient tous sur le même balisage sous-jacent.

Véritables technologies d’assistance vs overlays d’accessibilité

C’est la distinction qui compte le plus, et c’est là que de nombreuses organisations se trompent.

Les véritables technologies d’assistance — lecteurs d’écran, loupes, accès par contacteur, contrôle vocal — fonctionnent sur l’appareil de l’utilisateur, sous son contrôle, et manipulent votre site grâce à sa sémantique et à sa prise en charge du clavier. L’utilisateur a passé des années à les configurer. Votre rôle se résume à construire une page que ces outils peuvent comprendre.

Les overlays d’accessibilité sont des scripts tiers que vous ajoutez à votre propre site et qui promettent de le « rendre accessible » automatiquement, généralement via un widget flottant. Ils ne remplacent pas les technologies d’assistance, et ils ne corrigent pas un site inaccessible. Voici pourquoi :

Ils ne peuvent pas réparer le code sous-jacent. Les overlays se superposent à la page ; ils ne peuvent pas inventer de manière fiable un texte alternatif manquant, corriger des structures de titres défaillantes ou faire en sorte qu’une <div> se comporte comme un véritable bouton sur tous les lecteurs d’écran.
Ils entrent souvent en conflit avec les vraies TA. De nombreux utilisateurs de lecteurs d’écran signalent que les overlays interfèrent avec les outils sur lesquels ils s’appuient déjà, rendant parfois les sites plus difficiles à utiliser, et non plus faciles.
Ils créent un faux sentiment de conformité. Installer un widget ne satisfait pas à WCAG 2.2, à l’EAA ni à l’ADA. Des poursuites ont été engagées contre des sites utilisant des overlays précisément parce que les barrières sous-jacentes subsistaient.
Ils ne reflètent pas l’expérience vécue. L’accessibilité est en fin de compte jugée par les personnes qui utilisent des TA chaque jour — c’est pourquoi nous réalisons des audits par des personnes en situation de handicap plutôt que de nous fier aux affirmations d’un script.

La voie fiable consiste à corriger l’accessibilité dans le code et à la valider par des tests à la fois automatisés et humains. Nous expliquons cette philosophie plus en détail dans ce qu’est la véritable accessibilité numérique.

Un flux de travail concret pour construire avec des outils adaptatifs

Concevoir pour les technologies d’assistance n’est pas un projet ponctuel ; c’est un processus qui s’intègre à votre façon de livrer déjà des logiciels. Une approche durable combine généralement quatre éléments :

Une analyse automatisée, tôt et souvent. Des outils comme un logiciel d’analyse d’accessibilité détectent un grand volume de problèmes au niveau du code — étiquettes manquantes, échecs de contraste, ARIA défaillant — avant qu’ils n’atteignent la production. Les vérifications automatisées sont rapides et reproductibles, mais elles ne couvrent qu’une partie du tableau.
Des tests manuels et avec technologie d’assistance. Les problèmes qui affectent le plus les vrais utilisateurs — un ordre de focus déroutant, des annonces peu claires, des widgets personnalisés inutilisables — nécessitent un humain. Notre guide des audits manuels d’accessibilité décrit comment cela complète l’automatisation.
L’intégration de l’accessibilité dans votre équipe. Traiter l’accessibilité comme une discipline continue, soutenue par l’amélioration des processus d’accessibilité, prévient la lente régression qui survient lorsque les corrections sont ponctuelles.
Les bons outils pour votre stack. La boîte à outils d’accessibilité de QualiBooth réunit l’analyse, la surveillance et le reporting, tandis qu’Agora et notre édition communautaire offrent des points d’entrée aux équipes à différents stades de maturité.

Si la terminologie de cet article vous est nouvelle, le glossaire de l’accessibilité est un compagnon utile à mesure que vous mettez ces pratiques en place.

Où QualiBooth s’inscrit

QualiBooth identifie les problèmes sur votre site existant et peut aussi analyser les pages avant leur mise en ligne, afin que les clients utilisant n’importe quel outil adaptatif bénéficient d’une expérience fluide qui renforce l’utilisabilité et la fidélité à la marque. Nous combinons la détection automatisée avec une évaluation par des testeurs expérimentés et des personnes en situation de handicap, puis nous aidons votre équipe à transformer les constats en corrections durables — jamais un overlay qui masque le problème.

L’objectif est simple : un site qui fonctionne avec les outils auxquels vos utilisateurs font déjà confiance, selon leurs conditions, à chaque visite.

Prêt à voir comment votre site se comporte face à de vraies technologies d’assistance ? Lancez une analyse d’accessibilité gratuite pour repérer des gains rapides, demandez une démo pour voir QualiBooth en action, ou parlez à notre équipe d’une mission de conseil en accessibilité sur mesure.