Cherchez « conformité ADA site web » et presque tout ce qui ressort se ressemble : une entrée de glossaire sur ce que veut dire ADA, un paragraphe sur les niveaux A, AA et AAA, une ligne sur le risque de poursuite, et un bouton pour acheter une solution. Rien de tout ça ne vous dit quelles parties de votre propre site comptent vraiment, ni pourquoi la règle qui a fait les manchettes en avril 2026 n’est presque certainement pas celle qui s’applique à vous.
Voici la version qui part plutôt de vos pages. Pas « qu’est-ce que la conformité ADA » — mais ce qui, précisément, sur une page, la rend inaccessible, et ce que la personne qui la construit fait concrètement à ce sujet.
Ce que la conformité ADA d’un site web demande vraiment à une page
Mettez la loi de côté un instant. Peu importe la règle qui s’applique techniquement à vous, voici ce qui rend une page difficile ou impossible à utiliser pour quelqu’un qui dépend d’un clavier, d’un lecteur d’écran ou qui a une vision réduite — et c’est la même liste, que vous soyez couvert par le Titre II, le Titre III, ou par rien du tout.
Le contraste entre le texte et son arrière-plan, et entre un bouton et la page qui l’entoure. Un texte gris pâle sur fond blanc paraît épuré pour quelqu’un qui voit toutes les couleurs, et disparaît pour quelqu’un qui ne les voit pas. Même chose pour un bouton dont la couleur se distingue à peine de la section où il se trouve — il se lit comme une décoration plutôt que comme quelque chose sur quoi cliquer.
Un repère visible quand le focus se déplace au clavier. Quelqu’un qui navigue en appuyant sur Tab plutôt qu’en cliquant a besoin de voir, à chaque étape, quel élément est actif en ce moment. Beaucoup de sites retirent ce contour pour paraître « plus propres » et ne le remplacent jamais par rien — ce qui veut dire que la navigation au clavier fonctionne encore techniquement, mais que personne qui l’utilise ne peut savoir où il se trouve.
Des titres dans un ordre réel. Un H1, puis des H2, puis des H3 en dessous — pas un H3 choisi simplement parce qu’il s’affiche à la taille de police voulue pour un sous-titre. Les lecteurs d’écran permettent de sauter d’un titre à l’autre, comme un lecteur voyant survole une page ; quand l’ordre est choisi pour la taille plutôt que pour la structure, cette carte cesse d’avoir un sens.
Une vraie étiquette sur un champ de formulaire, pas juste un indice qui vit à l’intérieur. Un texte de substitution qui affiche « Courriel » dans la boîte paraît correct jusqu’à ce que quelqu’un commence à taper, moment où il disparaît — et un lecteur d’écran ne l’annonce pas de façon fiable comme il annoncerait une vraie étiquette. Laissez le champ vide et soumettez, et la personne qui le remplissait n’a plus aucune trace de ce qu’on lui demandait.
Une erreur qui n’est pas communiquée par la couleur seule. Un champ qui devient rouge quand quelque chose cloche renseigne exactement un visiteur voyant et non daltonien sur ce qui s’est passé. Il ne dit rien à personne d’autre. Le message doit exister sous forme de texte, rattaché à ce champ, pas seulement comme un changement de couleur de bordure.
Un texte alternatif qui décrit ce qui est vraiment dans l’image. Pas le nom du fichier, pas un mot-clé répété, pas « image » laissé vide par défaut — une description courte et exacte de ce que l’image fait sur cette page. Une photo purement décorative devrait recevoir un attribut alt vide, volontairement, pour qu’un lecteur d’écran passe par-dessus au lieu de lire quelque chose qui ne veut rien dire.
Des sous-titres sur vidéo, synchronisés avec ce qui se dit. Ça sert directement les personnes sourdes ou malentendantes, et ça couvre aussi le groupe bien plus large des visiteurs qui regardent le son coupé.
Chaque élément interactif qui fonctionne sans aucune souris. Menus déroulants, filtres, fenêtres modales, sélecteurs de date — chacun doit pouvoir s’ouvrir, s’utiliser et se fermer avec le clavier seul. C’est l’un des endroits où une page échoue le plus souvent en silence, parce qu’il est facile de construire un composant qui fonctionne parfaitement à la souris et qui n’est jamais testé autrement.
Rien de tout ça n’est abstrait. Chacun est une décision précise, prise une seule fois, dans le balisage ou dans le texte, pendant que la page se construit — c’est la partie que comment tester vous-même l’accessibilité de votre site passe en revue si vous voulez vérifier vous-même votre propre site, et ce que couvre vraiment un audit d’accessibilité si vous préférez qu’on vous dise exactement ce qui cloche et qu’on le corrige.
Peu importe la règle qui s’applique, ce qui cloche sur la page reste le même
Trois règles distinctes couvrent trois groupes distincts — les sites des gouvernements étatiques et locaux sous le Titre II de l’ADA, les entreprises privées sous le Titre III, et les agences fédérales et leurs fournisseurs sous la Section 508 — et aucune n’est écrite pour une entreprise qui opère au Canada, laquelle répond plutôt à ses propres règles — les deux qui nomment réellement une norme étant un règlement fédéral couvrant les banques, les télécommunications, la radiodiffusion et le transport interprovincial, et une loi provinciale en Ontario avec un seuil basé sur le nombre d’employés. Seulement certaines de ces règles nomment une norme technique ; le Titre III, celui sous lequel tombent la plupart des entreprises privées américaines, n’en nomme aucune. Laquelle est vraiment la vôtre dépend de qui vous êtes, pas de la façon dont votre site est construit, et la carte complète — qui tombe sous quoi, et quelle version du WCAG chacune nomme — se trouve dans quelle règle d’accessibilité vous vise.
Un élément de cette carte mérite d’être mis en avant, parce qu’il est constamment mal cité. En avril 2026, le département de la Justice des États-Unis a prolongé les échéances du Titre II jusqu’au 26 avril 2027 et au 26 avril 2028. Ces dates appartiennent aux gouvernements étatiques et locaux. Une bonne partie de ce qui se classe actuellement dans les recherches sur l’ADA les présente comme une échéance générale que tout le monde doit respecter — ce n’est pas le cas, et aucune prolongation de ces dates ne change quoi que ce soit pour un site privé.
Le reste de cet article reste centré sur la page elle-même.
Quand le problème n’est pas du tout votre code
Il existe une catégorie que presque rien de ce qui est écrit sur ce sujet n’aborde : les parties d’une page qui ne sont pas construites par la personne qui a bâti le site.
Un widget de réservation, une bulle de clavardage, une carte intégrée, une étape de paiement confiée à un processeur — chacun de ces éléments arrive habituellement sous forme de code venant d’un tiers, déposé dans un iframe ou une balise script. Quand l’une de ces pièces contient un piège au clavier, un problème de contraste ou un bouton sans étiquette, la personne qui a construit le site autour ne peut pas simplement ouvrir le code et le corriger, parce que ce n’est pas son code. Il appartient au fournisseur.
Ce qui change réellement quelque chose dans cette situation, c’est l’une de deux choses : une demande de soutien au fournisseur, pointant vers le problème précis, puisque certains d’entre eux tiennent réellement des feuilles de route en accessibilité et agissent sur un signalement concret — ou remplacer cet outil par un autre qui gère la chose correctement. Un correctif posé par-dessus le script de quelqu’un d’autre n’est une troisième option que jusqu’à la prochaine mise à jour de ce script.
Ça se voit constamment à la caisse — une étape de paiement intégrée par un processeur, un calculateur d’expédition, une fenêtre de guide des tailles — et c’est exactement la couche couverte dans la conception de boutiques en ligne, parce que c’est là que vivent habituellement les problèmes d’accessibilité d’une boutique : pas dans la fiche produit qu’on a rédigée, mais dans les quatre étapes qui suivent le « ajouter au panier ».
Les widgets de superposition : ce qu’ils font vraiment
À un moment donné dans leurs recherches, la plupart des gens tombent sur un script qui promet de rendre un site existant conforme en ajoutant un petit panneau dans un coin — des contrôles de taille de police, un bouton de contraste, une option pour arrêter les animations, parfois une prétention à réécrire la page automatiquement. Ça vaut la peine d’être précis sur ce que ce script fait vraiment.
Mécaniquement, une superposition est un bout de code chargé par-dessus une page déjà construite. Il s’exécute dans le navigateur du visiteur, donne à ce visiteur un panneau de réglages et, dans certaines versions, tente des modifications automatisées — insérer un texte alternatif par reconnaissance d’image, par exemple. Ce qu’il ne fait pas, c’est réécrire la page sous-jacente : la structure des titres, les vrais attributs alt dans le balisage, l’ordre de focus au clavier et les étiquettes de formulaire restent exactement ce qu’ils étaient avant que le script se charge. Le panneau change ce qui s’affiche par-dessus ; il ne touche pas au code en dessous.
Les directives officielles de l’ADA à ce sujet méritent d’être citées directement plutôt que résumées, parce que la formulation exacte est plus prudente que la plupart de ce qui en est écrit ailleurs : « Les vérificateurs d’accessibilité automatisés et les superpositions qui repèrent ou corrigent des problèmes sur votre site peuvent être des outils utiles, mais comme d’autres outils automatisés tels que les correcteurs d’orthographe ou de grammaire, ils doivent être utilisés avec prudence. » La même page ajoute une phrase qui mérite qu’on s’y arrête : « Un rapport “propre” ne signifie pas nécessairement que tout est accessible. »
Il existe aussi un cas réglementaire précis et daté qui vaut la peine d’être connu. En janvier 2025, la Federal Trade Commission (FTC) a déposé une plainte contre le fabricant d’un tel outil, alléguant que sa prétention à rendre n’importe quel site conforme au WCAG était fausse ou non étayée, et que des avis rédigés par des personnes ayant un lien matériel non divulgué avec l’entreprise avaient été présentés comme indépendants. Une ordonnance finale a été approuvée en avril 2025 : un paiement de 1 000 000 $, et une interdiction de prétendre qu’un produit automatisé rend un site conforme au WCAG, ou le maintient conforme dans le temps, sans preuve à l’appui. C’est une conclusion visant les prétentions marketing précises d’un fournisseur précis — pas un jugement sur les widgets de superposition en tant que catégorie, et il ne faut pas le lire comme tel.
Un dernier fait à garder en tête : personne ne certifie la conformité ADA. Il n’existe aucun badge, sceau ou marque émise par un gouvernement disant qu’un site « est conforme à l’ADA », parce qu’aucun organisme — ni le DOJ, ni le W3C — n’en délivre.
Nous installons ces panneaux pour les clients qui souhaitent spécifiquement cette couche sur leur site. Le panneau agit sur ce qui s’affiche ; les étiquettes, les titres, le contraste et l’ordre de focus vivent dans la page elle-même, et c’est cette couche-là sur laquelle nous travaillons. Et si une lettre faisant référence à tout ça a déjà atterri dans votre boîte de réception, ce qui déclenche vraiment une poursuite en accessibilité couvre ce qu’il faut en faire en premier.
Par où commencer si votre site échoue sur la plupart de la liste
Personne ne coche les huit points en un après-midi, et laisser les huit de côté ne coûte pas la même chose pour chacun. Voici un ordre utile quand il y a plus à corriger que de temps cette semaine :
D’abord, tout ce qui empêche complètement une tâche d’être accomplie. Un piège au clavier dans une fenêtre contextuelle, une étape de paiement inaccessible sans souris, un champ de formulaire sans étiquette. Ce ne sont pas des expériences dégradées — ce sont des portes fermées, et ce sont aussi les éléments qu’un étranger qui examine votre site rencontrera en premier.
Ensuite, tout ce qui se trouve sur la page pour laquelle les gens sont réellement venus. Un formulaire de contact, un calendrier de réservation, une fiche produit. Corriger la page « À propos » avant le formulaire, c’est dépenser de l’effort là où ça change le moins.
Enfin, ce qui rend le site plus difficile plutôt qu’impossible à utiliser. Un faible contraste dans un pied de page, un sous-titre manquant sur une vidéo publicitaire, une image décorative avec un texte alternatif maladroit. Réel, ça vaut la peine d’être corrigé, mais pas avant les deux premiers points.
Cet ordre, c’est aussi ce qui sépare un après-midi de travail d’une reconstruction complète. La plupart de ce qui figure sur la liste est un changement au balisage ou au texte sur des pages qui existent déjà — c’est pourquoi ça coûte tellement moins cher quand ça fait partie de la façon dont un site est construit que lorsque c’est ajouté après coup deux ans plus tard sur quarante pages que personne n’a touchées depuis le lancement.
L’accessibilité ne reste pas immobile après le lancement
Une page qui coche tous les points ci-dessus le jour du lancement ne le reste pas d’elle-même — une nouvelle bannière promotionnelle sans texte alternatif, une image d’en-tête remplacée, une mise à jour de plugiciel qui change discrètement l’affichage d’un formulaire : chacun peut défaire quelque chose qui allait bien un mois plus tôt. Ça fait partie de ce que couvre réellement l’entretien continu d’un site, et non un sujet à part.
Où se situe la conformité ADA dans notre façon de construire un site
Le contraste, la structure des titres, les étiquettes de formulaire et le texte alternatif sont des décisions prises pendant qu’une page est mise en page et pendant que son texte est rédigé, et puisque le texte, les métadonnées et la structure des pages d’un site font déjà partie de ce que coûte la construction d’un site, le texte alternatif, l’ordre des titres et les étiquettes de formulaire font simplement partie de ce même travail, et non d’une ligne ajoutée en supplément.
Les défauts ci-dessus se manifestent différemment selon ce que fait réellement un site : un formulaire d’admission ne se comporte pas comme un catalogue de produits, et ni l’un ni l’autre ne se comporte comme un calendrier de réservation. Les détails changent. La liste des choses qui valent la peine d’être vérifiées ne change pas.
Si vous n’êtes pas certain de quelles parties de tout ça s’appliquent à vos propres pages, c’est exactement la conversation avec laquelle nous commençons chaque construction de site web — et elle est plus courte que ce que la plupart des textes sur la conformité ADA laissent croire.
