Comment auditer l’accessibilité clavier et lecteur d’écran d’un widget WebChat

Auditer la page, le widget et la transition entre les deux

Un widget de chat ne fonctionne pas de manière isolée. Son lanceur se trouve dans une page hôte, tandis que la conversation ouverte peut s’afficher dans un panneau, une boîte de dialogue ou une autre interface. Testez l’expérience réellement intégrée : la page autour du lanceur, le widget lui-même et ce qui se passe lorsque les personnes y entrent ou en sortent.

Avant de commencer les tests, consignez l’URL de la page, la configuration du widget, le navigateur et le système d’exploitation, la technologie d’assistance ainsi que les états de l’interface concernés. Incluez le lanceur, le chat ouvert, tout formulaire préalable au chat, l’échange de messages, les erreurs de validation, l’état réduit et l’état fermé lorsque ces fonctionnalités sont présentes. Ne supposez pas que chaque widget utilise une boîte de dialogue modale : établissez d’abord le comportement de celui que vous testez.

• Périmètre : intégration à la page hôte, commandes du widget et états pertinents de la conversation.
• Échantillon : choisissez des pages et des parcours représentatifs, y compris un formulaire ou un état d’erreur s’il y en a un.
• Environnement : consignez le navigateur, le système d’exploitation, le lecteur d’écran et le mode de saisie.
• Responsabilités : notez les éléments gérés par l’équipe du site web, le fournisseur du widget ou le fournisseur du canal.

Préparer un petit plan de test reproductible

Combinez les tests au clavier uniquement et les tests avec lecteur d’écran. Les vérifications automatisées de l’accessibilité peuvent aider à repérer certains problèmes, mais elles ne permettent pas d’établir qu’un widget est accessible. Le WAI souligne qu’aucun outil d’évaluation unique ne permet de déterminer si un site respecte les normes d’accessibilité : une évaluation humaine menée par des personnes compétentes est nécessaire.

Choisissez un petit nombre de parcours utilisateur que votre équipe pourra répéter après chaque changement. Par exemple : ouvrir le widget, atteindre et remplir ses champs, envoyer un message, prendre connaissance d’une réponse, fermer le widget et poursuivre l’utilisation de la page. Effectuez ces étapes au clavier uniquement, puis reprenez le même parcours avec un lecteur d’écran.

• Utilisez Tab et Maj+Tab pour parcourir les commandes ; utilisez Entrée et Espace pour activer les boutons.
• Utilisez les commandes habituelles de lecture et de navigation dans les formulaires du lecteur d’écran pour vérifier les noms, les rôles, les instructions et les mises à jour.
• Lancez une analyse automatisée lorsque cela est pertinent, puis vérifiez manuellement ses résultats et testez les comportements qu’elle ne peut pas évaluer.
• Utilisez des données de test non sensibles ; évitez d’envoyer de véritables informations client pendant un audit.

Tester l’ouverture, la fermeture et le retour du focus

Repérez le lanceur sans utiliser de souris. Vérifiez qu’il possède un nom accessible pertinent, que son focus est visible et qu’il peut être activé avec Entrée ou Espace. Après l’ouverture du chat, déterminez où le focus se place et si cette destination indique clairement quelle est la prochaine action.

Si le chat se comporte comme une boîte de dialogue modale, comparez son comportement au clavier au modèle de boîte de dialogue modale des pratiques de création WAI-ARIA : le focus entre dans la boîte de dialogue, Tab et Maj+Tab y restent, Échap la ferme et le focus revient normalement à la commande qui l’a ouverte. N’appliquez ce modèle que si l’interface est réellement modale. Pour un panneau non modal, vérifiez que les utilisateurs peuvent passer du panneau à la page sans se retrouver piégés ni perdre leur place.

Fermez le chat au clavier, puis vérifiez que le focus revient à un emplacement logique — généralement le lanceur — et qu’il reste visible. Ouvrez-le de nouveau et vérifiez si l’état précédent de la conversation et le comportement du focus sont compréhensibles.

• Le lanceur et la commande de fermeture peuvent-ils être atteints et activés au clavier ?
• Le focus est-il visible avant et après l’ouverture, la fermeture et la réouverture ?
• Le focus se place-t-il sur un point de départ utile à l’ouverture du widget ?
• Les utilisateurs peuvent-ils quitter le widget sans pointeur ni piège de focus inattendu ?
• Après la fermeture, les utilisateurs peuvent-ils poursuivre depuis un emplacement logique de la page hôte ?

Vérifier l’ordre, les commandes et les instructions des formulaires

Parcourez au clavier le widget ouvert et les commandes voisines de la page. Le focus doit suivre un ordre qui préserve le sens et permet d’utiliser l’interface. Repérez tout déplacement du focus derrière une superposition, toute commande ignorée, toute entrée dans du contenu masqué ou toute sortie inattendue du widget. Vérifiez que chaque commande ayant le focus possède un indicateur de focus visible.

Inspectez les boutons, les liens, les champs et les autres composants interactifs avec un lecteur d’écran. Leurs noms et leurs rôles doivent expliquer ce qu’ils sont et quelle action ils déclenchent ; les changements d’état, comme développé, sélectionné ou désactivé, doivent être communiqués lorsque cela s’applique. Une icône visuelle seule ne fournit pas nécessairement un nom pertinent.

Pour chaque champ, vérifiez que les utilisateurs peuvent comprendre quelles informations sont attendues et que l’étiquette ou l’instruction est associée au champ par programmation lorsque cela est nécessaire. Testez aussi bien le parcours d’erreur que la saisie réussie : déclenchez une erreur de validation prévisible et sans risque, puis vérifiez que le champ en erreur et le problème sont indiqués sous forme de texte. Si une correction connue est appropriée, vérifiez que celle-ci est expliquée.

• Vérifiez l’ordre de navigation au clavier entre le lanceur, la conversation, le champ de message, la commande d’envoi et tout formulaire préalable au chat.
• Vérifiez que le focus est visible et qu’il se comporte de manière logique lorsque du contenu apparaît ou que l’état d’une commande change.
• À l’aide d’un lecteur d’écran, vérifiez les noms, les rôles et les états des commandes ; ne vous fiez pas uniquement à leur apparence.
• Confirmez que chaque champ possède une étiquette ou une instruction claire et associée.
• Soumettez des données de test non valides et vérifiez si l’erreur est signalée et si des indications de correction utiles sont fournies, le cas échéant.

Vérifier les annonces de messages et de statuts

Envoyez un message de test et vérifiez comment le lecteur d’écran le présente. Faites ensuite apparaître une réponse ou une autre mise à jour pendant que le focus reste ailleurs. Les utilisateurs doivent pouvoir savoir qu’une nouvelle information pertinente est arrivée sans devoir rechercher la conversation ni voir le focus se déplacer de manière inattendue.

Vérifiez également les changements d’état qui ne déplacent pas le focus, comme un retour de validation ou un message sur l’état de la connexion lorsque cet état fait partie de l’expérience testée. Le critère de succès 4.1.3 des WCAG 2.2 concerne les messages d’état qui peuvent être déterminés par programmation afin que les technologies d’assistance puissent les présenter sans recevoir le focus. Évitez d’annoncer chaque petit changement visuel : les annonces doivent être utiles et ne pas submerger la conversation.

• Une personne utilisant un lecteur d’écran peut-elle identifier les messages entrants et leur expéditeur ?
• Les mises à jour importantes sont-elles annoncées tandis que le focus reste en place ?
• Les messages de validation et autres messages d’état sont-ils communiqués aux technologies d’assistance sans nécessiter une recherche visuelle ?
• Les annonces sont-elles compréhensibles, opportunes et exemptes de répétitions inutiles ?

Consigner les problèmes et attribuer les responsabilités

Décrivez chaque constat de façon à ce qu’une autre personne puisse le reproduire. Indiquez la page et l’état du widget, l’environnement de test, le point de départ, les étapes exactes au clavier ou avec le lecteur d’écran, le résultat observé et le résultat attendu. Décrivez l’impact en termes concrets — par exemple : « une personne utilisant le clavier ne peut pas atteindre le bouton d’envoi » — plutôt que de noter uniquement une référence à une norme.

Distinguez les problèmes probablement liés à l’intégration à la page hôte de ceux qui relèvent du widget, tout en gardant à l’esprit que l’expérience intégrée est ce qui compte pour les utilisateurs. Si les responsabilités ne sont pas claires, demandez à l’équipe du site web et au fournisseur du widget de reproduire le problème ensemble. Un constat qui concerne les deux, comme un déplacement du focus vers du contenu masqué de la page à l’ouverture du panneau, peut nécessiter une enquête conjointe.

• Consignez : l’identifiant du problème, l’URL, la date, le navigateur et le système d’exploitation, la technologie d’assistance, les étapes, le résultat observé et le résultat attendu.
• Ajoutez : l’impact sur les utilisateurs, une capture d’écran ou un court enregistrement si cela convient, ainsi que le responsable probable.
• Classez le problème comme relevant de la page hôte, du widget, de l’intégration ou d’une responsabilité partagée ou incertaine.
• Après une correction, répétez les mêmes étapes et consignez le résultat sur la page intégrée, et pas seulement dans un aperçu local du composant.

S’appuyer sur les recommandations WCAG et WAI, puis refaire les tests après les changements

Utilisez les WCAG 2.2 comme référence d’évaluation pour le fonctionnement au clavier, l’ordre et la visibilité du focus, les étiquettes et les instructions, l’identification des erreurs, les noms et rôles des composants ainsi que les messages d’état. Les pratiques de création WAI-ARIA fournissent des recommandations utiles pour les boîtes de dialogue modales et les boutons ; appliquez les modèles selon le comportement réel de l’interface, et pas seulement selon son apparence.

Les recommandations d’évaluation du WAI préconisent d’évaluer tôt et tout au long du développement. Répétez les vérifications pertinentes après toute modification de la configuration du widget, du style du site web, du code d’intégration ou du widget lui-même. Conservez une courte checklist de non-régression et les constats afin que les équipes puissent savoir si un problème est réapparu.

• WCAG 2.2 : https://www.w3.org/TR/wcag/
• Présentation de l’évaluation de l’accessibilité du WAI : https://www.w3.org/WAI/test-evaluate/
• Modèle de boîte de dialogue modale WAI-ARIA APG : https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• Modèle de bouton WAI-ARIA APG : https://www.w3.org/WAI/ARIA/apg/patterns/button/
• Méthode d’évaluation WCAG-EM : https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/

Prévoir une solution humaine si le widget empêche l’accès

Si une personne ne peut pas atteindre ou utiliser le chat, ne faites pas du widget inaccessible son seul moyen d’obtenir de l’aide. Proposez un autre moyen de contact lui-même accessible et indiquez clairement comment joindre une personne. Les équipes qui utilisent webchat.vip peuvent organiser les conversations et configurer des parcours qui les transfèrent à des personnes ou leur passent le relais ; cette fonctionnalité ne suffit pas, à elle seule, à établir qu’un widget ou un parcours donné réussit un audit d’accessibilité.

Désignez une équipe ou une fonction précise chargée de recevoir les constats d’accessibilité, de coordonner les échanges avec les responsables du site et du widget, et de confirmer les corrections. Si la cause n’est pas claire, gardez le problème ouvert et reproduisez-le conjointement plutôt que de demander à la personne concernée de diagnostiquer la séparation technique entre les composants.

• Indiquez aux utilisateurs comment joindre l’assistance par un autre moyen accessible lorsque le chat leur est inaccessible.
• Transmettez les problèmes d’accès non résolus à un contact humain du service d’assistance et à un responsable du site web ou de l’accessibilité.
• Vérifiez l’autre moyen de contact et l’expérience intégrée corrigée à l’aide de tests au clavier et avec lecteur d’écran.