Un achat presque terminé
Imaginons un client qui utilise un lecteur d’écran. Il ajoute un article à son panier, mais au moment de payer, il ne trouve pas le message qui lui permettrait de corriger une erreur. Même si le site obtient un bon résultat au contrôle automatisé, que sait-on de son accessibilité numérique à cette étape? Gonçalves et al. (2018) ont observé une autre difficulté sur une boutique en ligne. Le site avait obtenu un bon résultat au contrôle automatisé. Pourtant, après avoir envoyé leur commande, certains participants ont demandé si la tâche était terminée.
Ces obstacles privent les clients de leur autonomie à une étape décisive de leur parcours. Les normes aident à concevoir un formulaire de paiement accessible. Pour savoir si un client peut aller jusqu’au bout de sa commande, il faut aussi observer comment il s’y prend et à quel moment il doit demander de l’aide.
À retenir
Conformité: Un audit automatisé détecte des erreurs techniques mais ne prouve pas qu’un parcours complet est utilisable.
Autonomie: Le client peut-il terminer sa commande sans devoir solliciter quelqu’un ?
Performance de l’entreprise: Les effets éventuels d’une correction sur les ventes restent à mesurer.
Que dit un audit sur l’accessibilité numérique du paiement ?
Pour interpréter un résultat d’audit, il faut savoir quelles étapes ont été examinées et par quelle méthode. Un contrôle automatisé repère certains problèmes techniques. Une évaluation de conformité vérifie le respect des critères applicables des WCAG, tandis qu’un test utilisateur montre comment une personne accomplit une tâche. L’illusion de conformité apparaît lorsqu’un résultat favorable obtenu sur une page est présenté comme la preuve que tout le parcours de paiement est accessible.
Un score élevé ne prouve pas l’absence d’obstacles. Gonçalves et al. (2018) ont comparé plusieurs méthodes d’évaluation sur un site portugais de commerce en ligne. Le contrôle automatisé a donné un bon résultat. Pourtant, les vérifications manuelles et l’évaluation menée par des spécialistes ont révélé des problèmes d’accessibilité et d’utilisabilité. Les participants aveugles ont aussi rencontré des difficultés lors du test. En croisant ces méthodes, les chercheurs ont pu repérer des obstacles que le score seul ne faisait pas apparaître. Leur étude ne permet toutefois pas de conclure que le site respecte l’ensemble des exigences des WCAG.
Une difficulté rencontrée à l’usage ne signifie pas nécessairement que les normes sont insuffisantes. Les WCAG 2.2 exigent que toutes les pages d’un processus complet respectent le niveau de conformité visé, du choix du produit à la fin de la commande (World Wide Web Consortium [W3C], 2024, section 5.2.3). Vérifier une seule page ne suffit donc pas.
Un obstacle peut être couvert par les critères, mais ne pas avoir été repéré lors de l’évaluation. Il arrive aussi que les critères ne répondent pas entièrement aux besoins d’une personne. Le W3C (2024) reconnaît cette limite. Face à une difficulté persistante, il faut examiner les critères concernés et les vérifications réalisées avant de mettre en cause la norme.
Cette exigence de rigueur s’accompagne également d’enjeux de responsabilité, le Département de la Justice des États-Unis considérant que les obligations du titre III de l’ADA s’appliquent aux services en ligne des entreprises concernées (U.S. Department of Justice, 2022).
Que change une interface plus accessible pour les utilisateurs ?
Une interface plus accessible peut aider les utilisateurs à accomplir leurs tâches et leur sembler plus facile à utiliser. Une étude comparant différentes versions du site Web (Schmutz et al., 2016) a recruté 61 participants sans handicap. Dans la version la plus accessible, les participants réussissaient davantage de tâches et certaines évaluations subjectives étaient plus favorables. Comme l’étude portait sur des participants sans handicap, elle ne permet pas de généraliser ces résultats à tous les utilisateurs. Elle ne permet pas non plus de conclure à une hausse des ventes.
Vollenwyder et al. (2023) ont comparé deux versions d’une boutique en ligne qui différaient par leur niveau de conformité aux normes. L’expérience réunissait 66 personnes ayant une déficience visuelle et 65 personnes sans déficience visuelle. En termes d’indicateurs quantitatifs d’utilisabilité et d’expérience utilisateur, l’étude n’a trouvé aucune différence statistiquement significative entre les deux versions. Avec la version AA, les participants ayant une déficience visuelle ont décrit plus d’expériences positives. Les participants sans déficience visuelle ont décrit moins d’expériences positives et moins d’expériences négatives.
Note: Le tableau présente le taux moyen de réussite de trois tâches. Pour la tâche d’achat, il fallait ajouter les produits demandés au panier, dans les bonnes quantités, puis commencer le paiement. L’étude ne demandait pas aux participants d’aller jusqu’au bout du paiement.
Les deux études portent sur des tâches différentes. Chez Schmutz et al. (2016), les participants devaient notamment trouver une ligne de bus. Dans l’étude de Vollenwyder et al. (2023), la tâche d’achat s’arrêtait au début du paiement. Comme les deux études diffèrent aussi par les publics et les interfaces, il est difficile d’expliquer l’écart entre leurs résultats par un seul facteur.
Pour un site marchand, il faut donc préciser ce qu’on cherche à mesurer. Un client peut trouver la boutique facile à utiliser et pourtant avoir besoin d’aide pour terminer sa commande.
Du panier à la confirmation, où le client risque-t-il de rester bloqué ?
La maîtrise d’un achat en ligne ne se résume pas à l’accès initial à une page produit. Elle se construit à travers plusieurs points de contact du parcours client (Lemon & Verhoef, 2016). Une fois le produit sélectionné, il y a trois moments qui méritent une attention particulière. Dans le panier, la personne doit pouvoir vérifier ce qu’elle s’engage à acheter. Dans le formulaire, elle doit pouvoir repérer et corriger une erreur. Après le paiement, elle doit pouvoir déterminer si sa commande a abouti. Les exemples du panier et du code postal sont hypothétiques. Le cas de la confirmation de commande vient d’une étude de Gonçalves et al. (2018) menée auprès de personnes aveugles.
Dans le panier, un client change la quantité d’un article. Le total est mis à jour à l’écran, mais son lecteur d’écran ne lui annonce pas le nouveau montant. Comment peut-il vérifier ce qu’il va payer ? S’il doit demander à quelqu’un de lire le total à sa place, il ne peut plus vérifier sa commande de façon autonome.
Une autre difficulté apparaît lorsqu’une erreur de saisie empêche de poursuivre. En soumettant son adresse de livraison, le client reçoit le message : « Veuillez vérifier les informations que vous avez renseignées. » Il comprend qu’une erreur est survenue, mais ne sait pas quel champ corriger. Il peut alors relire toute l’adresse ou modifier un numéro de rue pourtant correct, puis renvoyer le formulaire sans avoir corrigé le code postal.
Une dernière difficulté concerne la confirmation de la commande. Une commande peut être enregistrée sans que le client sache si elle a abouti. Dans le test mené par Gonçalves et al. (2018), le message confirmant l’envoi de la commande était bien présent. Pourtant, après la validation, le lecteur d’écran reprenait la lecture au début de la page. Les participants devaient parcourir les éléments un à un avant d’entendre la confirmation. Certains ont demandé si la tâche était terminée.
Le client doit pouvoir vérifier sa commande, modifier ses informations et savoir si son achat a abouti sans demander de l’aide. S’il abandonne, le taux d’abandon ne nous dit pas ce qui l’a poussé à partir. Pour mieux comprendre le problème, l’équipe peut observer comment il essaie de corriger une erreur et à quel moment il reste bloqué.
Cette courte vidéo reprend l’exemple du code postal pour montrer ce qu’un message plus précis apporte, et ce qu’il reste à vérifier.
Comment évaluer l’autonomie au moment de payer?
Un bon résultat à un contrôle technique ne suffit pas à montrer qu’un client peut payer sans aide. L’illusion de conformité apparaît lorsqu’on confond les deux. Pour examiner cette différence, l’équipe peut croiser plusieurs méthodes sur une même tâche. Prenons un code postal mal saisi. Une vérification technique permet de contrôler si le message identifie le champ à corriger. Lors d’un test utilisateur, l’équipe observe ensuite si la personne retrouve ce champ et corrige sa saisie avec son lecteur d’écran. Si les données du site montrent plusieurs tentatives d’envoi du formulaire, elles donnent une piste à examiner. Elles ne disent toutefois pas pourquoi la personne a dû recommencer.
Note: Ce schéma aide à comparer les observations. Il ne constitue pas un protocole de certification.
Tout d’abord, l’équipe doit effectuer une vérification technique du formulaire de paiement. Ara et al. (2024)présentent plusieurs méthodes pour évaluer l’accessibilité d’un site. Gómez-Delgado et al. (2026) constatent que ces évaluations sont encore peu présentes au début des projets. Plus précisément, l’évaluation peut vérifier si le champ erroné peut être rejoint au clavier et comment l’interface présente des messages d’erreur. Réussir quelques contrôles ne suffit pas à établir une conformité complète. Ces résultats ne montrent pas non plus si une personne comprend le message d’erreur et parvient à corriger sa saisie.
Le test utilisateur permet d’observer si la personne repère l’erreur, comprend ce qu’elle doit modifier et poursuit son achat. L’équipe peut noter si la tâche est interrompue, accomplie avec une aide humaine ou accomplie sans cette aide. L’utilisation d’un lecteur d’écran reste compatible avec une réalisation autonome.
Sur une plateforme de commerce électronique,Gonçalves et al. (2018) ont observé des difficultés d’usage malgré un résultat favorable au contrôle automatisé, et ce cas a également été inclus dans un examen plus large de l’expérience numérique des malvoyants (Hamideh Kerdar et al., 2024).Ces observations complètent l’évaluation selon les standards, mais leurs conclusions restent limitées aux personnes et aux situations examinées (World Wide Web Consortium, 2021).
Si le site enregistre plusieurs tentatives d’envoi du même formulaire, l’équipe peut regarder de plus près ce qui se passe à cette étape. Vigo et Harper (2017) décrivent une méthode qui repère des signes de difficulté définis à l’avance. Apaolaza et Vigo (2019) étudient une autre méthode qui aide à repérer et à interpréter des comportements qui se répètent. Ces méthodes examinent le détail des interactions. Le taux d’abandon, lui, indique seulement quelle part des sessions de paiement se termine sans commande. Les traces seules ne permettent pas de savoir pourquoi un client a essayé plusieurs fois, s’il a un handicap ou s’il a eu besoin d’aide. Pour comprendre ce qui se passe, l’équipe peut observer une personne qui remplit le formulaire.
Pour une même tâche, l’équipe peut comparer les résultats des vérifications techniques avec les difficultés observées et, si le site enregistre des données d’usage, les signaux qu’on y repère. La grille suivante traduit cette démarche en trois étapes. Pour chacune, l’équipe peut documenter la difficulté, envisager une correction et reprendre la tâche avec les utilisateurs concernés.
Trois étapes pour vérifier l’autonomie au paiement
Repérer le blocage, adapter l’interface, puis reprendre la tâche avec la personne.
Repérer l’erreur
Observer
La personne trouve-t-elle le message et le champ concerné avec son équipement habituel ?
Ajuster
Revoir le message, l’identification du champ ou son accès au clavier, selon le blocage.
Vérifier
La personne atteint-elle le champ à corriger sans aide humaine？
Corriger la saisie
Observer
La personne comprend-elle ce qui est incorrect et ce qu’elle doit saisir?
Ajuster
Clarifier l’instruction ou le format, puis vérifier la validation de la saisie.
Vérifier
Vérifier si la personne corrige l’erreur et poursuit sans aide humaine. Noter les tentatives infructueuses.
Confirmer le résultat
Observer
La personne peut-elle poursuivre et connaître le statut de sa commande ?
Ajuster
Examiner l’étape bloquante et la présentation du statut, avec le prestataire si nécessaire.
Vérifier
Comparer le statut compris à l’état réel de la commande. Noter toute aide humaine.
Sources: Grille élaborée pour cet article à partir des WCAG 2.2, critères 3.3.1 à 3.3.3 (W3C, 2024), du guide du W3C sur l’évaluation avec des utilisateurs (2021) et de l’étude de Schmutz et al. (2017) sur la réussite des tâches.
Financer les corrections, vérifier les résultats au paiement
Lorsqu’un obstacle est documenté, l’équipe doit décider des corrections à financer, même si le score automatisé paraît rassurant. Si un client doit demander de l’aide pour corriger son code postal et passer sa commande, l’équipe devrait traiter ce problème en priorité. Elle a une raison d’agir, même si elle ne sait pas encore si la correction fera augmenter les ventes.
Pour choisir les corrections à financer, l’équipe peut examiner les tâches entravées et leurs conséquences pour les utilisateurs, plutôt que compter uniquement les anomalies détectées. La revue de Droutsas et al. (2025) relève des effets différents selon les groupes de personnes handicapées. Appliquée au paiement, cette observation invite à documenter la tâche bloquée et les situations concernées. L’équipe peut ainsi accorder la priorité à un obstacle qui empêche de poursuivre, même s’il est peu signalé.
Après avoir pris cette décision, l’équipe doit estimer les ressources nécessaires. Cependant, dans leur enquête auprès de douze organisations, Huffaker et al. (2014) n’ont pas obtenu les informations nécessaires pour établir un rapport coûts-bénéfices solide. Face à cette incertitude, l’équipe peut estimer les resources nécessaires pour réparer les obstacles, vérifier le fonctionnement de la technologie et inviter les utilisateurs concernés à accomplir à nouveau la tâche.
Comment vérifier les effets de la correction?
Après la correction, l’équipe peut examiner deux résultats : la capacité des clients à terminer leur achat sans aide humaine et la proportion de sessions de paiement qui aboutissent à une commande.
Lors du test utilisateur
Après la correction, l’équipe peut proposer la même tâche aux participants. Parmi ceux qui essaient de passer commande, combien y parviennent sans aide humaine ? Si une personne doit demander de l’aide ou abandonne, l’équipe peut noter à quelle étape cela se produit. Schmutz et al. (2017) ont également mesuré la réussite des tâches et le temps nécessaire pour les accomplir.
Sur le site marchand
L’équipe peut suivre la proportion de sessions de paiement qui aboutissent à une commande confirmée. Pour calculer ce taux, elle divise le nombre de sessions avec une commande confirmée par le nombre total de sessions où le paiement a été commencé, sur la même période.
Une commande peut être enregistrée même si le client a eu besoin d’aide.
Même si le taux de conversion augmente après la correction, cette hausse peut avoir d’autres causes. Pour mieux isoler l’effet de la modification, l’équipe peut comparer deux versions accessibles du formulaire en répartissant les utilisateurs au hasard entre les deux groupes (Kohavi et al., 2007).
Le client peut-il aller jusqu’au bout de sa commande sans aide ?
Un bon score au contrôle automatisé peut donner l’impression que tout le parcours de paiement respecte les normes. C’est là que se crée l’illusion de conformité. Si une erreur survient au moment de payer, la personne peut-elle la repérer avec son aide technique, comprendre ce qu’elle doit corriger et poursuivre son achat sans avoir à demander l’aide de quelqu’un ?
Au moment de confirmer la commande, un détail compte encore. La personne sait-elle que sa commande a bien été envoyée, ou doit-elle demander à quelqu’un de le vérifier? Pour juger une correction, l’entreprise doit examiner ce qui a changé pour la personne dans la situation observée. Son effet éventuel sur les ventes se mesure séparément.
Références:
Apaolaza, A., & Vigo, M. (2019). Assisted pattern mining for discovering interactive behaviours on the web. International Journal of Human-Computer Studies, 130, 196‑208. https://doi.org/10.1016/j.ijhcs.2019.06.012
Ara, J., Sik-Lanyi, C., & Kelemen, A. (2024). Accessibility engineering in web evaluation process : A systematic literature review. Universal Access in the Information Society, 23(2), 653‑686. https://doi.org/10.1007/s10209-023-00967-2
Droutsas, N., Spyridonis, F., Daylamani-Zad, D., & Ghinea, G. (2025). Web accessibility barriers and their cross-disability impact in eSystems : A scoping review. Computer Standards & Interfaces, 92, Article 103923. https://doi.org/10.1016/j.csi.2024.103923
Gómez-Delgado, J., Marín-Palacios, C., & Moreno, L. (2026). Integrating accessibility, usability and UX in web project management : A systematic review. Universal Access in the Information Society, 25(1), Article 28. https://doi.org/10.1007/s10209-025-01298-0
Gonçalves, R., Rocha, T., Martins, J., Branco, F., & Au-Yong-Oliveira, M. (2018). Evaluation of e-commerce websites accessibility and usability: An e-commerce platform analysis with the inclusion of blind users. Universal Access in the Information Society, 17(3), 567‑583. https://doi.org/10.1007/s10209-017-0557-5
Hamideh Kerdar, S., Bächler, L., & Kirchhoff, B. M. (2024). The accessibility of digital technologies for people with visual impairment and blindness : A scoping review. Discover Computing, 27(1), Article 24. https://doi.org/10.1007/s10791-024-09460-7
Huffaker, R., Bascones, L. M., & Rubio, P. (2014). Determining costs and benefits of website accessibility in Ireland: Results from an empirical approach. Journal of Accessibility and Design for All, 4(1), 14‑29. https://doi.org/10.17411/jacces.v4i1.56
Kohavi, R., Henne, R. M., & Sommerfield, D. (2007). Practical guide to controlled experiments on the web : Listen to your customers not to the hippo. Proceedings of the 13th ACM SIGKDD international conference on Knowledge discovery and data mining, KDD ’07, 959‑967. https://doi.org/10.1145/1281192.1281295
Lemon, K. N., & Verhoef, P. C. (2016). Understanding customer experience throughout the customer journey. Journal of Marketing, 80(6), 69‑96. https://doi.org/10.1509/jm.15.0420
Schmutz, S., Sonderegger, A., & Sauer, J. (2016).Implementing recommendations from web accessibility guidelines: Would they also provide benefits to nondisabled users? Human Factors, 58(4), 611‑629. https://doi.org/10.1177/0018720816640962
Schmutz, S., Sonderegger, A., & Sauer, J. (2017). Implementing recommendations from web accessibility guidelines: A comparative study of nondisabled users and users with visual impairments. Human Factors, 59(6), 956‑972. https://doi.org/10.1177/0018720817708397
U.S. Department of Justice. (2022, 18 mars). Guidance on web accessibility and the ADA.https://www.ada.gov/resources/web-guidance/
Vigo, M., & Harper, S. (2017). Real-time detection of navigation problems on the World ‘Wild’ Web. International Journal of Human-Computer Studies, 101, 1‑9. https://doi.org/10.1016/j.ijhcs.2016.12.002
Vollenwyder, B., Petralito, S., Iten, G. H., Brühlmann, F., Opwis, K., & Mekler, E. D. (2023). How compliance with web accessibility standards shapes the experiences of users with and without disabilities. International Journal of Human-Computer Studies, 170, Article 102956. https://doi.org/10.1016/j.ijhcs.2022.102956
World Wide Web Consortium. (2021, 1 juin). Involving Users in Evaluating Web Accessibility. Web Accessibility Initiative (WAI). Consulté 2 novembre 2026, à l’adresse https://www.w3.org/WAI/test-evaluate/involving-users/
World Wide Web Consortium. (2024, 12 décembre). Web content accessibility guidelines (WCAG) 2.2. Consulté 31 octobre 2026, à l’adresse https://www.w3.org/TR/2024/REC-WCAG22-20241212/