Lisez les plaintes qui sous-tendent les poursuites en accessibilité Web et un schéma se dégage vite. Le plaignant ne dit presque jamais « votre page d'accueil avait l'air bancale ». Il dit qu'il n'a pas pu faire quelque chose — pas pu payer, pas pu se connecter, pas pu soumettre une demande — parce qu'un formulaire ne fonctionnait pas avec son lecteur d'écran. Les formulaires sont l'endroit où la navigation devient une transaction, et l'endroit où l'accessibilité tient bon ou échoue en silence. Cela en fait l'élément à plus fort effet de levier à bien faire, que votre souci soit une échéance de conformité ontarienne ou une réclamation transfrontalière.
Faits essentiels
- Dans l'analyse WebAIM Million 2025 du million de pages d'accueil les plus visitées, 34,2 % des champs de formulaire n'étaient pas correctement étiquetés — autrement dit, un lecteur d'écran ne peut pas indiquer de façon fiable à l'utilisateur à quoi sert le champ.
- Les étiquettes de champ manquantes étaient la troisième défaillance WCAG la plus courante, présente sur 48,2 % des pages d'accueil; au total, 94,8 % des pages d'accueil présentaient des défaillances WCAG 2 détectées, avec en moyenne 51 erreurs et 6,3 champs de formulaire chacune (WebAIM).
- Les WCAG 2.2 (recommandation du W3C depuis octobre 2023) ont ajouté neuf critères de succès; trois touchent directement les formulaires : 2.5.8 Taille de la cible (minimum) — cibles interactives d'au moins 24×24 pixels CSS (niveau AA), 3.3.7 Saisie redondante (niveau A) et 3.3.8 Authentification accessible (niveau AA).
- Le RNAI (Règlement sur les normes d'accessibilité intégrées) de l'Ontario exige que les sites Web publics des organisations de 50 employés et plus respectent les WCAG (Règles pour l'accessibilité des contenus Web) 2.0 niveau AA d'ici le 31 décembre 2026 — une base qui inclut déjà les critères de formulaire ci-dessous.
- La LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) ne confère aucun droit d'action privé : les recours provinciaux sont donc le processus de rapport de conformité et une plainte au TDPO (Tribunal des droits de la personne de l'Ontario) — mais l'exposition à l'ADA (Americans with Disabilities Act) est bien réelle pour toute entreprise ontarienne qui vend à des clients américains.
Quelles règles WCAG un formulaire doit-il réellement respecter?
L'essentiel du travail est peu spectaculaire et fait déjà partie de la base WCAG 2.0 AA à laquelle renvoie le RNAI. Chaque champ a besoin d'une étiquette associée par programmation, et non d'un simple texte indicatif qui disparaît dès qu'on commence à taper (1.3.1 Information et relations, 3.3.2 Étiquettes ou instructions). Lorsqu'une commande personnalisée — un menu déroulant stylisé, un sélecteur de date, une « liste » construite à partir de <div> — est exposée aux technologies d'assistance, elle doit annoncer son nom, son rôle et sa valeur actuelle (4.1.2 Nom, rôle, valeur). Et le texte d'aide ou les instructions sur lesquels s'appuie une personne voyante doivent aussi être accessibles à un utilisateur de lecteur d'écran.
Les erreurs constituent l'autre moitié. Si un champ est rejeté, le formulaire doit dire lequel et pourquoi en texte, et non se contenter de rougir une bordure (3.3.1 Identification des erreurs), et lorsqu'il le peut, suggérer la correction (3.3.3 Suggestion après une erreur). Pour tout ce qui est juridique, financier ou qui modifie des données de l'utilisateur, les soumissions doivent être réversibles, vérifiables ou confirmables (3.3.4 Prévention des erreurs). Les WCAG 2.2 ajoutent ensuite les touches modernes : ne forcez pas les utilisateurs à ressaisir des renseignements déjà fournis dans le même processus (3.3.7 Saisie redondante), ne verrouillez pas la connexion derrière un casse-tête cognitif sans solution accessible (3.3.8 Authentification accessible) et rendez les cibles tactiles assez grandes pour être atteintes (2.5.8 Taille de la cible). Un dernier — 1.3.5 Identification de la fonction de saisie, la règle derrière une bonne autocomplétion des champs nom/courriel/adresse — est de niveau AA mais est apparu dans les WCAG 2.1; il se situe donc juste au-dessus du plancher 2.0 du RNAI et relève carrément de la meilleure pratique plutôt que du strict minimum provincial.
Pourquoi un tiers des formulaires échouent-ils encore?
Parce que les défaillances sont invisibles pour la personne qui a construit la page. Un développeur qui utilise une souris et une paire d'yeux fonctionnels traverse sans encombre un paiement totalement inutilisable au clavier ou avec un lecteur d'écran — le texte indicatif ressemble à une étiquette, la bordure rouge ressemble à un message d'erreur, le menu déroulant personnalisé a l'air correct. Le chiffre de WebAIM n'est pas un cas marginal exotique; c'est un tiers de tous les champs sur les sites les plus visités du monde. C'est aussi pourquoi une surcouche ajoutée ne règle rien : une surcouche ne peut pas savoir de façon fiable qu'un <input> donné recueille un code postal, quelle est sa condition d'erreur, ni comment annoncer un sélecteur de date fait main — et les sites dotés de surcouches sont quand même poursuivis pour exactement ces parcours. La correction se trouve dans le balisage même du formulaire, c'est pourquoi c'est la remédiation du code source, et non un script, qui tient la route.
Comment repérer les problèmes de formulaire avant qu'une réclamation ne le fasse?
Un balayage automatisé est un bon premier passage pour la moitié évidente — il signalera de façon fiable les champs non étiquetés et les boutons vides. Mais les défaillances qui brisent réellement un paiement sont des défaillances d'interaction : un ordre de tabulation qui saute le bouton de soumission, un résumé d'erreurs qui ne reçoit jamais le focus, un champ de paiement qui piège le clavier. Elles ne ressortent que lorsqu'un humain pilote le formulaire au clavier et au lecteur d'écran, ce qui est toute la différence entre un balayage et un véritable audit. Priorisez d'abord les parcours qui portent de l'argent et des obligations — paiement, création de compte, connexion, formulaires de prospects et de contact — car c'est là que se concentrent les poursuites. Puis corrigez à la source et conservez des preuves datées dans un rapport de conformité en accessibilité (ACR). Ce même travail comble votre écart au titre du RNAI avant l'échéance du 31 décembre 2026, de sorte que le budget fait double emploi.
Voyez ce qu'un balayage automatisé signale sur vos formulaires en environ 30 secondes — Rapport PassProof gratuit : getpassproof.com. Il détecte les surcouches, vous indique ce qui s'applique légalement en Ontario et montre où se trouvent les vrais écarts — sans tactiques alarmistes, seulement les faits.
PassProof est un studio d'ingénierie de l'accessibilité, à distance d'abord, au service de l'Ontario. Renseignements généraux, et non un avis juridique.