par Un bouton peut être parfaitement visible et rester impossible à identifier avec une synthèse vocale. Un formulaire peut sembler simple tout en cachant ses messages d’erreur aux personnes qui ne voient pas l’écran. Avant de publier un site, vérifier son apparence ne suffit donc pas : il faut aussi contrôler ce que ses composants annoncent, leur ordre de lecture et leur fonctionnement sans souris. Les analyses automatiques repèrent certaines anomalies, mais elles ne déterminent pas si une personne peut réellement trouver un produit, comprendre une offre ou terminer une inscription.
La vérification de la compatibilité avec les lecteurs d’écran repose sur des scénarios concrets, plusieurs environnements techniques et une observation attentive des obstacles rencontrés. Prenons le cas d’Atelier Rivage, une boutique fictive qui prépare son ouverture : son équipe doit rendre le catalogue, le panier et le paiement utilisables avant d’accueillir ses premiers clients. Son parcours montre comment associer contrôles techniques, essais manuels et retours de personnes concernées. L’objectif n’est pas d’obtenir une page silencieuse dans un rapport d’erreurs, mais de permettre à chacun d’accomplir une tâche sans dépendre d’une aide extérieure.
1. Préparer les tests avant mise en ligne avec les bons lecteurs d’écran
Un lecteur d’écran restitue les informations exposées par le navigateur sous forme vocale ou sur une plage braille. Il ne se contente pas de lire le texte visible : il communique aussi le rôle des composants, leur nom, leur état et leurs relations avec les autres éléments.
Un bouton peut ainsi être annoncé comme « Ajouter au panier, bouton », tandis qu’un accordéon précise si son contenu est développé ou replié. Lorsque ces informations manquent, l’utilisateur doit deviner le fonctionnement de l’interface, même si son apparence semble parfaitement explicite.
Choisir les associations navigateur et technologie d’assistance
La compatibilité dépend de toute une chaîne : système d’exploitation, navigateur, technologie d’assistance et code de la page. Un résultat satisfaisant sur une seule configuration ne prouve pas que les autres produisent une expérience équivalente.
Atelier Rivage commence par deux environnements de bureau et un téléphone réellement disponible dans l’équipe. Ce choix constitue une base de travail, à compléter selon les usages du public, les contrats applicables et les incidents déjà signalés.
| Environnement | Association à tester | Points à observer |
|---|---|---|
| Windows | NVDA avec Firefox ou Chrome | Lecture structurée, formulaires et composants interactifs |
| macOS | VoiceOver avec Safari | Repères, navigation au rotor et restitution des états |
| iPhone | VoiceOver avec Safari | Exploration tactile, gestes et parcours mobile |
| Android | TalkBack avec Chrome | Ordre de balayage, activation et annonces dynamiques |
Le Narrateur intégré à Windows peut également compléter les vérifications. Pour rendre les résultats reproductibles, consignez les versions utilisées et les réglages particuliers plutôt que de noter simplement « testé sur ordinateur ».
Définir des scénarios d’accessibilité web représentatifs
Tester uniquement la page d’accueil laisse de nombreux risques dans l’ombre. Les difficultés se concentrent souvent dans les étapes comportant plusieurs actions : sélectionner une variante, modifier une quantité, corriger une adresse ou confirmer une réservation.
L’équipe prépare des comptes et des données fictives sur une préproduction proche de la future version publique. Les services externes, notamment le paiement, doivent proposer un environnement d’essai afin de parcourir les étapes sans effectuer de transaction réelle.
- Explorer : trouver une catégorie, parcourir ses titres et ouvrir une fiche produit.
- Choisir : sélectionner une taille, connaître sa disponibilité et ajouter l’article au panier.
- Corriger : provoquer une erreur de saisie puis comprendre comment la résoudre.
- Confirmer : terminer la commande et retrouver son récapitulatif.
- Se repérer : revenir au contenu principal après avoir ouvert un menu ou une fenêtre modale.
Chaque scénario possède un résultat attendu observable. « Le paiement fonctionne » reste trop vague ; « la personne identifie les champs obligatoires, corrige son code postal et entend la confirmation » permet de trancher.
Prévoyez aussi des états moins favorables : panier vide, produit indisponible, session expirée et recherche sans résultat. Ces situations révèlent fréquemment des informations affichées visuellement, mais absentes de la restitution vocale.
Enfin, définissez le référentiel de l’audit d’accessibilité, par exemple les WCAG 2.2 et, lorsque le contexte l’exige, le RGAA applicable. Un protocole utile décrit des tâches, des environnements et des critères de réussite ; il ne se limite pas à une liste de pages ouvertes.
2. Vérifier la navigation au clavier et le déplacement du focus
La navigation au clavier constitue un premier contrôle indispensable, mais elle ne remplace pas un essai avec synthèse vocale. Elle permet de repérer les commandes inaccessibles à la touche Tab, les pièges de déplacement et les changements de contexte mal maîtrisés.
Commencez sans lecteur d’écran pour isoler les défauts du parcours. Reprenez ensuite les mêmes tâches avec celui-ci activé : ses commandes de lecture et ses modes d’interaction peuvent modifier la façon d’explorer la page.
Tester les commandes clavier des composants web
Mettez la souris de côté, puis utilisez Tab et Maj+Tab pour parcourir les éléments interactifs. Entrée active généralement les liens et les boutons ; Espace sert notamment aux boutons et aux cases à cocher, tandis que les flèches interviennent dans certains composants composites.
Un menu, un groupe d’onglets ou une liste de suggestions ne se teste donc pas uniquement en pressant Tab. Vérifiez le modèle d’interaction attendu pour chaque composant, en privilégiant les comportements natifs du navigateur lorsque cela est possible.
Chez Atelier Rivage, le sélecteur de quantité ressemble à deux petits boutons « moins » et « plus ». Le contrôle initial révèle pourtant que seuls des clics de souris ont été prévus : remplacer les éléments génériques par de véritables boutons rétablit leur activation standard et leur présence dans le parcours.
Contrôler l’ordre de tabulation et la visibilité du focus
L’ordre de déplacement doit suivre une progression compréhensible. Une mise en page CSS peut placer un encart à droite tout en le laissant très tôt dans le document : ce décalage devient gênant lorsque la sélection semble sauter d’une zone à l’autre.
Évitez de réparer ce problème avec des valeurs positives de tabindex, qui créent un ordre artificiel difficile à maintenir. Corrigez plutôt l’organisation du document et réservez les ajustements programmatiques aux interactions qui les nécessitent réellement.
Le repère visuel de sélection doit rester identifiable sur tous les arrière-plans. Il ne doit pas disparaître derrière un bandeau de consentement, un en-tête fixe ou une fenêtre superposée, faute de quoi une personne voyante utilisant le clavier perd sa position.
Le lien d’évitement vers le contenu principal mérite un essai dès le chargement. Sans ce raccourci, un visiteur peut devoir traverser une longue navigation à chaque nouvelle page avant d’atteindre l’information recherchée.
Éviter les pièges clavier dans les fenêtres modales
Ouvrez ensuite le panier dans sa fenêtre modale. Le focus doit rejoindre un emplacement pertinent dans cette fenêtre, rester dans son périmètre tant qu’elle est active, puis revenir logiquement au déclencheur après fermeture.
Le reste de la page ne doit pas rester accidentellement utilisable derrière le dialogue. Vérifiez également la présence d’une commande de fermeture accessible et le fonctionnement d’Échap lorsque ce comportement convient à l’interaction.
Pour examiner la restitution sans dépendre du regard, vous pouvez masquer temporairement l’affichage ou utiliser un rideau d’écran lorsque l’outil le permet. Cette pratique aide à découvrir des informations uniquement visuelles, mais elle ne reproduit ni l’expérience ni l’expertise d’une personne aveugle.
Notez séparément les difficultés d’apprentissage des commandes et les défauts du site. Un novice peut chercher longtemps une fonction pourtant accessible, tandis qu’un utilisateur expérimenté contournera parfois un problème réel sans le signaler spontanément.
Le bon critère est la maîtrise du parcours : chaque action doit être atteignable, compréhensible et réversible sans souris. Une fois les déplacements stabilisés, il devient possible d’évaluer précisément les informations annoncées à chaque étape.
3. Examiner la structure HTML, les images et les intitulés de liens
La structure HTML fournit une carte du contenu aux technologies d’assistance. Des titres correctement balisés, des régions identifiables et des listes véritables permettent d’explorer une page sans écouter chaque ligne dans l’ordre.
Un lecteur expérimenté peut consulter la liste des titres ou celle des liens pour rejoindre directement une information. Si les éléments visuellement importants ne possèdent aucune sémantique, ces raccourcis donnent une représentation appauvrie du document.
Vérifier les titres et les régions avec un lecteur d’écran
Affichez la liste des titres dans NVDA ou utilisez le rotor de VoiceOver. Vous devez comprendre l’organisation générale sans consulter la présentation graphique : catégorie, caractéristiques, livraison, avis et informations complémentaires doivent former un ensemble cohérent.
Les niveaux expriment une hiérarchie, pas une taille de police. Un saut de niveau mérite un examen, mais la question centrale reste la relation logique entre les contenus ; agrandir un paragraphe avec du CSS ne le transforme pas en titre.
Sur une fiche d’Atelier Rivage, « Livraison et retours » apparaît en caractères imposants, mais reste un simple paragraphe. Sa conversion en titre approprié permet aux visiteurs d’atteindre cette information depuis la navigation structurée, au lieu de parcourir toute la description.
Contrôlez également les régions de navigation et de contenu principal. Lorsque plusieurs zones ont le même rôle, un nom distinctif aide à différencier le menu des catégories de celui du compte client, sans multiplier inutilement les repères.
Le titre de la page et sa langue déclarée font aussi partie du contrôle. Le premier aide à identifier l’onglet et le contexte ; la seconde favorise une prononciation adaptée, notamment lorsque des passages utilisent une autre langue.
Rédiger des textes alternatifs selon la fonction des images
Une description utile dépend du contexte. Sur une fiche produit, elle peut préciser une forme ou un détail nécessaire au choix ; pour une illustration purement décorative, un attribut alt vide évite une annonce sans valeur ajoutée.
Un nom de fichier comme « photo_finale_08.jpg » n’explique rien. À l’inverse, répéter mot pour mot une légende déjà accessible peut alourdir l’écoute sans apporter d’information supplémentaire.
Les images servant de commande nécessitent une attention particulière : leur nom accessible doit exprimer l’action ou la destination. Pour une loupe ouvrant la recherche, « Rechercher » est plus utile que « icône de loupe ».
Un graphique complexe demande davantage qu’une courte alternative. Présentez les tendances essentielles dans le texte et proposez les données sous une forme exploitable, par exemple un tableau avec des en-têtes correctement associés.
Évaluer les liens et les attributs ARIA sans surcharger le code
Écoutez les liens hors de leur paragraphe. Une succession de « En savoir plus » ne permet pas toujours de distinguer les destinations ; « Consulter les conditions de livraison » rend immédiatement le choix plus clair.
Les attributs ARIA servent à exposer des informations qui ne sont pas suffisamment exprimées autrement. Ils ne remplacent ni les interactions clavier ni le comportement d’un contrôle natif : ajouter un rôle de bouton à un élément générique ne suffit pas à le rendre opérationnel.
Vérifiez aussi qu’un nom fourni par aria-label ne masque pas une formulation visible différente. Une divergence peut perturber les personnes qui alternent perception visuelle, synthèse et commande vocale.
La meilleure restitution commence par un document sémantique, puis ajoute seulement les informations nécessaires. Cette base doit ensuite résister aux saisies, aux erreurs et aux mises à jour de l’interface.
4. Tester les formulaires, les erreurs et les contenus dynamiques
Les formulaires concentrent plusieurs exigences : identifier ce qui est demandé, comprendre les contraintes, saisir une réponse et recevoir un retour exploitable. Une seule rupture peut empêcher une inscription ou un achat, même lorsque toutes les pages précédentes semblent accessibles.
Atelier Rivage teste donc son paiement avec des informations volontairement incorrectes. L’équipe ne cherche pas seulement à déclencher un message rouge : elle vérifie qu’une personne sait quelle donnée corriger et comment reprendre son parcours.
Associer les champs à des étiquettes accessibles
Chaque champ doit posséder un nom accessible explicite, généralement obtenu grâce à une étiquette visible correctement associée. Le texte indicatif placé à l’intérieur d’une zone de saisie ne constitue pas un remplacement satisfaisant : il disparaît pendant la frappe et peut laisser l’utilisateur sans repère.
Les instructions utiles doivent être disponibles avant l’erreur. Si un mot de passe impose une longueur minimale ou certains caractères, indiquez ces exigences à proximité et associez-les au contrôle, notamment avec aria-describedby lorsque nécessaire.
Les groupes de réponses demandent eux aussi un contexte commun. Pour choisir un mode de livraison parmi plusieurs boutons radio, une légende de groupe permet de comprendre la question à laquelle chaque proposition répond.
Testez les types de champs, l’autocomplétion et le caractère obligatoire des réponses. Le navigateur peut offrir une assistance précieuse, mais ses annonces doivent rester compréhensibles dans les configurations retenues et ne pas être contredites par les scripts.
Rendre les messages d’erreur repérables et actionnables
Une erreur ne doit pas reposer uniquement sur la couleur. « Valeur incorrecte » est rarement suffisant ; « Saisissez un code postal de cinq chiffres » explique ce qui est attendu lorsque cette règle correspond effectivement au pays sélectionné.
Après un envoi invalide, un récapitulatif placé à un endroit pertinent peut faciliter la correction. Ses liens doivent conduire aux champs concernés, tandis que les messages locaux restent associés aux contrôles, par exemple au moyen de aria-describedby.
L’état aria-invalid peut signaler une valeur rejetée, mais il ne fournit pas à lui seul l’explication nécessaire. Vérifiez ce qui est réellement annoncé en revenant dans le champ, puis confirmez que l’état d’erreur disparaît après une correction valide.
Conservez les données déjà saisies lorsque cela est approprié. Obliger une personne à recommencer intégralement son adresse après une faute mineure transforme un problème de validation en obstacle majeur.
Annoncer les changements sans interrompre inutilement
Lorsqu’un article rejoint le panier, une confirmation peut apparaître sans changement de page. Une région de statut, par exemple avec role= »status », permet d’annoncer ce résultat sans déplacer systématiquement le focus.
Les annonces urgentes doivent rester réservées aux situations qui le justifient. Une interface qui interrompt la lecture à chaque variation de quantité devient difficile à suivre, même si chacune de ses notifications est techniquement exposée.
Testez également les suggestions de recherche, les résultats filtrés et les étapes chargées de façon asynchrone. L’utilisateur doit connaître l’état de l’opération, retrouver ses repères et comprendre si son action a produit un résultat.
Dans une application monopage, un changement de vue mérite une gestion explicite du titre et du positionnement de lecture. Sans cela, le nouveau contenu peut être présent tandis que la personne demeure mentalement dans l’écran précédent.
Un formulaire accessible accompagne la correction autant que la réussite. Consignez donc les annonces entendues et les déplacements observés, plutôt que de valider seulement l’apparition visuelle des messages.
5. Croiser audit d’accessibilité, tests mobiles et validation de publication
Les contrôles manuels révèlent la compréhension et la continuité du parcours ; les outils automatiques repèrent rapidement certaines anomalies répétées. Les associer permet de couvrir davantage de situations, sans attribuer à l’un ce que seul l’autre peut vérifier.
Une extension comme axe DevTools ou WAVE peut signaler des problèmes détectables dans l’état affiché. Pour explorer plusieurs pages et suivre les évolutions, un dispositif de surveillance peut compléter ces contrôles, sous réserve de configurer correctement son périmètre et ses accès.
Interpréter les analyses automatiques sans fausse garantie
Un détecteur peut constater qu’une image possède un attribut alt, mais pas toujours déterminer si sa description aide réellement au choix d’un produit. Il peut également relever certaines absences de noms accessibles sans juger toute l’ambiguïté d’un intitulé dans son contexte.
Le Moniteur d’Accessibilité de Wawsome constitue l’une des solutions à examiner pour cette surveillance. Avant de le retenir, vérifiez les fonctionnalités actuellement proposées, la prise en charge des pages authentifiées, les fréquences d’analyse et les possibilités d’intégration au processus de développement.
Aucun service de ce type ne garantit à lui seul une conformité durable. Un rapport sans anomalie détectée signifie seulement que les règles exécutées n’ont rien relevé dans le périmètre effectivement analysé.
Atelier Rivage utilise les scans pour retrouver les défauts récurrents de ses modèles de pages. L’équipe conserve les essais humains pour juger les descriptions, l’ordre de compréhension et la réussite du paiement.
Distinguer responsive design et compatibilité avec les lecteurs d’écran
Un aperçu de téléphone dans un navigateur vérifie principalement la mise en page. Les outils de redimensionnement, qu’il s’agisse de Responsinator ou d’un mode adaptatif intégré, ne reproduisent pas toute l’interaction entre un appareil mobile et sa technologie d’assistance.
Sur un téléphone réel, explorez l’interface par balayage et au toucher. Vérifiez que le menu réduit conserve un nom pertinent, que son état est annoncé et que les éléments masqués ne restent pas accidentellement présents dans le parcours.
Le contraste des couleurs concerne particulièrement les personnes malvoyantes et celles qui combinent plusieurs modes de perception. Contrôlez aussi le zoom, les espacements et la redistribution du contenu : une synthèse correcte n’excuse pas des commandes devenues illisibles ou recouvertes.
Les tableaux larges, les vidéos et les bandeaux fixes doivent être examinés dans ces conditions. Le test d’optimisation mobile de Google, retiré en décembre 2023, ne constitue plus une solution disponible pour réaliser ces vérifications.
Documenter les corrections et prévenir les régressions
Chaque anomalie doit préciser la page, l’environnement, les étapes de reproduction, le résultat observé et le comportement attendu. Une courte capture sonore ou vidéo peut aider, à condition de ne pas exposer de données personnelles.
Classez les problèmes selon leur impact sur la tâche. Un bouton de paiement impossible à activer demande un traitement prioritaire ; une annonce inutile mais contournable reste à corriger sans recevoir automatiquement la même urgence.
Après réparation, rejouez le scénario dans la configuration qui révélait le défaut, puis sur une autre association pertinente. Ajoutez des contrôles de régression aux composants partagés : une modification du menu peut affecter toutes les pages simultanément.
Organisez enfin des sessions rémunérées avec des personnes utilisant habituellement ces technologies. Leur expérience permet de distinguer une interface simplement exploitable d’un parcours réellement efficace, sans leur faire porter la responsabilité exclusive de la validation.
La publication doit s’appuyer sur des preuves de tâches réussies et des risques documentés. Maintenez ensuite cette exigence lors des ajouts de contenu et des évolutions fonctionnelles, car une correction acquise peut disparaître au prochain déploiement.
Quel lecteur d’écran utiliser pour commencer les vérifications ?
Sur Windows, NVDA constitue un point de départ gratuit. Sur les appareils Apple, VoiceOver est intégré. Commencez avec un environnement que vous pouvez utiliser régulièrement, puis ajoutez une autre association navigateur et technologie d’assistance ainsi qu’un téléphone réel.
Un score automatique élevé prouve-t-il que le site est accessible ?
Non. Un score décrit seulement les règles exécutées et les pages ou états analysés. Il ne prouve pas qu’un visiteur comprend les intitulés, corrige une erreur ou termine un achat. Les scénarios manuels et les essais avec des personnes concernées restent nécessaires.
Faut-il ajouter des attributs ARIA à tous les composants ?
Non. Privilégiez les éléments HTML natifs correctement utilisés. ARIA complète les informations manquantes, mais ne crée pas les comportements clavier et peut dégrader la restitution lorsqu’il est mal employé. Vérifiez toujours le nom, le rôle et l’état effectivement annoncés.
Quels problèmes doivent bloquer une mise en ligne ?
Les obstacles empêchant une tâche essentielle demandent une correction prioritaire : commande inaccessible au clavier, fenêtre impossible à quitter, champ indispensable sans nom compréhensible ou erreur impossible à résoudre. La décision doit également tenir compte des exigences applicables et des autres non-conformités relevées.
À quelle fréquence refaire les essais après publication ?
Rejouez les parcours critiques après toute modification susceptible de les affecter, notamment les changements de navigation, de formulaire ou de composant partagé. Associez ces vérifications à des analyses automatisées régulières et à des sessions humaines planifiées selon le rythme des évolutions.
