En 2025, les plaignants ont déposé 3 117 poursuites pour accessibilité de sites web en vertu du Titre III de l'ADA devant les tribunaux fédéraux — une hausse 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 phare sous-estime la pression : les avocats de la défense estiment que 35 000 à 50 000 lettres de mise en demeure pour accessibilité ont été envoyées aux entreprises américaines l'année dernière, dont la plupart sont réglées à l'amiable entre 1 000 et 25 000 dollars sans jamais apparaître dans un registre judiciaire.
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 récidivistes — environ 40 % des dépôts fédéraux de 2025 en vertu du Titre III de l'ADA provenaient de personnes se représentant elles-mêmes, dont beaucoup utilisent des scanners basés sur l'IA pour identifier des défendeurs potentiels et rédiger des plaintes en quelques minutes.
Ce guide explique ce qu'exige réellement le Titre III de l'ADA pour les expériences numériques, pourquoi le niveau WCAG 2.1 AA est devenu la référence de facto, à quoi ressemble une feuille de route de remédiation, et comment constituer un dossier défendable avant qu'une lettre de mise en demeure n'arrive.
Pourquoi votre site web est désormais dans le champ d'application du 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. La loi a été rédigée en 1990 et n'a jamais mentionné explicitement les sites web ou les applications mobiles — mais les tribunaux ont passé la dernière décennie à résoudre cette ambiguïté, presque toujours en faveur des plaignants.
L'héritage de Robles c. Domino's Pizza
L'affaire la plus importante est Robles c. 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 initialement rejeté l'affaire pour des motifs de procédure équitable, estimant qu'en l'absence de règlements publiés sur l'accessibilité web, Domino's n'avait pas été averti de manière équitable de ce qu'exigeait la conformité.
La Neuvième Circuit a inversé cette décision en 2019. Le tribunal a statué que le Titre III couvrait le site web et l'application de Domino's parce qu'ils avaient un lien avec un lieu public physique (les restaurants de pizzas), et qu'imposer une responsabilité ne violait pas la procédure équitable même en l'absence de normes techniques publiées. La Cour suprême a refusé d'examiner la décision de la Neuvième Circuit plus tard cette année-là, laissant la règle en place. Domino's a finalement réglé en juin 2022 après six ans de litige.
L'effet pratique est que toute entreprise ayant un emplacement physique — et, dans de nombreux circuits, même les entreprises purement en ligne — fait désormais face à une exposition réelle pour un site web inaccessible.
La règle du Titre II de 2024 du DOJ et ses répercussions sur le Titre III
En avril 2024, le ministère de la Justice a publié une règle finale en vertu du Titre II de l'ADA exigeant que les sites web et applications mobiles des gouvernements étatiques et locaux se conforment au niveau WCAG 2.1 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 autoritaire 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 une réglementation fédérale contraignante qui nomme le niveau WCAG 2.1 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 du Titre III de traiter le niveau WCAG 2.1 AA comme le plancher.
Ce qu'exige réellement le niveau WCAG 2.1 AA
Les WCAG — Web Content Accessibility Guidelines, maintenues par le World Wide Web Consortium — sont organisées autour de quatre principes, commodément résumés par l'acronyme POUR : Percevable, Utilisable, Compréhensible et Robuste. Le niveau AA comprend chaque critère de succès du niveau A plus des critères supplémentaires spécifiques au niveau AA. Il y a 50 critères de succès au total au niveau AA, mais une poignée entraîne la grande majorité des lettres de mise en demeure.
Contraste des couleurs (1.4.3 et 1.4.11)
Le texte du corps 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) doit avoir au moins 3 : 1. Les boutons, les bordures des champs de formulaire, les indicateurs de focus et autres éléments graphiques interactifs doivent respecter 3 : 1 par rapport aux couleurs adjacentes. Beaucoup de lettres de mise en demeure proviennent d'ici car les scanners automatisés détectent les échecs de contraste en quelques secondes.
Alternatives textuelles pour le contenu non textuel (1.1.1)
Chaque image, icône, graphique, photo et élément graphique porteur de sens doit avoir un attribut alt qui transmet la même information. Les images décoratives reçoivent un attribut alt vide (alt="") pour 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 des champs de formulaire nécessitent des étiquettes. Les CAPTCHA nécessitent une alternative audio.
Opérabilité au clavier (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Chaque élément interactif — menus, modales, carrousels, accordéons, onglets, listes déroulantes personnalisées — doit être accessible et utilisable uniquement avec le 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 focus doit être logique et un indicateur de focus visible doit toujours montrer où se trouve l'utilisateur sur la page.
Étiquettes, erreurs et instructions de formulaire (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Chaque champ de formulaire doit avoir une étiquette associée par programmation (un élément <label for=""> ou aria-label). Les messages d'erreur doivent identifier quel champ a échoué et quoi faire à ce sujet. Pour les formulaires à enjeux élevés (paiement, création de compte, accusés de réception légaux), les utilisateurs doivent avoir la possibilité de vérifier et de corriger avant la soumission.
Sous-titres et audiodescriptions (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 dans la piste audio, vous avez également besoin d'audiodescriptions. Les vidéos en direct au niveau AA nécessitent 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 un <div> pour qu'il 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 poursuites judiciaires
Trois districts fédéraux représentent la majorité des dépôts pour accessibilité de sites web : le district sud de New York, le district central de Californie et le district sud de la Floride. New York mène de loin, en partie parce que la New York State Human Rights Law et la New York City Human Rights Law offrent des motifs supplémentaires au niveau étatique et des exigences de plaidoyer plus faibles que les réclamations fédérales de l'ADA.
La Californie ajoute la loi californienne sur les droits civils Unruh, qui prévoit 4 000 dollars de dommages-intérêts légaux par violation et par plaignant. Cela change radicalement le calcul du règlement — une petite réclamation peut rapidement devenir une exposition à six chiffres si une action collective est certifiée.
La Floride est devenue le troisième pôle depuis 2020, avec quelques cabinets de plaignants développant des pratiques à haut volume ciblant les chaînes de restaurants, les marques hôtelières et les boutiques de commerce électronique direct-au-consommateur.
Construire une feuille de route de remédiation
Si vous recevez une lettre de mise en demeure — ou, mieux, si vous agissez avant qu'elle n'arrive — le travail se décompose en environ cinq phases. Traitez cela comme un projet avec un budget et une échéance, pas comme un audit ponctuel.
Phase 1 : Audit automatisé et manuel
Commencez par une analyse automatisée avec un outil comme axe DevTools, WAVE ou Google Lighthouse. Les outils automatisés détectent entre 30 et 50 % des échecs 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 une estimation de l'effort de remédiation. Ce journal d'audit devient l'épine dorsale de toutes les phases ultérieures.
Phase 2 : Corrections du système de conception et des composants
La plupart des échecs à volume élevé se trouvent dans votre système de conception : contraste des boutons, indicateurs de focus, champs de formulaire, modèles de modales, contrôles de carrousel, menus de navigation. Corriger le composant une fois corrige chaque instance de celui-ci. Priorisez les composants qui apparaissent sur le plus grand nombre de pages.
Phase 3 : Balayage 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 le plus de modèles et de pages. Construisez une liste de contrôle de contenu que les auteurs doivent suivre pour chaque nouvelle page et un élément de backlog pour corriger rétroactivement les pages existantes.
Phase 4 : Coordination avec les 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'analyse, widgets d'avis et pop-ups de capture d'e-mails. Chacun de ces éléments peut introduire ses propres échecs d'accessibilité, et les tribunaux du Titre III ont généralement statué qu'une entreprise est responsable de l'accessibilité du code de fournisseur qu'elle intègre sur son propre site.
Pour chaque fournisseur, demandez un VPAT (Voluntary Product Accessibility Template) ou un rapport de conformité d'accessibilité actuel. Vérifiez que la version qu'ils fournissent respecte le niveau WCAG 2.1 AA. Poussez les fournisseurs qui ne respectent pas les normes à corriger, ou remplacez-les.
Phase 5 : Déclaration d'accessibilité et canal de retour
Publiez une déclaration d'accessibilité clairement liée qui nomme la norme que vous visez à respecter (généralement le niveau WCAG 2.1 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 ne fournit pas d'immunité légale, mais elle documente la bonne foi et donne aux répondants aux lettres de mise en demeure quelque chose de concret à pointer du doigt.
Un mot sur les superpositions d'accessibilité
Une industrie florissante d'outils de « superposition d'accessibilité » — des widgets JavaScript qui promettent une conformité WCAG instantanée via une seule ligne de code — prétend résoudre l'accessibilité rapidement et à moindre coût. La réalité est plus compliquée. Les superpositions ont été citées dans des dizaines de poursuites comme causant elles-mêmes des problèmes d'accessibilité en interférant avec les technologies d'assistance des utilisateurs. Plusieurs tribunaux ont rejeté l'argument qu'une superposition seule suffit pour rejeter une réclamation du Titre III.
Les superpositions peuvent avoir un rôle en complément de la remédiation sous-jacente — pour les utilisateurs qui doivent appliquer leurs propres préférences sur un site déjà accessible — mais elles ne remplacent pas la correction du code sous-jacent. Les cabinets de plaignants ciblent désormais spécifiquement les sites qui utilisent certains produits de superposition.
Tout documenter pour la défense
Lorsqu'une lettre de mise en demeure arrive, votre stratégie de défense dépend presque entièrement de ce que vous pouvez prouver sur votre programme d'accessibilité au moment de la violation présumée. Construisez une trace papier qui comprend :
- Des rapports d'audit datés montrant la portée et les conclusions
- Des tickets de remédiation avec les dates de clôture
- Des VPAT de fournisseurs et des rapports de conformité d'accessibilité
- Des registres de formation pour les concepteurs et développeurs
- Des listes de contrôle internes de revue d'accessibilité liées aux lancements de produits
- Un journal des modifications pour la déclaration d'accessibilité
- Les retours utilisateurs reçus via votre canal de contact d'accessibilité et votre réponse à ceux-ci
Ces registres ne préviennent pas les poursuites, mais ils déplacent radicalement les négociations de règlement. Un plaignant espérant un règlement rapide de nuisance de 10 000 dollars est beaucoup moins intéressé lorsque le défendeur peut produire un audit actuel, un backlog de remédiation documenté et un VPAT de fournisseur pour chaque widget intégré.
Le côté comptable de la conformité à l'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'agence ou d'entrepreneur pour les audits, licences de logiciels pour les outils de test et les services de surveillance, coûts de reconstruction du système de conception, coûts de changement de fournisseur et les inévitables règlements de lettres de mise en demeure qui passent malgré vos meilleurs efforts.
Suivre ces dépenses séparément des dépenses générales de marketing ou d'ingénierie facilite certaines choses. Vous obtenez une vue claire du coût réel de conformité dans le temps, ce qui aide lors de la budgétisation du programme de l'année prochaine. 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 à une action collective de plaignants en série, vous pouvez rapidement produire un registre financier de votre investissement de bonne foi dans l'accessibilité — utile à la fois dans les négociations de règlement et dans toute défense de modification raisonnable.
Un simple segment du plan comptable pour « 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 de règlement va loin. Associez-le à des revues trimestrielles pour que le programme ne dérive pas silencieusement hors du budget.
Erreurs courantes à éviter
Quelques schémas apparaissent dans presque chaque lettre de mise en demeure que je vois recevoir par les propriétaires d'entreprise.
Traiter l'accessibilité comme un projet ponctuel. Les sites changent constamment. Une nouvelle page produit, un paiement redessiné, un chatbot intégré — n'importe lequel de ces éléments peut introduire de nouveaux échecs. Intégrez l'accessibilité dans votre cycle de développement afin que chaque modification soit vérifiée avant d'être publiée.
Se fier entièrement aux analyses automatisées. Les outils automatisés détectent une minorité des échecs WCAG. Les tests manuels avec des technologies d'assistance sont le seul moyen de trouver des problèmes comme un ordre de focus illogique, un texte alternatif trompeur ou des widgets personnalisés inutilisables.
Ignorer les applications mobiles. Les plaignants du Titre III déposent de plus en plus de réclamations 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ées sur votre site sont tous dans le champ d'application. Les PDF nécessitent un ordre de lecture correct, des balises, du texte alternatif et des étiquettes de champ de formulaire tout comme les pages HTML.
Supposer qu'une plateforme tierce s'en occupe pour vous. Shopify, WordPress, Wix, Squarespace et des plateformes similaires fournissent une certaine infrastructure d'accessibilité, mais les choix de thèmes, le code personnalisé, les widgets intégrés et le contenu que vous publiez restent votre responsabilité. Une lettre de mise en demeure ne se soucie pas de savoir si un thème est pré-construit.
Ignorer la déclaration d'accessibilité. Elle ne coûte rien à publier et fournit une preuve démontrable de bonne foi. Son absence est parfois citée spécifiquement dans les plaintes.
Gardez vos finances de conformité organisées dès le premier jour
Alors que vous construisez votre programme d'accessibilité, les registres financiers de soutien — factures d'audit, accords de fournisseurs, main-d'œuvre de remédiation, coûts de formation et réserves de règlement — doivent être conservés dans un endroit où vous pouvez les retrouver des années plus tard si un plaignant en série nomme votre entreprise. Beancount.io fournit une comptabilité en texte brut qui vous donne une transparence complète et un historique versionné sur chaque ligne, sans boîtes noires et sans verrouillage de fournisseur. Commencez gratuitement et découvrez pourquoi les développeurs, les équipes financières et les opérateurs soucieux de conformité choisissent la comptabilité en texte brut pour garder un registre défendable en cas d'audit.