En 2025, les plaignants ont déposé 3 117 poursuites pour l'accessibilité des sites web en vertu du titre III de l'ADA devant les tribunaux fédéraux — un bond de 27 % par rapport à 2024 et le chiffre annuel le plus élevé depuis 2022. En ajoutant les dépôts devant les tribunaux d'État, le total dépasse les 5 000. Même ce chiffre global sous-estime la pression : les avocats de la défense estiment que 35 000 à 50 000 mises en demeure pour cause d'inaccessibilité ont été envoyées à des entreprises américaines l'année dernière, dont la plupart se règlent à l'amiable pour un montant compris entre 1 000 sans jamais apparaître dans un registre.
Si votre entreprise exploite un site web, une application mobile, une boutique en ligne, un widget de réservation ou un portail client, vous êtes désormais une cible réaliste. Et les plaignants en série ne se limitent plus à un petit groupe de déposants récurrents — environ 40 % des dépôts fédéraux au titre de l'ADA Titre III en 2025 provenaient de personnes se représentant elles-mêmes, dont beaucoup utilisent des scanners alimentés par l'IA pour identifier les défendeurs potentiels et rédiger des plaintes en quelques minutes.
Ce guide détaille ce que le titre III de l'ADA exige réellement pour les expériences numériques, pourquoi le WCAG 2.1 Niveau AA est devenu la référence de facto, à quoi ressemble une feuille de route de mise en conformité et comment constituer un dossier défendable avant l'arrivée d'une mise en demeure.
Pourquoi votre site web est désormais concerné par le titre III de l'ADA
Le titre III de l'Americans with Disabilities Act interdit la discrimination fondée sur le handicap dans les lieux publics (« places of public accommodation »). La loi a été rédigée en 1990 et ne mentionnait jamais explicitement les sites web ou les applications mobiles — mais les tribunaux ont passé la dernière décennie à lever cette ambiguïté, presque toujours en faveur des plaignants.
L'héritage de l'affaire Robles contre Domino's Pizza
L'affaire la plus importante est Robles v. Domino's Pizza. Guillermo Robles, un plaignant aveugle en Californie, a poursuivi Domino's en 2016 après avoir découvert qu'il ne pouvait pas utiliser le site web ou l'application mobile de la chaîne de pizzas avec un lecteur d'écran. Le tribunal de district a d'abord rejeté l'affaire pour des motifs de procédure régulière, estimant qu'en l'absence de réglementations publiées sur l'accessibilité du web, Domino's n'avait pas reçu de préavis équitable sur les exigences de conformité.
Le Neuvième Circuit a infirmé cette décision en 2019. La cour a statué que le titre III couvrait le site web et l'application de Domino's parce qu'ils présentaient un lien avec un lieu physique ouvert au public (les restaurants de pizzas), et que l'engagement de la responsabilité ne violait pas la procédure régulière, même sans normes techniques publiées. La Cour suprême a refusé de réviser la décision du Neuvième Circuit plus tard cette année-là, laissant la règle en vigueur. Domino's a finalement conclu un accord en juin 2022 après six ans de litige.
L'effet pratique est que toute entreprise disposant d'un emplacement physique — et, dans de nombreux circuits judiciaires, même les entreprises exclusivement en ligne — fait désormais face à une exposition réelle pour un site web inaccessible.
La règle du titre II du DOJ de 2024 et ses répercussions sur le titre III
En avril 2024, le ministère de la Justice (DOJ) a publié une règle finale en vertu du titre II de l'ADA exigeant que les sites web et les applications mobiles des gouvernements étatiques et locaux soient conformes au WCAG 2.1 Niveau AA. Bien que cette règle ne lie formellement que les entités publiques, les plaignants et les tribunaux ont immédiatement commencé à la citer comme l'articulation fédérale la plus autorisée de ce que signifie « accessible ».
Pour une entreprise privée, le calcul juridique a changé du jour au lendemain. Même si le titre III n'a toujours pas de norme technique publiée, un plaignant peut désormais pointer du doigt un règlement fédéral contraignant qui désigne le WCAG 2.1 Niveau AA comme la norme pour des entités du titre II matériellement similaires. La plupart des avocats de la défense conseillent désormais à leurs clients relevant du titre III de considérer le WCAG 2.1 Niveau AA comme le seuil minimal.
Ce que le WCAG 2.1 Niveau AA exige réellement
Le WCAG (Web Content Accessibility Guidelines), maintenu par le World Wide Web Consortium, est organisé autour de quatre principes, commodément résumés par l'acronyme POUR : Perceptible, Utilisable, Compréhensible et Robuste. Le niveau AA comprend tous les critères de réussite du niveau A plus des critères spécifiques au niveau AA. Il existe 50 critères de réussite au total pour le niveau AA, mais une poignée d'entre eux génère l'écrasante majorité des mises en demeure.
Contraste des couleurs (1.4.3 et 1.4.11)
Le corps du texte doit avoir un rapport de contraste d'au moins 4,5:1 par rapport à son arrière-plan. Le texte de grande taille (18 points ou 14 points en gras) nécessite au moins 3:1. Les boutons, les bordures de champs de formulaire, les indicateurs de focus et les autres éléments graphiques interactifs doivent respecter un rapport de 3:1 par rapport aux couleurs adjacentes. De nombreuses mises en demeure trouvent leur origine ici car les scanners automatisés détectent les défauts de contraste en quelques secondes.
Alternatives textuelles pour le contenu non textuel (1.1.1)
Chaque image, icône, graphique, photo et illustration porteuse de sens nécessite un attribut alt qui transmet la même information. Les images décoratives reçoivent un attribut alt vide (alt="") afin que les lecteurs d'écran les ignorent. Les logos doivent décrire la marque. Les graphiques et infographies nécessitent un équivalent textuel plus long à proximité ou lié. Les icônes de saisie de formulaire ont besoin d'étiquettes. Les CAPTCHA nécessitent une alternative audio.
<img src="background-pattern.png" alt="">
<img src="quarterly-earnings-chart.png" alt="Graphique à barres montrant une augmentation de 15 % des revenus au T3">
### Accessibilité au clavier (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Chaque élément interactif — menus, fenêtres modales, carrousels, accordéons, onglets, menus déroulants personnalisés — doit être accessible et utilisable uniquement à l'aide du clavier. Les utilisateurs ne doivent jamais être piégés à l'intérieur d'un widget sans issue (l'échec classique de la « modale qui ne se ferme pas sans souris »). L'ordre de focalisation doit être logique et un indicateur de focus visible doit toujours indiquer où se trouve l'utilisateur sur la page.
### Étiquettes de formulaires, erreurs et instructions (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Chaque entrée de formulaire nécessite une étiquette associée par programmation (un élément `<label for="">` ou un aria-label). Les messages d'erreur doivent identifier le champ en échec et indiquer ce qu'il faut faire. Pour les formulaires à enjeux élevés (paiement, création de compte, reconnaissances juridiques), les utilisateurs doivent avoir la possibilité de réviser et de corriger les informations avant l'envoi.
### Sous-titres et descriptions audio (1.2.2, 1.2.5)
Les vidéos pré-enregistrées nécessitent des sous-titres synchronisés. Si des informations essentielles sont transmises visuellement et non par la piste audio, vous avez également besoin de descriptions audio. La vidéo en direct au niveau AA nécessite des sous-titres en direct.
### Structure des titres et points de repère (1.3.1, 2.4.6)
Les titres doivent suivre une hiérarchie logique (`h1` → `h2` → `h3`, sans sauter de niveaux arbitrairement). Utilisez des éléments HTML sémantiques — `<nav>`, `<main>`, `<header>`, `<footer>` — ou des points de repère ARIA afin que les utilisateurs de lecteurs d'écran puissent accéder directement à la section souhaitée. Évitez de styliser une `<div>` pour qu'elle ressemble à un titre sans lui donner le rôle sémantique approprié.
### Redimensionnement et réorganisation (1.4.4, 1.4.10)
Le texte doit rester lisible à un zoom de 200 % sans défilement horizontal. Les mises en page doivent se réorganiser sur une fenêtre d'affichage de 320 pixels CSS sans défilement bidimensionnel.
## Où se concentrent les litiges
Trois districts fédéraux concentrent l'essentiel des dépôts de plaintes concernant l'accessibilité des sites web : le Southern District de New York, le Central District de Californie et le Southern District de Floride. New York arrive largement en tête, en partie parce que la loi sur les droits de l'homme de l'État de New York (New York State Human Rights Law) et celle de la ville de New York (New York City Human Rights Law) offrent des leviers juridiques supplémentaires et des exigences de plaidoirie moindres par rapport aux réclamations fédérales au titre de l'ADA.
La Californie ajoute l'Unruh Civil Rights Act, qui prévoit 4 000 $ de dommages-intérêts légaux par violation et par plaignant. Cela modifie radicalement le calcul des règlements — une petite réclamation peut rapidement se transformer en un risque financier à six chiffres si un recours collectif est certifié.
La Floride est devenue le troisième pôle depuis 2020, avec une poignée de cabinets de plaignants développant des pratiques à gros volume ciblant les chaînes de restaurants, les marques d'hôtellerie et les boutiques de commerce électronique directes aux consommateurs.
## Élaborer une feuille de route de remédiation
Si vous recevez une mise en demeure — ou, mieux, si vous agissez avant qu'une ne survienne — le travail se décompose en environ cinq phases. Traitez cela comme un projet avec un budget et une date limite, et non comme un audit ponctuel.
### Phase 1 : Audit automatisé et manuel
Commencez par un balayage automatisé à l'aide d'un outil comme axe DevTools, WAVE ou Google Lighthouse. Les outils automatisés détectent entre 30 et 50 % des échecs aux WCAG — le reste nécessite des tests manuels avec un lecteur d'écran (NVDA sur Windows, VoiceOver sur macOS et iOS, TalkBack sur Android), une navigation au clavier uniquement, et des tests de zoom et de réorganisation.
Documentez chaque échec avec le critère WCAG violé, la page ou le modèle affecté, la gravité et un effort de remédiation estimé. Ce journal d'audit devient la colonne vertébrale de chaque phase ultérieure.
### Phase 2 : Corrections du système de conception et des composants
La plupart des échecs les plus fréquents résident dans votre système de conception (design system) : contraste des boutons, indicateurs de focus, champs de formulaire, modèles de modales, contrôles de carrousel, menus de navigation. Corriger le composant une seule fois corrige toutes ses occurrences. Donnez la priorité aux composants qui apparaissent sur le plus grand nombre de pages.
### Phase 3 : Nettoyage du contenu
Le texte alternatif, les sous-titres vidéo, la structure des titres et les étiquettes de formulaire sont généralement des corrections au niveau du contenu qui touchent la plupart des modèles et des pages. Établissez une liste de contrôle du contenu que les auteurs doivent suivre pour chaque nouvelle page et une tâche de fond (backlog) pour corriger rétroactivement les pages existantes.
### Phase 4 : Coordination des fournisseurs tiers
La plupart des sites web modernes intègrent des widgets tiers : formulaires de paiement, chat en direct, calendriers de réservation, lecteurs vidéo, superpositions d'analyses, widgets d'avis et fenêtres contextuelles de capture d'e-mails. Chacun d'entre eux peut introduire ses propres défauts d'accessibilité, et les tribunaux relevant du Titre III ont généralement estimé qu'une entreprise est responsable de l'accessibilité du code fournisseur qu'elle intègre sur son propre site.
Pour chaque fournisseur, demandez un VPAT (Voluntary Product Accessibility Template) actuel ou un rapport de conformité sur l'accessibilité (ACR). Vérifiez que la version qu'ils livrent répond au niveau AA de la norme WCAG 2.1. Poussez les fournisseurs qui ne sont pas à la hauteur à remédier à la situation, ou changez-en.
### Phase 5 : Déclaration d'accessibilité et canal de rétroaction
Publiez une déclaration d'accessibilité clairement liée qui mentionne la norme que vous visez à respecter (typiquement WCAG 2.1 Niveau AA), les limitations connues et un canal de contact (e-mail et téléphone) pour que les utilisateurs signalent les problèmes d'accessibilité. La déclaration n'offre pas d'immunité juridique, mais elle atteste d'une démarche de bonne foi et donne aux destinataires de mises en demeure un élément concret sur lequel s'appuyer.
## Un mot sur les overlays d'accessibilité
Une industrie en plein essor d'outils de « superposition d'accessibilité » (accessibility overlays) — des widgets JavaScript qui promettent une conformité instantanée aux WCAG via une seule ligne de code — prétend résoudre l'accessibilité rapidement et à moindre coût. La réalité est plus complexe. Les overlays ont été cités dans des dizaines de poursuites judiciaires comme étant eux-mêmes à l'origine de problèmes d'accessibilité en interférant avec les technologies d'assistance des utilisateurs. Plusieurs tribunaux ont rejeté l'argument selon lequel un overlay seul suffit à rejeter une plainte au titre du Titre III.
Les overlays peuvent jouer un rôle de complément à une remédiation de fond — pour les utilisateurs qui ont besoin d'appliquer leurs propres préférences sur un site déjà accessible — mais ils ne remplacent pas la correction du code source. Les cabinets d'avocats de demandeurs ciblent désormais spécifiquement les sites utilisant certains produits d'overlay.
## Tout documenter pour assurer sa défense
Lorsqu'une mise en demeure arrive, votre stratégie de défense dépend presque entièrement de ce que vous pouvez prouver concernant votre programme d'accessibilité au moment de la violation présumée. Constituez une piste d'audit qui comprend :
- Des rapports d'audit datés indiquant le périmètre et les conclusions
- Des tickets de remédiation avec les dates de clôture
- Les VPAT des fournisseurs et les rapports de conformité en matière d'accessibilité
- Les registres de formation pour les designers et les développeurs
- Des listes de contrôle internes de révision de l'accessibilité liées aux lancements de produits
- Un journal des modifications pour la déclaration d'accessibilité
- Les commentaires des utilisateurs reçus via votre canal de contact dédié à l'accessibilité et votre réponse à ceux-ci
Ces dossiers n'empêchent pas les poursuites, mais ils modifient radicalement les négociations de règlement. Un plaignant espérant un règlement rapide de 10 000 $ pour nuisance est beaucoup moins intéressé lorsque le défendeur peut produire un audit récent, un carnet de remédiation documenté et un VPAT de fournisseur pour chaque widget intégré.
## L'aspect comptable de la conformité en matière d'accessibilité
La remédiation de l'accessibilité est rarement une dépense ponctuelle. Elle apparaît généralement dans vos livres comme une dépense récurrente — factures d'agences ou de prestataires pour les audits, licences logicielles pour les outils de test et les services de surveillance, coûts de reconstruction du système de design, coûts de changement de fournisseur et les inévitables règlements de mises en demeure qui passent à travers les mailles du filet malgré vos meilleurs efforts.
Le suivi de ces dépenses séparément des dépenses générales de marketing ou d'ingénierie facilite plusieurs choses. Vous obtenez une vision claire du coût réel de la conformité au fil du temps, ce qui aide à la budgétisation du programme de l'année suivante. Vous documentez la dépense si vous devez plus tard demander une déduction ou amortir une amélioration de site Web capitalisée. Et si vous faites face à un recours collectif de la part d'un plaignant en série, vous pouvez rapidement produire un relevé financier de votre investissement de bonne foi dans l'accessibilité — utile tant dans les négociations de règlement que dans toute défense de modification raisonnable.
Un simple segment de plan comptable pour la « Conformité à l'accessibilité » avec des sous-catégories pour les audits, la main-d'œuvre de remédiation, les outils de test, la diligence raisonnable des fournisseurs et les réserves pour règlements est très utile. Couplez-le à des examens trimestriels pour que le programme ne dérive pas discrètement hors du budget.
## Erreurs courantes à éviter
Quelques schémas apparaissent dans presque toutes les mises en demeure que je vois passer.
**Traiter l'accessibilité comme un projet ponctuel.** Les sites changent constamment. Une nouvelle page produit, un tunnel de commande repensé, un chatbot intégré — n'importe lequel de ces éléments peut introduire de nouveaux défauts. Intégrez l'accessibilité dans votre cycle de vie de développement afin que chaque changement soit vérifié avant son déploiement.
**Se fier entièrement aux scans automatisés.** Les outils automatisés ne détectent qu'une minorité des échecs aux WCAG. Les tests manuels avec des technologies d'assistance sont le seul moyen de trouver des problèmes tels qu'un ordre de tabulation illogique, des textes alternatifs trompeurs ou des widgets personnalisés inutilisables.
**Ignorer les applications mobiles.** Les plaignants au titre du Titre III déposent de plus en plus de plaintes doubles couvrant à la fois le site Web et l'application mobile native. iOS et Android ont chacun leurs propres API d'accessibilité (UIAccessibility et TalkBack/AccessibilityService), et les mêmes principes WCAG s'appliquent mais nécessitent des tests spécifiques à la plateforme.
**Oublier les PDF.** Les formulaires fiscaux, les livres blancs, les menus et les ressources téléchargeables hébergés sur votre site sont tous concernés. Les PDF ont besoin d'un ordre de lecture approprié, de balises (tags), de textes alternatifs et d'étiquettes de champs de formulaire, tout comme les pages HTML.
**Supposer qu'une plateforme tierce s'en occupe pour vous.** Shopify, WordPress, Wix, Squarespace et d'autres plateformes similaires fournissent une certaine structure d'accessibilité, mais les choix de thèmes, le code personnalisé, les widgets intégrés et le contenu que vous publiez restent sous votre responsabilité. Une mise en demeure ne se soucie pas de savoir si un thème était pré-construit ou non.
**Omettre la déclaration d'accessibilité.** Sa publication ne coûte rien et constitue une preuve manifeste de bonne foi. Son absence est parfois spécifiquement citée dans les plaintes.
## Gardez les finances de votre conformité organisées dès le premier jour
À mesure que vous construisez votre programme d'accessibilité, les justificatifs financiers — factures d'audit, accords de fournisseur, main-d'œuvre de remédiation, coûts de formation et réserves pour règlements — doivent être conservés là où vous pourrez les retrouver dans plusieurs années si un plaignant en série s'en prend à votre entreprise. [Beancount.io](https://beancount.io) propose une comptabilité en texte brut qui vous offre une transparence totale et un historique géré par versionnage pour chaque écriture, sans boîte noire ni dépendance envers un fournisseur. [Commencez gratuitement](https://beancount.io) et découvrez pourquoi les développeurs, les équipes financières et les gestionnaires soucieux de la conformité choisissent la comptabilité en texte brut pour tenir un registre défendable en cas d'audit.