Ce qui fait l'objet de poursuites : un guide pratique des modèles d'interface utilisateur à l'origine de 6 666 plaintes en matière d'accessibilité

L'en-tête est la première zone interactive de chaque page, et le bouton « hamburger » est souvent la première chose à laquelle accède un utilisateur du clavier. Lorsque ce bouton s'affiche sous la forme d'un <div> si un élément utilise une image d'arrière-plan CSS, ne dispose pas d'un nom accessible ou déploie un menu qui retient le focus ou ne signale pas son état (ouvert/fermé), l'ensemble du site devient structurellement inaccessible au clavier avant même que l'utilisateur n'ait pu consulter le contenu proprement dit.

Le lien d'accès direct est le problème qui va de pair. Un lien qui fonctionne "Skip to main content" Le lien de saut ne nécessite que cinq lignes de code, mais il constitue aussi le critère le plus efficace pour déterminer si une équipe de développement a réellement intégré l'accessibilité à sa liste de contrôle. Les plaintes mentionnent souvent ces deux éléments dans le même paragraphe, car un lien de saut manquant ou défectueux est un signe avant-coureur : si l'équipe n'a pas intégré de lien de saut, il est presque certain qu'elle n'a pas non plus pris en charge les états « aria-expanded ».

Afficher le déclencheur du menu sous sa forme réelle <button> avec une étiquette textuelle visible ou accessible uniquement par un lecteur d'écran et un élément géré aria-expanded attribut. Indiquez un "Skip to main content" lien qui s'affiche lorsque le curseur passe dessus et qui mène à la page <main> repère. Assurez-vous que le focus passe sur le menu lorsqu'il s'ouvre, qu'il revienne sur l'élément déclencheur lorsqu'il se ferme, et que Esc ferme le menu.

Sur la plupart des grands sites, la fonction de recherche est recréée sous la forme d'un composant personnalisé : un champ de saisie textuel avec suppression du rebond qui envoie une requête à chaque frappe et affiche une liste flottante de suggestions à l'intérieur d'un élément positionné de manière absolue <div>. Le champ de saisie en lui-même fonctionne généralement bien. La liste de suggestions, en revanche, ne fonctionne presque jamais correctement. Elle s'affiche en dehors du contexte DOM du champ de saisie et ne dispose d'aucun role="listbox", non aria-activedescendant, et aucune notification de zone active ne s'affiche lorsque les résultats apparaissent. Un utilisateur de lecteur d'écran tape du texte, n'entend rien, appuie sur Entrée et obtient une page de résultats dont il ignorait l'existence.

On retrouve le même modèle architectural dans les panneaux de filtrage de la recherche à facettes et dans la liste des résultats elle-même : des éléments sur lesquels le curseur du clavier peut se poser, qui sont visibles mais qui ne sont jamais annoncés. Les plaintes concernant la recherche portent rarement sur le champ de recherche ; elles concernent tout ce qui s'affiche une fois que l'utilisateur a saisi son texte.

Utilisez le modèle de liste déroulante WAI-ARIA établi : role="combobox" à l'entrée avec aria-expanded, aria-controls, et aria-activedescendant raccordé à un role="listbox" de suggestions. Ajoutez une zone interactive qui affiche le nombre de résultats. Assurez-vous que la liste de suggestions soit accessible à l'aide de la touche fléchée vers le bas, et pas seulement avec la souris.

La grille PLP regroupe plusieurs anti-modèles sur un seul écran. Chaque tuile est généralement une carte cliquable comportant trois ou quatre éléments interactifs — lien vers une image, lien vers un titre, nuancier de couleurs, bouton d’ajout rapide —, le tout encadré par un autre lien vers la page du produit. Il en résulte des éléments interactifs imbriqués (une erreur HTML), des textes de lien redondants (« Hero Dash Three Graphic Image Link » répété quatre fois) et des nuanciers de couleurs créés à partir de <div> les éléments dotés d'un gestionnaire de clic, mais sans rôle ni nom.

La barre latérale de filtrage ajoute une deuxième catégorie d'erreurs. Les facettes de filtrage se présentent généralement sous forme de listes de cases à cocher, mais elles sont en réalité construites à l'aide d'éléments div et span personnalisés, stylisés pour ressembler à des cases à cocher, avec le véritable <input> masqué hors de l'écran. Lorsque cet élément masqué perd son association — à cause d'une règle CSS, d'un gestionnaire d'événements JavaScript qui intercepte les pressions sur la touche Espace, ou d'un élément manquant for attribut sur l'étiquette visible — le filtre ne peut alors être activé qu'à l'aide de la souris.

Utilisez un lien par vignette avec un texte descriptif, et non pas trois liens par produit. Affichez les échantillons de couleur tels qu'ils sont réellement <button> éléments à l'intérieur d'un role="radiogroup". Créer des facettes de filtrage sur les données réelles <input type="checkbox"> éléments associés <label> tags ; stylisez les champs de saisie de manière visible plutôt que de les masquer. Signalez les modifications apportées au filtre à l'aide d'une zone interactive claire.

C'est sur la page de détail du produit qu'un utilisateur de lecteur d'écran doit effectuer plusieurs choix précis dans le bon ordre : choisir une couleur, choisir une taille, définir une quantité, puis ajouter le produit au panier. Chacun de ces choix est mis en œuvre dans le commerce électronique moderne sous la forme d'un widget personnalisé — généralement une rangée horizontale de <button>en forme de <div>En ce qui concerne les dimensions, les tuiles de couleur sont constituées de divs stylisées via CSS, et le curseur numérique est formé de deux boutons iconiques encadrant un champ de saisie. Les boutons d'augmentation et de diminution sont généralement fournis sans nom accessible ; les plaintes les décrivent comme annoncé sous le nom de « button, button » sans aucune indication sur ce qu'ils font.

Les guides des tailles et les tableaux des tailles constituent un autre problème : ils se trouvent presque toujours derrière un lien « Tableau des tailles » qui ouvre une fenêtre contextuelle, et ce lien n'est souvent pas libellé, la fenêtre contextuelle n'affiche souvent pas de titre, et le tableau qu'elle contient ne comporte souvent ni en-têtes de lignes ni de colonnes.

Utilisez de véritables contrôles de formulaire. Les nuanciers de couleurs et les sélecteurs de taille doivent être des role="radiogroup" de role="radio" des boutons (ou des éléments radio dont l'apparence est masquée), chacun doté d'un nom accessible tel que « Taille : Moyenne ». Le curseur de quantité doit être un champ numérique étiqueté, accompagné de boutons d'augmentation et de diminution dont les noms accessibles indiquent l'action et la quantité actuelle. Enveloppez l'ensemble du bloc de sélection dans un élément `fieldset` muni d'une légende.

Le bouton « Ajouter au panier » est l'étape la plus testée dans tout entonnoir de vente en ligne, et l'une de celles qui posent le plus souvent problème aux utilisateurs de technologies d'assistance. Le schéma est classique : un visiteur clique sur le bouton, une petite fenêtre de confirmation ou un mini-menu de panier s'affiche pendant deux ou trois secondes, et l'icône du panier met à jour le compteur dans l'en-tête. Les utilisateurs voyants perçoivent ces trois signaux. Les utilisateurs de lecteurs d'écran n'en perçoivent généralement aucun. La fenêtre contextuelle s'affiche en dehors de toute zone interactive, le tiroir apparaît sans gestion du focus, et la modification du nombre d'articles dans le panier est traitée comme une simple mutation du DOM qu'aucun lecteur d'écran ne signalera.

Il en résulte un bouton qui, du point de vue de l'utilisateur, ne fait rien. Il appuie dessus, n'entend aucun son, pense que ça n'a pas marché et appuie à nouveau. Certains utilisateurs se plaignent d'avoir dû appuyer cinq ou six fois sur le bouton avant de se rendre compte que le panier s'était rempli en silence de cinq ou six articles.

Encadrez la zone « cart-status » avec aria-live="polite" et actualiser son texte à chaque ajout réussi. Si l'interface utilise un volet de confirmation, déplacer le focus vers ce volet lorsqu'il s'ouvre et le ramener sur le bouton d'origine lorsqu'il se ferme. Mettre à jour l'icône indiquant le nombre d'articles dans le panier avec une annonce destinée uniquement aux lecteurs d'écran, telle que « 1 article ajouté. Total du panier : 3 articles. »

Les contrôles composés uniquement d'icônes présentent des dysfonctionnements prévisibles : le contenu visible est un fichier SVG ou un glyphe de police d'icônes, le contenu accessible est vide, et la lecture par un lecteur d'écran se réduit au rôle structurel de l'élément, qui n'a pas de nom. L'icône du panier est finalement annoncée comme « lien » ou « réduit »; la bulle de discussion comme « bouton »; la rangée d'icônes sociales dans le pied de page comme « lien, lien, lien, lien, lien ». L'utilisateur n'a aucun moyen de savoir à quoi elles servent.

Les icônes de panier présentent plus souvent des dysfonctionnements que les autres icônes pour une raison d'ordre architectural : de nombreuses implémentations affichent le nombre d'articles du panier dans le nom accessible de l'icône (par exemple, l'icône affiche « 0 » à l'intérieur du fichier SVG), et le lecteur d'écran ne détecte que le chiffre. Des utilisateurs se plaignent que l'icône de panier est annoncée comme « 3, lien » ou « 0, lien », sans aucune indication précisant que le « 3 » fait référence à la quantité d'articles dans le panier.

Chaque contrôle composé uniquement d'icônes doit avoir un nom accessible. Ajoutez un aria-label sur le bouton ou en y intégrant une étiquette de texte invisible : "Shopping cart, 3 items". Évitez d'inclure des chiffres dans le nom accessible de l'icône sans contexte. Pour les icônes décoratives qui accompagnent du texte visible, utilisez aria-hidden="true" sur l'icône et laissez le texte servir d'étiquette.

La page de paiement concentre davantage de risques liés à la conformité par pixel carré que n'importe quelle autre page d'un site de commerce en ligne, et les sources d'erreur y sont nombreuses. Les menus déroulants d'adresse s'affichent sous forme personnalisée <div> éléments qui ignorent la touche Espace. Les champs obligatoires sont signalés uniquement par un astérisque rouge, sans aria-required et aucune association programmatique. Des messages d'erreur s'affichent en rouge sous le champ, sans aria-describedby le champ n'est pas associé à l'erreur et aucune zone active n'est mise en évidence lorsque la validation échoue. L'utilisateur remplit le formulaire, clique sur « Continuer », est redirigé sans avertissement et n'a aucun moyen de savoir quels champs ont posé problème ni pourquoi.

On retrouve les mêmes plaintes dans des centaines de cas : les messages d'erreur ne sont pas annoncés, ils sont vagues, il est impossible de saisir les informations de paiement. Il ne s'agit pas de bugs isolés. C'est le comportement par défaut de la plupart des composants de paiement en ligne fournis sans avoir fait l'objet d'un travail explicite en matière d'accessibilité.

Utilisez des données réelles <label> éléments associés aux entrées par for/id. Indiquez les champs obligatoires avec aria-required="true" et indiquez que le champ est obligatoire dans le texte visible, et pas seulement par la couleur. En cas d'échec de la validation, affichez le message d'erreur à l'intérieur du champ de saisie aria-describedby cible, indiquez le champ défaillant aria-invalid="true", et déplacer le focus du clavier sur le premier champ non valide. Afficher une zone récapitulative des erreurs en haut du formulaire, avec des liens vers chaque champ présentant une erreur.

Le bloc de paiement est particulier, car il est souvent intégré via une iframe tierce — Stripe Elements, Braintree Hosted Fields ou un module prêt à l'emploi d'Adyen. À l'intérieur de l'iframe, le formulaire propre au prestataire de paiement est généralement bien étiqueté. Mais dès qu’un site crée son propre formulaire de saisie de carte bancaire ou intègre les champs dans une mise en page personnalisée qui remplace les étiquettes par des espaces réservés visuels, les quatre champs — numéro, date d’expiration, CVV, code postal — apparaissent comme une ligne de champs vides pour un lecteur d’écran.

Le champ CVV est celui qui fait le plus souvent l'objet d'une erreur d'étiquetage, car les concepteurs remplacent souvent son libellé par une icône en forme de point d'interrogation qui ouvre une info-bulle expliquant ce qu'est un CVV. L'info-bulle ne remplace pas le libellé ; le champ doit tout de même disposer d'un nom programmatique. Lorsqu'il n'en a pas, le lecteur d'écran annonce l'ensemble du bloc de paiement comme « modifier, modifier, modifier, modifier » et la transaction s'interrompt.

Si vous utilisez une intégration de champs hébergés par un tiers, suivez les recommandations d'accessibilité du fournisseur : la plupart proposent une méthode documentée pour étiqueter les champs depuis l'extérieur de l'iframe. Si vous créez un formulaire de saisie de données personnalisé, chaque champ de saisie doit disposer d'un véritable <label> élément comportant une étiquette de texte visible, ainsi que autocomplete="cc-number" / cc-exp" / cc-csc" attributs afin que les gestionnaires de mots de passe et les technologies d'assistance puissent identifier les champs en fonction de leur fonction.

La page du panier reproduit le problème rencontré avec le sélecteur de quantité de la page de détail du produit, mais avec des conséquences plus graves : un utilisateur de lecteur d'écran qui ne parvient pas à utiliser ce sélecteur ne peut pas finaliser sa commande. Le bouton « Supprimer » constitue en soi un anti-modèle : il s'agit généralement d'une petite icône en forme de « × » située à côté de chaque article, souvent dépourvue de texte visible, sans aria-label, et aucune notification n'est émise lorsque la ligne est supprimée. L'utilisateur clique sur ce qu'il pense être le bouton de suppression, la ligne disparaît, et le lecteur d'écran reste silencieux. Il n'y a aucun moyen de confirmer que l'action a bien abouti.

Plusieurs plaintes font état d'un problème similaire : le montant total du panier est mis à jour en temps réel lorsque les quantités changent ou que des articles sont retirés, mais le nouveau total s'affiche sous forme de texte DOM classique en dehors de toute zone dynamique, de sorte que l'utilisateur n'a aucune idée du montant qui lui sera facturé.

Chaque ligne doit comporter un bouton « Supprimer » clairement identifié (par exemple, "Remove Blue T-Shirt, size M, from cart"). Les curseurs de quantité doivent indiquer leur valeur actuelle soit dans leur nom accessible, soit via des mises à jour associées de la zone interactive. Le sous-total du panier doit figurer à l'intérieur d'un aria-live="polite" région, de sorte que les modifications soient signalées. Confirmez les suppressions à l'aide d'une fonction d'annulation.

Il s'agit de la catégorie la plus importante de l'ensemble de données, car c'est le problème le moins coûteux à détecter et le plus coûteux à ignorer. Un lecteur d'écran parcourt le DOM, rencontre un <input>, et lit son nom d'accès — qu'il calcule à partir, dans l'ordre : aria-labelledby, aria-label, une société affiliée <label for>, le title attribut ou l'élément de remplacement. Si aucun de ces éléments n'existe, le lecteur d'écran n'annonce que le rôle : « zone d'édition » ou « édition, vide ». Cette phrase, reprise presque mot pour mot, revient dans des centaines de dossiers de réclamation.

La raison pour laquelle cette pratique est si courante est d'ordre structurel. Les systèmes de conception modernes affichent souvent un texte de remplacement à l'intérieur du champ de saisie pour suppléer à l'étiquette visible, et les développeurs partent du principe que ce texte de remplacement fait office d'étiquette. Or, ce n'est pas le cas. Le texte de remplacement disparaît lorsque l'utilisateur commence à taper, ne laisse aucune référence programmatique et rend le champ inutilisable pour toute personne qui y accède plus tard dans le flux ou qui y revient après une erreur.

Chaque élément de contrôle interactif est associé à une étiquette visible, définie par programmation. <label for="email">Email</label><input id="email" type="email"> C'est la norme. Les espaces réservés ne sont que des indications supplémentaires, et non des substituts. Pour les éléments de contrôle où un libellé visible n'est vraiment pas souhaitable (champs de recherche, boutons sous forme d'icônes), utilisez aria-label avec un texte descriptif — jamais avec le texte de remplacement dupliqué.

L'expression « non annoncé ou sans focus » apparaît telle quelle dans plus de 400 signalements et constitue l'une des phrases les plus récurrentes de l'ensemble des données. Elle décrit un type de dysfonctionnement spécifique : une fenêtre modale ou une boîte de dialogue s'affiche sur la page (souvent automatiquement — inscription à une newsletter, vérification de l'âge, confirmation de la localisation), le contenu visible change, mais le lecteur d'écran ne reçoit aucun signal indiquant qu'un changement s'est produit. Le focus reste sur la page sous-jacente. L'utilisateur continue à naviguer à l'aide de la touche Tabulation sur ce qui se trouvait sous la fenêtre modale, sans se rendre compte qu'une boîte de dialogue bloquante est apparue.

C'est l'exemple type d'une fenêtre contextuelle qui échoue sur tous les plans à la fois : pas role="dialog", non aria-modal="true", pas de changement de focus programmatique lors de l'ouverture, pas de « focus trap » pendant l'ouverture, pas de fermeture par la touche Échap, pas d'annonce du titre. Comme tous ces problèmes vont de pair, le fait de corriger l'un d'entre eux isolément ne change rien à la situation.

Utilisez un modèle de boîte de dialogue standard (la spécification « WAI-ARIA Authoring Practices » sert de référence). À l'ouverture : déplacez le focus sur le premier élément pouvant recevoir le focus à l'intérieur de la boîte de dialogue, définissez aria-modal="true" et role="dialog", nommez la boîte de dialogue aria-labelledby en indiquant son titre. Tant qu'il est ouvert : maintenir le focus à l'intérieur de la boîte de dialogue. À la fermeture : renvoyer le focus vers l'élément qui l'a déclenché. Respecter la touche Échap. Si la fenêtre modale interrompt un flux (par exemple, la lecture automatique au chargement de la page), proposer à l'utilisateur un moyen unique de la fermer définitivement.

Les indicateurs de focus sont généralement désactivés intentionnellement par un développeur ou un concepteur qui considérait le contour par défaut du navigateur comme un élément gênant et a écrit *:focus { outline: none; } dans une feuille de style globale. La page semble désormais plus claire pour un utilisateur voyant qui utilise la souris. En revanche, pour un utilisateur voyant qui utilise le clavier — notamment la plupart des personnes malvoyantes, des personnes à mobilité réduite et des utilisateurs qui naviguent sans souris —, la page devient inutilisable. L'utilisateur peut appuyer sur la touche Tab, mais il ne peut pas voir où il se trouve.

Il s'agit de l'un des rares problèmes d'accessibilité détectables sans aucun outil d'assistance. Un contrôleur qualité qui parcourt la page d'accueil à l'aide de la touche Tab, sans autre outil, le repérera en moins d'une minute. Le fait que les équipes chargées de l'accessibilité le repèrent systématiquement sur les sites faisant l'objet d'un litige, alors que les contrôles internes l'ont manqué, constitue l'un des indices les plus fiables dans l'ensemble de données indiquant que le site n'a absolument pas passé les tests d'accessibilité au clavier.

Ne désactivez jamais tout en bloc :focus des contours sans remplissage. Appliquez un style de surbrillance visible — généralement un contour de 2 à 3 pixels offrant un contraste suffisant par rapport à l'élément et à son arrière-plan — en utilisant :focus-visible L'indicateur s'affiche donc lors de la navigation au clavier, mais pas lors des clics de souris. Vérifiez-le sur chaque composant interactif, y compris les widgets personnalisés, les liens à l'intérieur des cartes et les éléments comportant tabindex.

Le logo est l'image la plus consultée d'un site web et l'une de celles qui présentent le plus souvent des problèmes d'affichage. Il est généralement intégré à un lien qui redirige vers la page d'accueil, mais l'image est fournie sans alt, non aria-label sur le lien, sans texte d'accompagnement. Le lecteur d'écran n'annonce que « lien », sans aucune indication sur sa destination. Multipliez cela par chaque page du site.

La catégorie plus large — les images sans texte alternatif — englobe les bannières, les photos de produits, les illustrations de mise en avant, les icônes de réseaux sociaux et le vaste catalogue d'images marketing que propose généralement un site de commerce en ligne. Les plaintes relevant de cette catégorie mentionnent souvent des noms de fichiers d'images spécifiques, ce qui indique que l'expert du plaignant a effectué une vérification automatisée qui a répertorié toutes les images dont alt L'attribut était manquant ou vide alors qu'il aurait dû être descriptif.

Les logos doivent comporter un texte alternatif décrivant le nom de l'entreprise et, si le logo renvoie vers une page, la destination — alt="Acme Co. — homepage". Les images décoratives se voient attribuer un attribut alt vide (alt=""), qui les masque délibérément aux technologies d'assistance. Les images informatives doivent être accompagnées d'un texte alternatif descriptif. Évitez de générer automatiquement du texte alternatif à partir des noms de fichiers ou d'utiliser des légendes générées par l'IA sans vérification humaine ; les registres de plaintes font régulièrement état de cas où des outils de superposition ont légendé le logo d'une entreprise en le décrivant comme « un panneau bleu et jaune ».

Les lecteurs d'écran proposent un affichage sous forme de « liste de liens », très utilisé par les utilisateurs expérimentés pour parcourir une page en quelques secondes. Cet affichage ne montre que le texte des liens, dissocié du paragraphe qui l'entoure. Une page où chaque accroche de blog se termine par « En savoir plus » s'affiche dans cette vue sous la forme de quinze entrées identiques. Une page comportant cinq liens vides — <a href="..."></a>, ce qui arrive souvent lorsque les icônes se trouvent dans des balises de lien sans texte de secours — affiche cinq espaces vides.

La solution est bien connue, tout comme le problème, ce qui explique pourquoi ce schéma revient sans cesse dans les plaintes — sa persistance témoigne d'un processus de développement dépourvu de linter automatisé pour le texte des liens et de vérification manuelle avec un lecteur d'écran.

Chaque lien doit comporter un nom accessible décrivant sa destination ou l'action qu'il permet d'effectuer. Remplacez les expressions génériques par des expressions descriptives — « En savoir plus » devient « En savoir plus sur les résultats du troisième trimestre ». Pour les liens comportant uniquement une icône, ajoutez du texte masqué ou un aria-label. Effectuez une vérification automatisée (axe, Lighthouse, etc.) pour détecter les champs vides <a> éléments au cours de la CI.

Les vidéos font l'objet de plaintes selon deux schémas. Le premier est évident : une vidéo marketing, une démonstration de produit ou une vidéo explicative est mise en ligne sans sous-titres, sans transcription ni aucune alternative textuelle — et un visiteur sourd ou malentendant ne peut pas accéder au contenu. Le second est plus subtil : une vidéo principale qui se lance automatiquement au chargement de la page, ce qui interfère avec la lecture par un lecteur d'écran et enfreint les contrôles de pause/arrêt attendus au niveau AA des WCAG 2.2 (conformément à la sous-section 2.2.2 Pause, arrêt, masquage pour le contenu animé et à la sous-section 1.4.2 pour tout contenu audio).

Certaines plaintes figurant dans cet ensemble de données affirment que « l'absence de sous-titrage codé sur les vidéos des sites web constitue une violation de l'ADA », ce qui est présenté comme une conclusion juridique. La validité de cette interprétation varie selon la juridiction et les circonstances ; ce qui est plus incontestable, c'est que ces vidéos ne respectent systématiquement pas les WCAG 2.2 AA, la norme que la plupart des tribunaux et des accords de règlement considèrent comme la référence en matière de conformité.

Fournissez des sous-titres synchronisés pour toutes les vidéos préenregistrées comportant un son. Fournissez également une transcription textuelle ; les transcriptions sont utiles pour les utilisateurs dont l'appareil est en mode silencieux, dans les environnements à faible bande passante, ainsi que pour l'indexation. Évitez la lecture automatique ; si celle-ci est nécessaire pour des raisons de conception, prévoyez une commande de pause/arrêt accessible immédiatement via le clavier. Pour les contenus exclusivement vidéo (sans son), fournissez une description audio ou un texte de remplacement.

La page de connexion est le point d'entrée de l'ensemble du processus d'authentification. Lorsque le formulaire ne fonctionne pas, toutes les pages qui s'y rattachent deviennent inaccessibles, et les utilisateurs perçoivent souvent cette cascade de problèmes comme un obstacle unique. Le schéma correspond à la même erreur de libellé du formulaire que dans le cas E·01, souvent associée à trois sous-erreurs spécifiques : un bouton « Afficher le mot de passe » implémenté sous la forme d’une simple icône, sans nom ni annonce de changement d’état ; un CAPTCHA qui rend l’utilisation d’un lecteur d’écran totalement impossible ; et des erreurs en ligne (« identifiants non valides ») qui s’affichent à l’écran mais ne sont pas annoncées.

La case à cocher « Se souvenir de moi » constitue une autre erreur secondaire récurrente : elle s'affiche sous la forme d'un élément stylisé <div>, avec le véritable <input> Cachée hors de l'écran, cette case à cocher est accessible à la souris, mais pas au clavier ni avec un lecteur d'écran. L'utilisateur n'a aucun moyen d'activer une session persistante.

Utilisez des données réelles <input>, <label>, et <button> éléments. Transformez le bouton d'affichage/masquage du mot de passe en un véritable bouton doté d'un nom accessible qui s'actualise en fonction de son état ("Show password" / "Hide password") et annoncer le changement avec aria-pressed. Proposer une alternative accessible aux CAPTCHA basés sur des images (CAPTCHA audio ou, de préférence, remplacer le CAPTCHA par une authentification basée sur le risque ou par les variantes accessibles de hCaptcha).

Les lecteurs d'écran permettent de parcourir la page selon trois modes de navigation : par titre, par repère et par lien. Une page qui est publiée sans <h1>, sans <main>, <nav>, et <footer> sites emblématiques, et sans lang="en" attribut sur le <html> a supprimé ces trois modes de navigation d'un seul coup. Les utilisateurs ne peuvent ni parcourir le contenu, ni accéder directement à celui-ci, ni permettre au lecteur d'écran de charger le moteur de prononciation approprié.

Il s'agit là d'une défaillance particulièrement grave : la simple absence d'un repère entraîne une cascade de problèmes en aval, car toutes les stratégies de navigation des lecteurs d'écran qui en dépendent échouent désormais. Les critiques relevant de cette catégorie énumèrent généralement quatre ou cinq problèmes structurels spécifiques, présentés comme la preuve que le site ne dispose d'aucune base sémantique.

Chaque page en a une et une seule <h1>, avec des sous-titres (<h2>, <h3>) imbriquées de manière logique. Encadrez les zones à l'aide d'éléments de repère HTML5 : <header>, <nav>, <main>, <aside>, <footer>. Définir lang à la racine <html> élément. Vérifiez-le à l'aide d'un vérificateur de structure ou exécutez document.querySelectorAll('h1').length === 1 comme test de fonctionnement dans CI.

La plupart des contrôles d'accessibilité sont effectués sur des navigateurs de bureau avec NVDA ou JAWS. Les technologies d'assistance mobiles — VoiceOver sur iOS, TalkBack sur Android — offrent un rendu différent du même DOM, souvent accompagné de bugs distincts. Les plaintes utilisent régulièrement l'abréviation « mobile SRU » (utilisateur de lecteur d'écran mobile) pour signaler des dysfonctionnements propres à l'affichage mobile : un menu hamburger qui fonctionne avec NVDA sur ordinateur de bureau mais reste silencieux sous VoiceOver, un bouton Apple Pay accessible sur un ordinateur portable mais pas sur la version iPhone de la page, des messages d'erreur qui s'affichent sur ordinateur de bureau mais pas sur mobile.

Les données indiquent que les défendeurs, dont l'accessibilité sur ordinateur de bureau est par ailleurs irréprochable, font tout de même l'objet de poursuites pour des problèmes spécifiques aux appareils mobiles. La parité mobile constitue en soi un critère d'acceptation lors des audits.

Testez au minimum avec VoiceOver sur Safari (iOS) et TalkBack sur Chrome (Android), en suivant les mêmes scénarios que ceux couverts par les tests d'assurance qualité sur ordinateur. Portez une attention particulière aux interactions gestuelles, aux boutons de paiement natifs et à la lecture des champs de formulaire lorsqu'ils sont sélectionnés. Si une application native existe, soumettez-la au même audit : les réclamations concernent souvent à la fois le site web et l'application dans le cadre d'un même dossier.

La superposition d’accessibilité est le seul cas présenté dans ce catalogue où le problème ne réside absolument pas dans le site sous-jacent, mais bien dans la couche de correction censée avoir été ajoutée pour y remédier. Les plaintes relevant de cette catégorie font état de deux préjudices distincts. Le premier est que les superpositions ne résolvent pas réellement les obstacles sous-jacents ; l’utilisateur se retrouve donc confronté aux mêmes fenêtres modales défectueuses, formulaires mal étiquetés et erreurs non signalées, que le widget soit présent ou non. Le second est plus précis : les superpositions introduisent parfois de nouvelles défaillances en injectant des étiquettes incorrectes, en appliquant de manière erronée les rôles ARIA ou en interférant avec la configuration des technologies d'assistance de l'utilisateur.

Un détail mérite d'être souligné : les plaintes déposées en 2024 et 2025 citent de plus en plus souvent le nom du fournisseur de la superposition. Deux passages spécifiques de ces plaintes mentionnent UserWay et AccessiBe en termes très clairs, et les récentes mesures prises par la FTC font désormais courir un risque réel que l'ajout d'une superposition soit considéré comme une preuve d'un manquement à l'obligation de mettre en œuvre de véritables mesures correctives — plutôt que comme un moyen de défense face à une action en justice.

Considérez les superpositions comme un indicateur, et non comme une solution. Si une superposition est actuellement déployée, élaborez une feuille de route pour une correction en profondeur qui s'attaque au code sous-jacent plutôt que de le masquer. La méthode qui a fait ses preuves consiste à combiner plusieurs éléments : un scanner automatisé intégré à l'intégration continue (CI), un audit manuel conforme aux WCAG 2.2 AA, des tests manuels avec au moins un lecteur d'écran et une navigation au clavier uniquement, ainsi qu'un contrôle qualité continu de l'accessibilité tout au long du processus de conception et de développement.