Un client effectuant un paiement par carte à l'aide d'un terminal de paiement portable.

Description de l'image : un client effectuant un paiement par carte à l'aide d'un terminal de paiement portable.

Le processus de paiement en ligne : le domaine le plus litigieux sur Internet

AIOPSGROUP · Intelligence en matière d'accessibilité
Analyse des litiges · Dossiers déposés devant les tribunaux fédéraux · 2007-2026

Le processus de paiement en ligne : le domaine le plus litigieux sur Internet

Une base de données regroupant 8 788 poursuites judiciaires fédérales relatives à l'accessibilité du Web révèle une tendance peu flatteuse. Les mêmes quelques bugs se retrouvent en production aux mêmes quelques étapes – et ce sont les mêmes quelques plaignants qui les détectent. Sur les 81 509 problèmes répertoriés par les avocats dans les dossiers judiciaires, plus de 4 050 se concentrent sur les cinq éléments qui transforment un visiteur en acheteur: le panier, l'adresse, le paiement, les messages d'erreur et le bouton de validation de la commande lui-même.

4,050
problèmes liés à la phase de paiement mentionnés dans les documents judiciaires (panier, adresse, paiement, ajout au panier, processus de paiement)
7.4×
Évolution du nombre de dossiers déposés chaque année, 2021 → 2025 (466 → 3 449 dossiers)
97
nombre médian de jours entre le dépôt de la plainte et la clôture du dossier (ce qui laisse supposer un règlement à l'amiable)
83.4%
Dans la plupart des affaires classées, le litige est réglé en moins de six mois : les défendeurs s'acquittent de leur dette ou remédient au problème, puis l'affaire est classée. Le système est conçu pour traiter un volume important de dossiers, et non pour donner lieu à des contestations.

Pourquoi les fraudes à la caisse sont celles qui vous coûtent le plus cher

Les poursuites judiciaires en matière d'accessibilité du Web visent tous les niveaux d'un site web : page d'accueil, navigation, pied de page, moteur de recherche. Mais dans les rares cas où une plainte aboutit à une requête en jugement sommaire, les tribunaux ne se laissent pas influencer par les obstacles d'ordre esthétique. Ce sont les obstacles d'ordre transactionnel qui les convainquent. Un acheteur aveugle qui ne parvient pas à trouver une bannière principale n'a, en termes juridiques les plus crus, rien perdu. Un acheteur aveugle qui ne parvient pas à finaliser un achat s'est vu refuser un service que le vendeur a offert à tous les autres visiteurs. Il s'agit là de la formulation type d'une violation du Titre III, et c'est ce même schéma factuel qui revient dans chaque lettre de mise en demeure rédigée par les avocats des plaignants.

C'est pourquoi les points les plus cités dans l'ensemble de données ne sont pas ceux qui génèrent le plus de plaintes dans l'ensemble. La catégorie « Général / Non classé » est de loin la plus importante (38 671 problèmes). Mais si l'on se base sur les sommes en jeu par échec, le tunnel de paiement génère plus de litiges que toutes les autres catégories réunies. Chaque champ CVC non étiqueté constitue un déni de service. Chaque message « Commande confirmée » non annoncé correspond à une transaction que l'utilisateur ne peut pas prouver avoir effectuée. Chaque fenêtre modale qui retient le focus à l'étape « Appliquer le coupon » représente une réduction pour laquelle l'utilisateur d'un lecteur d'écran a payé le prix fort pour pouvoir la sauter.

La fonction de gestion des litiges

Dans une salle d'audience fédérale américaine, la question n'est pas de savoir si « la page d'accueil est accessible », mais si « le plaignant pouvait acheter ce que le défendeur proposait à la vente ». Le processus de paiement est le seul élément pour lequel la réponse est binaire, et le seul pour lequel il est aisé de faire valoir des dommages-intérêts.

L'ensemble de données

L'analyse qui sous-tend cet article s'appuie sur deux corpus indépendants. Le premier est un instantané structuré de la base de données PACER comprenant 8 788 affaires civiles fédérales introduites en vertu de la loi américaine sur les personnes handicapées (Americans with Disabilities Act) et des lois étatiques parallèles entre janvier 2007 et avril 2026, chaque affaire étant associée à son ou ses plaignants, son ou ses défendeurs, sa date de dépôt et sa date de jugement. Le second est une extraction parallèle de 81 509 problèmes d'accessibilité distincts tirés du texte de ces dossiers – les phrases réelles rédigées par les avocats pour décrire ce que leurs clients ne pouvaient pas faire.

Ces deux sources combinées nous permettent de répondre à des questions auxquelles une seule source ne saurait répondre. Nous savons non seulement quels sites ont fait l'objet d'une poursuite, mais aussi ce que les avocats ont indiqué au tribunal comme étant défaillant – et à quel moment du parcours utilisateur cette défaillance s'est produite. Pour cet article, nous avons filtré le corpus de problèmes en cinq catégories du tunnel d'achat : PROCESSUS DE PAIEMENT, PANIER D'ACHAT, AJOUTER AU PANIER, PAIEMENT, GESTION DE L'ADRESSE. Ensemble, ces cinq aspects représentent 4 050 problèmes, soit environ 5 % du corpus, mais la partie présentant le lien de causalité le plus fort avec un préjudice déterminant.

Remarque concernant la couverture Le chiffre de 8 788 cas englobe les litiges en matière d'accessibilité visant n'importe quelle plateforme numérique ; tous ne concernaient pas nécessairement le commerce électronique de détail. Cependant, les sites de commerce électronique et les franchises qui les exploitent occupent une place prépondérante parmi les défendeurs : Marriott, TJX, Tapestry, Wolverine World Wide, Five Below, Walgreens, Target, Genesco, Sherwin-Williams, GameStop et Caleres apparaissent chacun au moins cinq fois.

La courbe que personne n'avait prise en compte dans le plan du quatrième trimestre

Avant d'aborder le fonctionnement interne de l'entonnoir, il convient de souligner à quel point son entrée s'est rétrécie. Le nombre de dépôts annuels a été multiplié par dix depuis 2020 et continue de croître à un rythme accéléré. Le chiffre de 2026 ci-dessous ne concerne que le premier trimestre ; si l'on extrapole sur l'ensemble de l'année, il devrait dépasser les 4 500, soit près de dix fois le niveau de référence de 2021.

Fig. 1 Poursuites judiciaires fédérales en matière d'accessibilité du Web par année, n = 8 788
2019
6
0.07%
2020
45
0.51%
2021
466
5.30%
2022
755
8.59%
2023
1,018
11.58%
2024
2,156
24.53%
2025
3,449
39.25%
2026
878 ▱
1er trimestre uniquement

▱ Données partielles pour 2026 : dépôts enregistrés jusqu'en avril 2026. Au rythme observé au premier trimestre, l'année devrait totaliser environ 3 500 dépôts, ce qui correspond à la tendance de 2025.

Deux points méritent d’être retenus. Premièrement, l’année charnière est 2021 – qui coïncide avec l’essor du commerce électronique post-pandémique et une vague de jurisprudence des tribunaux d’État (notamment l’affaire Robles c. Domino’s, dont la Cour suprême a rejeté le pourvoi en 2019) qui a conduit les tribunaux fédéraux de la neuvième circonscription judiciaire à inclure les sites web dans la définition des « lieux publics » du Titre III. Deuxièmement, la croissance ne s’est pas stabilisée. Chaque année depuis 2021 a atteint un nouveau record, et chaque nouveau record annuel a été atteint alors que le Titre III restait, formellement, non réglementé pour les sites commerciaux privés.

L'entonnoir au sein de l'entonnoir

Sur les 81 509 problèmes répertoriés à partir des signalements, 4 050 relèvent de l'une des cinq catégories de l'entonnoir d'achat ci-dessous. La répartition proportionnelle correspond presque parfaitement à l'entonnoir de conversion classique : davantage de problèmes sont signalés au début du parcours, chaque étape entraînant à la fois la perte d'utilisateurs légitimes et la survenue d'obstacles litigieux.

Fig. 2 Nombre de problèmes par étape du tunnel d'achat, n = 4 050
Processus de paiement (global)40,9 %
1 656 numéros
Page du panier25,2 %
1 022 numéros
Ajouter au panier17,7 %
718 numéros
Paiement12,9 %
524 numéros
Gestion des adresses3,2 %
130 numéros

La catégorie « Processus de paiement » est la plus importante, car la plupart des signalements décrivent cette expérience comme un parcours unique. Mais la répartition est instructive : le panier et la fonction « Ajouter au panier » (1 740 cas) génèrent ensemble un peu plus de plaintes faisant l'objet de litiges que la page de paiement elle-même. Cela s'explique en partie par le fait que c'est dans le panier que se produit la première action irréversible : dès lors que l'utilisateur d'un lecteur d'écran ne peut pas confirmer qu'un article a bien été ajouté, chaque étape suivante est effectuée à l'aveugle. Les problèmes qui apparaissent en amont s'aggravent en aval.

Les cinq erreurs les plus fréquentes

Lorsque l’on compare les 4 050 problèmes rencontrés lors de la phase de paiement avec leurs descriptions en texte clair, cinq types de dysfonctionnements reviennent le plus souvent dans les plaintes des plaignants. Nous les présentons ci-dessous par ordre de fréquence d’apparition dans les dossiers, en indiquant à côté de chacun les critères des WCAG les plus fréquemment cités par les avocats.

№ 1
« Je l'ai ajouté à mon panier, mais je ne m'en suis jamais rendu compte. »
Échec de l'ajout au panier pour la référence 639filings

La fonction « Ajouter au panier » déclenche une confirmation visuelle (fenêtre contextuelle, mini-panier coulissant, mise à jour d'un indicateur) que les lecteurs d'écran ne signalent pas. L'utilisateur clique à nouveau, double sa commande ou abandonne. Il s'agit de l'obstacle le plus fréquemment cité dans les signalements liés au panier.

Messages d'état WCAG 4.1.3WCAG 4.1.2 nom rôle valeur
№ 2
« Le champ du code promotionnel ne m'a donné aucune indication lorsque l'opération a échoué. »
566 obstacles liés aux coupons de réduction / codes de réduction

Les champs destinés aux codes promotionnels ne sont pas identifiés, les messages d'erreur ne sont pas signalés et la validation en temps réel se limite à un texte en surbrillance. Les plaignants invoquent souvent le fait d'avoir payé le prix fort parce qu'ils n'ont pas pu accéder à la rubrique des réductions, ce qui constitue un préjudice financier concret.

Identifiant d'erreur WCAG 3.3.1Suggestions concernant l'erreur WCAG 3.3.3
№ 3
« Une fenêtre contextuelle est apparue. Mais je n'y ai pas prêté attention. »
Problèmes de mise au point dans la fenêtre contextuelle / la superposition de référence 511filings

Les boîtes de dialogue de confirmation d'adresse, les fenêtres contextuelles de type « Êtes-vous sûr ? », les propositions de vente incitative et les tests CAPTCHA s'affichent à l'écran, mais ne reçoivent jamais le focus programmatique. Les utilisateurs de clavier et de lecteur d'écran ne peuvent ni les fermer ni passer outre.

WCAG 2.4.3 Ordre de sélectionWCAG 2.1.2 : absence de pièges clavier
№ 4
« Mon code CVC était incorrect. Le formulaire ne mentionnait rien. »
468 enregistrements font référence à des états d'erreur non signalés

Les champs obligatoires laissés vides, les cartes de crédit rejetées par l'expression régulière et les adresses non concordantes ne sont signalés que par des bordures rouges ou des validateurs dont le texte disparaît. L'utilisateur d'un lecteur d'écran valide la commande, n'entend aucun retour d'information et suppose que la commande a bien été prise en compte. Le critère WCAG 3.3.1 est celui qui est le plus souvent cité dans les rapports relatifs au processus de paiement.

Identifiant d'erreur WCAG 3.3.1Étiquettes WCAG 3.3.2
№ 5
« Le champ a été déclaré comme étant “vide” ».
330 fichiers font référence à des champs de saisie non libellés

Numéro de carte, date d'expiration, code postal, « Identique à l'adresse de facturation » : les champs non libellés sont annoncés comme « vide » ou « modifier le texte ». Les utilisateurs ne peuvent pas distinguer les différents champs, les remplissent dans le mauvais ordre et déclenchent des erreurs de validation qui, elles-mêmes, ne sont pas annoncées (voir n° 4).

WCAG 1.3.1 : informations et relationsWCAG 4.1.2 : nom, rôle, valeur
№ 6
« J'ai dû recommencer le processus de paiement. »
163 dossiers concernant des réintroductions forcées

Lorsqu'un seul champ ne passe pas la validation, certains processus de paiement effacent et réinitialisent l'intégralité du formulaire au moment du rechargement. Pour les utilisateurs qui ont mis six minutes à le remplir la première fois à l'aide d'une technologie d'assistance, cela constitue un obstacle qui n'existe pas pour les acheteurs voyants utilisant une souris – un cas d'école d'inégalité d'accès.

Prévention des erreurs WCAG 3.3.4WCAG 2.5.3 : présence d'une étiquette dans le nom

Les critères que les avocats invoquent réellement

La plupart des plaintes ne citent pas explicitement les critères des WCAG : elles en décrivent les symptômes. Toutefois, lorsque les avocats citent des critères spécifiques dans leurs allégations relatives à la phase de paiement, la répartition est très déséquilibrée. Six critères représentent 89 % de toutes les citations explicites; les quelque soixante autres critères des WCAG 2.2 ne sont mentionnés que de manière marginale.

Fig. 3 Critères WCAG 2.x explicitement cités dans 4 050 déclarations au moment du paiement
WCAG Nom du critère Niveau Cité dans Partager C'est là que ça fait mal, au moment de passer à la caisse
3.3.1 Identification des erreurs A 104 32.5% Le formulaire n'a pas signalé les champs obligatoires ni les erreurs de validation
2.4.3 Commande prioritaire A 72 22.5% Les fenêtres modales, les boîtes de dialogue et les transitions entre les étapes ne déplaçaient pas le focus
2.1.1 Clavier A 43 13.4% Les boutons PayPal et « Express » ne sont pas accessibles sans souris
4.1.3 Messages d'état AA 26 8.1% « Ajouté au panier », « Remise appliquée », « Commande passée » (sans notification sonore)
4.1.2 Nom, Rôle, Valeur A 23 7.2% Les widgets radio et de sélection personnalisés ne transmettent pas d'informations d'état à AT
3.3.2 Étiquettes ou instructions A 18 5.6% Le code CVC, le code postal et le champ « Identique à l'adresse de facturation » sont indiqués comme « vides »
1.3.1 Informations et relations A 7 2.2% Indicateurs d'étape non visibles ; regroupement des champs obligatoires
2.4.7 Mise au point visible AA 4 1.2% Les boutons de paiement ne sont pas mis en évidence
2.5.3 Étiquette dans le nom A 1 0.3% Incohérences entre le nom affiché et le nom accessible lors de la commande vocale
Lire attentivement le tableau

Seuls 320 des 4 050 problèmes (environ 8 %) mentionnent un critère WCAG par son numéro. Les autres décrivent le symptôme en langage clair. Conséquence : même si vous remettez un rapport d'audit WCAG 2.2 AA irréprochable, votre équipe d'ingénieurs sera tout de même évaluée en fonction des symptômes – « l'utilisateur n'a pas pu finaliser son achat » est la norme qui intéressera un tribunal, et non « violation du critère de succès 3.3.1 ».

Ce qu'ont réellement écrit les plaignants

Cet ensemble de données est constitué à partir de pièces déposées auprès des tribunaux. Les passages ci-dessous sont tirés de ces documents ; ils ont été anonymisés afin de supprimer toute référence au lieu, mais n’ont pas subi d’autres modifications. Ils sont utiles car ils permettent aux équipes d’ingénieurs de comprendre comment les utilisateurs décrivent, dans leurs propres mots, la manière dont les avocats ont transposé ces descriptions en pièces de procédure.

« Chacun des champs de saisie est annoncé comme étant “vide”. Les options du menu déroulant “Taille” ne sont pas accessibles aux utilisateurs qui se servent uniquement du clavier.» – Allégation relative aux formulaires, plainte déposée auprès du tribunal fédéral du district sud de New York
« Après avoir cliqué sur le bouton « Ajouter au panier », un message de confirmation s'affiche à côté du bouton. Ce message est le seul indicateur permettant de savoir que l'article a bien été ajouté – et il n'est pas annoncé. »– Allégation concernant le bouton « Ajouter au panier »
« Lorsque l'utilisateur tente de finaliser sa commande sans saisir de code postal, aucun message n'indique qu'il s'agit d'une erreur. »– Allégation relative à la gestion des adresses, reprise dans 11 plaintes déposées contre différents défendeurs
« Le plaignant n'a pas pu déterminer si les champs du formulaire étaient obligatoires (« Requis ») sur la page de paiement. L'absence d'instructions détaillées lors du remplissage du formulaire a empêché le plaignant de valider sa commande. »– Allégation relative au processus de paiement
« Le bouton PayPal ne peut pas être actionné à l'aide du clavier (page de paiement) – Le bouton PayPal est sélectionné visuellement, mais ne peut pas être activé à l'aide de la touche Entrée. »– Allégation relative au paiement, en référence à la norme WCAG 2.1.1
« Le demandeur ne pouvait pas revenir en arrière pour corriger les champs du formulaire sans recharger la page entière et tout recommencer. »– Allégation relative au processus de paiement, affaire devant le tribunal fédéral de district du sud de New York

Ce qui caractérise cet ensemble de données, ce n'est pas sa sophistication technique. Les obstacles invoqués par les avocats n'ont rien de nouveau ni d'obscur : il s'agit toujours des mêmes douzaine de schémas, qui se répètent dans des milliers de dossiers, à l'encontre de milliers de défendeurs. Les avocats des plaignants ont en effet systématisé la détection de bogues que les équipes d'ingénieurs n'ont pas repérés, car celles-ci n'ont pas effectué leurs propres tests avec un lecteur d'écran.

Le phénomène des 97 jours

Sur les 8 788 dossiers du corpus, 6 945 avaient été clôturés en avril 2026 et comportaient des dates de dépôt et de clôture valides. La durée de ces dossiers constitue l'une des distributions les plus révélatrices du corpus. Le délai médian entre le dépôt de la plainte et la clôture est de 97 jours; 83,4 % de toutes les clôtures interviennent en moins de six mois.

Fig. 4 Répartition de la durée des dossiers, du dépôt à la clôture, n = 6 945
7.7%
< 30d534
37.6%
30–90j2 609
38.1%
90–180j2 643
12.6%
180–365d872
3.3%
1–2y227
0.9%
>2 ans et 60 jours

Les affaires qui sont closes en moins de 180 jours ne donnent, presque sans exception, lieu à aucune décision au fond publiée. Elles font l'objet d'un règlement à l'amiable. La forme de cette répartition illustre la stratégie globale des avocats des plaignants : intenter un grand nombre d'actions, parvenir rapidement à un accord et éviter la poignée de décisions de fond qui permettraient aux défendeurs de distinguer leurs règlements de ceux d'une autre entreprise. Le règlement médian intervient avant que l'une ou l'autre des parties ne dépose une requête en irrecevabilité.

Pourquoi cela est-il important sur le plan opérationnel ?

Les affaires étant jugées rapidement, il n'existe pas de jurisprudence contraignante précisant ce que recouvre la notion de « caisse accessible » au niveau de détail qu'un ingénieur senior pourrait souhaiter. La norme est plutôt définie par l'ensemble des accords de règlement, dont la plupart exigent la conformité aux WCAG 2.1 AA, un audit annuel et un plan de mise en conformité. Les entreprises paient pour se conformer à une norme établie dans des contrats privés, mais qui n'a jamais fait l'objet d'une décision judiciaire dans des arrêts publiés.

Le modèle de volume : dix plaignants, 1 289 affaires

Le chiffre avancé – 8 788 affaires – est trompeur s'il n'est pas accompagné d'une ventilation plus détaillée. La partie plaignante est en effet très concentrée. Les dix plaignants les plus actifs de l'échantillon représentent à eux seuls 14,7 % de l'ensemble des actions intentées. Le plaignant le plus prolifique a intenté à lui seul 256 actions distinctes.

Fig. 5 Les 10 principaux plaignants en nombre d'affaires fédérales (anonymisés)
#Demandeur (anonymisé)Cas% du total
01Le demandeur A – celui qui a déposé le plus grand nombre de requêtes dans l'ensemble de données
2562.91%
02Le demandeur B
2072.36%
03Le demandeur C
1581.80%
04Le demandeur D
1311.49%
05Le demandeur E
1211.38%
06Le demandeur F
1151.31%
07Le demandeur G
991.13%
08Le demandeur H
971.10%
09Demandeur I
941.07%
10Le demandeur J
860.98%

Les noms des plaignants ont été masqués ; les chiffres sont tirés des métadonnées PACER. Sur les 8 788 dossiers déposés, les dix principaux plaignants ont intenté à eux tous 1 289 actions (14,66 %). Le principal plaignant figure comme partie citée dans près d'une affaire sur 35 dans l'ensemble de données.

Cette concentration n’est pas un signe de mauvaise foi : bon nombre de ces plaignants souffrent de handicaps légitimes et avérés, et ont eux-mêmes été confrontés aux obstacles décrits dans leurs requêtes. Mais elle montre bien que les défendeurs qui perdent devant les tribunaux le font rarement face à un inconnu. On retrouve sans cesse les mêmes noms, souvent représentés par les mêmes cabinets, qui déposent des requêtes rédigées selon des modèles quasi identiques. La structure du contentieux récompense l’efficacité du côté des plaignants et la capitulation du côté des défendeurs. Elle ne récompense les arguments novateurs de l’une ou l’autre partie.

La matrice de triage

Si la question est « par quoi dois-je commencer ? », la réponse dépend de deux facteurs : la fréquence à laquelle un obstacle donné est mentionné (fréquence) et la mesure dans laquelle il bloque directement une transaction (gravité). Le tableau ci-dessous combine ces deux éléments. Les cellules sont colorées en fonction du volume relatif de mentions dans notre corpus de 4 050 transactions de paiement, les cellules les plus foncées représentant les modes de défaillance qui méritent le plus d'être traités lors d'un sprint.

Fig. 6 Matrice défaillance × stade (densité de citations)
Type de défaillance Ajouter au panier Panier Adresse Paiement Confirmation
Statut non communiqué Élevé Élevé Méd. Méd. Élevé
Champs sans libellé Faible Élevé Élevé
Erreurs non signalées Faible Méd. Élevé Élevé Méd.
Perte de mode / de focus Élevé Élevé Méd. Méd. Méd.
Dysfonctionnement du clavier Méd. Méd. Faible Élevé Faible
Retour forcé en cas d'erreur Faible Méd. Méd.
Inaccessibilité du CAPTCHA Faible Méd.
Peu souvent cité Faible Moyen Élevé Très élevé

Deux cas méritent d'être soulignés. « Statut non indiqué × Ajouter au panier » est l'obstacle le plus fréquemment cité dans l'ensemble des données ; si vous ne devez corriger qu'une seule chose, corrigez celle-ci. « Champs non libellés × Paiement » est l'exemple type d'un manquement aux règles de conformité : un formulaire de paiement par carte bancaire comportant des champs présentés comme vides constitue une infraction incontestable.

Combien cela vous coûte-t-il aujourd'hui, avant toute procédure judiciaire ?

Le risque de litige est l'un des coûts liés à un processus de paiement inaccessible. L'autre – généralement plus important et toujours présent – concerne les commandes qui ne sont jamais finalisées parce que l'acheteur n'a pas pu remplir le formulaire. Le calculateur ci-dessous utilise trois paramètres que vous pouvez modifier pour estimer ce coût pour votre propre entonnoir de conversion. Les valeurs par défaut sont prudentes et s'appuient sur des références intersectorielles ; adaptez-les à votre activité.

Modèle d'exposition « Inaccessible-checkout »

Tous les champs de saisie sont des curseurs. Les chiffres s'actualisent en temps réel à mesure que vous les modifiez. Il ne s'agit en aucun cas d'une estimation officielle, mais d'un modèle approximatif destiné à servir de base à une analyse plus rigoureuse.

Commandes mensuelles bloquées
650
les utilisateurs de lecteurs d'écran ou de clavier qui abandonnent
Perte de recettes mensuelles
$78,000
à l'AOV que vous avez fourni
Chiffre d'affaires annuel menacé
$936,000
projection linéaire, sans hypothèse de croissance

Méthodologie. Selon les estimations de WebAIM et de la BOIA, l'utilisation active de lecteurs d'écran concernerait environ 1 à 3 % des internautes américains ; ce chiffre augmente si l'on inclut les utilisateurs qui se servent uniquement du clavier ou ceux souffrant de troubles moteurs. Le taux de blocage de 65 % correspond à la limite supérieure de la mesure réalisée par WebAIM Million pour 2024, qui évalue la fréquence à laquelle une analyse de la page d'accueil révèle au moins un obstacle bloquant (95,9 %) ; les obstacles au paiement ont généralement une portée plus restreinte. Utilisez vos propres données si vous en disposez. Ce modèle exclut les risques de litige, le coût pour la marque et la valeur des clients perdus définitivement après un échec de paiement – autant de facteurs qui alourdissent les chiffres présentés.

À quoi ressemble, en revanche, un processus de paiement accessible

Le tableau comparatif ci-dessous met en correspondance les modes de défaillance les plus fréquemment cités dans l'ensemble de données avec le modèle d'ingénierie permettant de résoudre chacun d'entre eux. Aucun des modèles présentés à droite n'est hypothétique : chacun d'entre eux correspond à une technique WCAG 2.2 AA documentée.

Ce contre quoi les plaignants ont intenté une action

  • Le message « Ajouter au panier » s'affiche sans role="status" région ; les services d'aide technique ne sont pas informés
  • Le champ de saisie CVC ne contient qu'un texte de remplacement – pas de code <label>
  • La fenêtre contextuelle de confirmation d'adresse s'ouvre, mais le focus reste sur le bouton « Continuer » précédent
  • La validation en ligne s'affiche en rouge sous le champ ; le lecteur d'écran ne la lit pas
  • Boutons PayPal / Apple Pay affichés sous la forme <div> avec un gestionnaire de clic ; sans écouteur d'événements clavier
  • Si l'envoi échoue, la page se recharge et le formulaire est effacé ; l'utilisateur doit alors recommencer depuis le champ « Nom » et « E-mail ».

En quoi consiste un processus de paiement accessible ?

  • « Article ajouté » annoncé via aria-live="polite" région ou role="status"
  • Chaque entrée encapsulée dans un élément associé par programmation <label> – « placeholder » n'est pas une étiquette
  • La fenêtre modale s'ouvre, le focus se place sur l'en-tête de la boîte de dialogue, le focus est bloqué, la touche Échap rétablit le focus précédent
  • Erreurs signalées via aria-describedby et le champ reçoit aria-invalid="true"
  • Les boutons de paiement sont bien réels <button> éléments dont le contour de focus visible est ≥ 2 px
  • Les erreurs s'affichent directement à l'écran ; les champs précédemment valides restent renseignés ; la page n'est pas réinitialisée dans son intégralité

La liste de contrôle en treize étapes pour la remise en état

Les éléments ci-dessous, tirés des tendances observées dans la densité des citations au sein de l'ensemble de données, sont classés par ordre décroissant de fréquence d'apparition dans les documents déposés au stade de la conclusion de la transaction. En parcourant cette liste de haut en bas, on couvre la grande majorité des allégations invoquées dans une plainte déposée par un plaignant récidiviste.

Mesures correctives visant à réduire le risque de litige, classées par fréquence de citation

  1. Indiquer si l'article a été ajouté au panier. Ajouter un élément masqué role="status" zone interactive ; affichez-y le message « Article ajouté – N articles dans le panier » à chaque ajout réussi.
  2. Attribuez un libellé à chaque champ de saisie par programmation. Vérifiez votre validation par rapport à un scan Axe-Core ou WAVE ; résolvez chaque label-missing Règle. Les espaces réservés ne sont jamais des étiquettes.
  3. Signaler les erreurs concernant les bons de réduction et les promotions. Erreur de lien <span> éléments à l'entrée via aria-describedby; ajouter aria-invalid="true" en cas d'échec de la validation.
  4. Placez le focus dans les fenêtres modales. Lorsqu'une boîte de dialogue de confirmation s'ouvre, placez le focus sur le titre ou sur le premier élément interactif. À la fermeture, replacez le focus sur l'élément déclencheur.
  5. Rester dans les fenêtres modales actives. Dans une boîte de dialogue ouverte, les touches Tab et Maj+Tab permettent de passer d'un élément à l'autre ; la touche Échap permet de la fermer.
  6. Transformez les boutons de paiement en véritables boutons. Remplacer tout <div onclick> des interfaces pour PayPal, Apple Pay, Google Pay et « Passer la commande » avec <button> éléments. Ajouter des styles de mise en évidence visibles ≥ 2 px.
  7. Marquez les champs obligatoires de manière sémantique. Ajouter aria-required="true" et un indicateur « Obligatoire » bien visible. Regroupez les champs obligatoires liés à <fieldset>.
  8. Conserver l'état du formulaire en cas d'échec de la validation. Les erreurs ne doivent pas effacer les champs correctement remplis. Retourner directement au formulaire ; placer le curseur sur le premier champ non valide.
  9. Indiquez les conditions de réussite. Les mentions « Commande passée » et « Remise appliquée » doivent être transmises au logiciel d'assistance via le même role="status" fonctionnalité « Ajouter au panier ».
  10. Utilisez un CAPTCHA accessible. Si vous devez en utiliser un, prévoyez au minimum une solution de secours audio et le mode d'accessibilité de reCAPTCHA. Mieux encore : remplacez-le par une vérification invisible ou comportementale.
  11. Veillez à ce que les indicateurs d'étape aient un sens. Si votre processus de paiement comporte plusieurs étapes, présentez-les sous la forme d'une <nav aria-label="Checkout progress"> avec un <ol> et aria-current="step".
  12. Testez avec un véritable lecteur d'écran. Effectuez le processus de paiement de bout en bout avec NVDA + Firefox ou VoiceOver + Safari. Les analyses automatisées ne détectent pas environ la moitié des obstacles que vos utilisateurs rencontreront.
  13. Apportez la correction au niveau du système de conception. La plupart des erreurs de validation proviennent des composants partagés (Modal, Input, Toast). Corriger le composant une seule fois permet d'appliquer la correction à toutes les validations qui l'utilisent ; ce n'est pas le cas si l'on corrige la page une seule fois.
Un modèle qu'il convient d'assimiler

Les obstacles rencontrés lors de la phase de paiement se regroupent en cinq éléments : la fenêtre contextuelle, la fenêtre modale, le champ de saisie, le message d'erreur et le bouton de validation. Si ces cinq éléments sont testés individuellement à l'aide d'un lecteur d'écran avant même d'être intégrés à la page de paiement, l'ensemble des plaintes recensées dans le corpus se réduit à une longue traîne. C'est au niveau du système de conception que réside le levier d'action. Les poursuites judiciaires, malheureusement, se situent au niveau de la page – et sont notifiées par courrier recommandé.

Conclusion – la question technique, reformulée

La thèse défendue dans cet article – selon laquelle la page de paiement est l'élément le plus souvent visé par des poursuites judiciaires sur Internet – ne repose pas sur le nombre de plaintes déposées, bien que celui-ci soit impressionnant. Elle repose sur la structure du parcours utilisateur. De toutes les interfaces d'un site web commercial, la page de paiement est celle dont la défaillance correspond le plus précisément à la définition juridique d'un déni de service, celle dont les préjudices se traduisent le plus clairement en plainte, et celle dont les bugs sont les plus récurrents chez les défendeurs. Aucun de ces faits ne changera en 2027. Ce qui peut changer, ce sont les choix techniques qui les génèrent.

À y regarder de plus près, les 4 050 problèmes répertoriés dans cet article n’ont rien de mystérieux. Il s’agit toujours des mêmes cinq ou six défaillances provenant des mêmes cinq ou six composants. La solution la plus efficace qu’un commerçant puisse mettre en œuvre ne se trouve pas sur la page de paiement, mais au niveau du système de conception qui génère cette page. Corrigez la notification, la fenêtre modale, le champ de saisie, le message d'erreur et le bouton de validation – une seule fois, dans la bibliothèque de composants – et l'ensemble de données sur lequel s'appuie cet article s'allégera d'un ordre de grandeur. Les plaignants passeront à autre chose. Vos clients, eux, resteront.

ARCHIVÉ · ANALYSÉ · ARCHIVÉ À NOUVEAU

Sources et méthodologie

Les métadonnées relatives aux affaires civiles fédérales sont extraites de PACER (Public Access to Court Electronic Records) et couvrent 8 788 affaires liées à l'accessibilité du Web déposées devant les tribunaux de district américains entre janvier 2007 et avril 2026, identifiées à l'aide des codes de plainte du Titre III de l'ADA et d'un filtrage par chaîne de recherche sur le terme « site Web ». Une analyse au niveau des enjeux est effectuée à partir d'un extrait généré par OCR et NLP de ces mêmes dossiers, ce qui a permis de recenser 81 509 mentions distinctes d'enjeux d'accessibilité, classées en 28 taxonomies de surface.

Les références aux WCAG concernent les WCAG 2.1 (la norme la plus citée dans les accords de règlement du secteur privé aux États-Unis) et les WCAG 2.2 (la dernière recommandation publiée en octobre 2023, ratifiée en décembre 2024). Lorsque les documents citent l'EAA, la norme EN 301 549 ou la règle finale du Titre II du DOJ (avril 2024), les critères sont normalisés pour correspondre à leur équivalent WCAG 2.1 AA.

Les noms des plaignants ont été masqués dans cet article. Tous les plaignants existent réellement et leurs dossiers sont accessibles au public sur PACER. La synthèse présentée ici est fournie à des fins d'analyse ; les dossiers originaux peuvent être consultés par tout lecteur souhaitant vérifier un document spécifique.

Le calculateur d'exposition présenté au §11 est donné à titre indicatif. Les enquêtes menées par WebAIM auprès des utilisateurs de lecteurs d'écran (2014-2024) et l'audit annuel des pages d'accueil réalisé par WebAIM Million constituent les principales références du secteur pour estimer la part de visiteurs et la fréquence des obstacles. Adaptez les paramètres par défaut du calculateur à vos propres données analytiques, si vous en disposez.

Référence : AIOPSGROUP Accessibility Intelligence (2026). Le processus de paiement en ligne : le domaine le plus litigieux sur Internet. Numéro 04:12.