L'étape de paiement est pour beaucoup de boutiques en ligne la partie la plus vulnérable du site en matière d'accessibilité. Alors que les pages de produits fonctionnent souvent encore correctement avec un lecteur d'écran, le processus s'arrête dès qu'un client doit payer : boutons sans libellé clair, messages d'erreur qui ne sont pas annoncés, ou un widget de paiement d'un prestataire externe qui ne peut pas être utilisé sans souris. Ce n'est pas un hasard. L'étape de paiement contient le plus d'éléments dynamiques de tout le site, et les éléments dynamiques sont précisément là où les lecteurs d'écran et la navigation au clavier posent le plus de problèmes.
Il ne s'agit pas d'un petit détail. L'étape de paiement est soumise aux mêmes exigences EN 301 549 que le reste du site, et c'est une étape qu'un utilisateur parcourt définitivement au moment où il souhaite réellement acheter quelque chose. Un lecteur d'écran qui s'arrête là exclut un client au moment décisif. C'est aussi la raison pour laquelle chez axessia, nous incluons l'étape de paiement par défaut dans le scan complet, et non seulement dans le scan gratuit de quelques pages clés.
Où les choses s'en vont mal dans la pratique
Les problèmes les plus courants sont remarquablement récurrents. Un bouton pour « étape suivante » ou « payer maintenant » qui ne contient qu'une icône sans texte qu'un lecteur d'écran puisse lire. Un message d'erreur pour un champ de code postal mal rempli qui apparaît visuellement mais n'est pas annoncé parce que la liaison technique appropriée manque. Un indicateur de progression (« étape 2 sur 3 ») qui est visuellement clair mais reste invisible pour un lecteur d'écran. Et le prestataire de paiement lui-même : les widgets iDEAL ou de carte de crédit de tiers sont souvent intégrés séparément et ont leur propre niveau d'accessibilité, sur lequel une boutique en ligne a peu de contrôle mais reste néanmoins responsable.
La séquence de focus est aussi un problème récurrent. Après l'envoi d'un formulaire contenant une erreur, l'attention de l'utilisateur devrait se porter sur le message d'erreur. Si cela ne se produit pas, quelqu'un qui utilise le clavier ou un lecteur d'écran reste à chercher ce qui s'est mal passé, sans aucun point d'appui.
Pourquoi un scan automatisé manque partiellement cela
Un scan automatisé est bon pour signaler les libellés manquants, les boutons vides et les problèmes structurels du code source. Ce qu'un scan ne peut pas bien évaluer, c'est le comportement : un message d'erreur est-il réellement annoncé à haute voix, le focus se déplace-t-il logiquement, et l'étape de paiement reste-t-elle accessible sans souris après l'entrée de données. Cela nécessite quelqu'un qui parcoure réellement cette étape avec un lecteur d'écran. C'est précisément le type de limitation qui est explicitement énoncé dans chaque rapport axessia : un scan teste une partie des exigences, pas tout.
C'est pourquoi le scan complet ne se concentre pas seulement sur la page d'accueil, mais précisément sur les étapes qu'un client doit vraiment parcourir, y compris la connexion et le paiement. Si vous voulez d'abord une indication sans engagement, vous pouvez en quelques questions voir où se situe votre site actuellement.
Ce que cela signifie pour les exigences auxquelles vous devez vous conformer
La norme sous-jacente, EN 301 549, se traduit en pratique par WCAG 2.1 au niveau AA. Cela contient des exigences concernant le nom, le rôle et le statut des éléments interactifs, les messages de statut qui doivent être perceptibles sans attraction visuelle, et les informations qui ne sont pas communiquées uniquement par la couleur ou la position. Pour la formulation exacte et l'emplacement dans le texte officiel, EUR-Lex est la source appropriée ; nous traduisons ces exigences en situations reconnaissables comme l'étape de paiement, mais ne nous prononcons pas sur votre situation spécifique. Pour en savoir plus sur la façon dont cette traduction se fait, lisez la page qui explique d'où proviennent nos informations.
Comment vous pouvez tester cela vous-même ou le faire tester
Une première étape pratique consiste à parcourir l'étape de paiement elle-même sans souris : uniquement avec la touche Tab et Entrée. Si vous ne pouvez pas avancer à un moment donné, il y a de fortes chances qu'un lecteur d'écran se bloque aussi à cet endroit. Une deuxième étape consiste à tester avec un lecteur d'écran gratuit comme NVDA, et à prêter une attention particulière à ce qui est lu dès qu'une erreur se produit. Pour une vue complète, y compris les éléments qui ne remontent que lors d'un parcours manuel en détail, un test plus approfondi est nécessaire ; axessia.eu effectue ce test et consigne les résultats dans une liste d'actions hiérarchisée, mais n'effectue pas elle-même de travaux de correction. Cela reste à la charge de votre propre développeur ou prestataire, souvent sur la base des points précis que nous identifions. D'autres sujets fréquemment posés autour de ce type de difficultés concrètes se trouvent rassemblés dans la base de connaissances avec des sujets développés selon chaque situation.
Si vous souhaitez savoir quel est le coût d'un test complet de votre étape de paiement et de votre environnement de connexion, cela figure clairement sur la page des tarifs et de ce qu'elle contient.
Souhaitez-vous d'abord vous faire une idée sans engagement ? Le test rapide gratuit d'axessia.eu vous donne, en quelques minutes, une première image de vos pages principales, et le contrôle de périmètre montre si la réglementation s'applique à votre organisation.