Les formulaires à remplir, vos documents les plus difficiles

La plupart des documents d'un site Web public se lisent. Les formulaires s'utilisent — et cette différence est tout le problème. Un résident qui ne peut pas terminer une demande de permis n'a pas été incommodé; il a été exclu d'un service gouvernemental. Les formulaires sont la raison d'être de notre niveau de remédiation le plus élevé, et ce billet explique ce qui en fait les documents les plus difficiles que vous publiez.

Pourquoi les formulaires sont-ils les documents les plus difficiles que vous publiez?

Parce qu'un formulaire est une interface, pas une page. Un rapport a besoin d'un ordre de lecture correct; un formulaire a besoin d'étiquettes, de focus, d'état, de regroupement, d'instructions et de récupération d'erreurs — l'ensemble complet des exigences interactives que les WCAG 2.1 appliquent à tout ce qu'une personne manipule plutôt que lit. La plupart des formulaires PDF ont d'abord été dessinés comme des mises en page visuelles, alors rien de cette structure n'existe, et tout doit être ajouté délibérément.

Les enjeux sont aussi plus élevés. En vertu de la règle du Title II du Department of Justice, un formulaire en usage actif est un contenu carrément visé — les exceptions pour les vieux documents cessent explicitement de s'appliquer dès qu'un document sert actuellement à demander un service ou à y accéder (fiche d'information ADA.gov). Vos formulaires les plus anciens sont souvent vos documents les plus visés.

De quoi chaque champ de formulaire accessible a-t-il besoin?

De quatre choses, dont aucune ne paraîtra manquante à un coup d'œil sur la mise en page. D'abord, une étiquette programmatique et une infobulle qui portent la vraie question : un utilisateur de lecteur d'écran qui tabule dans un champ entend son infobulle, alors un champ étiqueté « Text1 » au lieu de « Date de naissance (MM/JJ/AAAA) » est un cul-de-sac. Ensuite, un ordre de tabulation qui suit le flux visuel — un formulaire à deux colonnes qui tabule vers le bas dans l'ordre de création fait ricocher les utilisateurs du clavier d'une section à l'autre. Troisièmement, un regroupement programmatique : cinq boutons radio ne sont « Oui/Non pour la question 7 » que s'ils sont regroupés; sinon chacun s'annonce comme un orphelin. Quatrièmement, des instructions au bon endroit — exigences et indications de format balisées pour être rencontrées avant les champs qu'elles régissent, pas découvertes après une soumission échouée.

Exemple concret : les cases à cocher « type de travaux » d'une demande de permis de construire. Visuellement, le titre au-dessus explique tout. Programmatiquement, à moins que cette relation ne soit construite, un lecteur d'écran annonce « case à cocher, non cochée » sept fois de suite sans aucune indication de ce que chacune signifie.

Un autre, tiré du formulaire le plus courant de tout site public : la demande d'accès aux documents. Il comporte habituellement une zone de description en texte libre dont les instructions (« décrivez les documents, y compris les plages de dates ») sont imprimées au-dessus comme du texte de mise en page ordinaire. Si ces instructions ne sont pas liées au champ, un utilisateur de lecteur d'écran atterrit dans une zone de texte non étiquetée de la taille d'un paragraphe et doit deviner ce qui y va — sur le formulaire même conçu pour garantir l'accès du public.

Pourquoi les formulaires vont-ils au niveau 3?

Parce que « à peu près correct » exclut quand même des gens. Sur une page de texte, une balise imparfaite dégrade l'expérience; sur un formulaire, un champ non étiqueté ou une séquence de tabulation brisée peut rendre tout le document impossible à remplir. L'automatisation fait la préparation structurelle — construire l'arborescence de balises, détecter les champs — puis un réviseur humain étiquette, ordonne et parcourt chaque formulaire avant sa vérification. C'est ce que paie le palier L3 à 30 crédits, et c'est pourquoi le seuil L3 comprend une vérification ponctuelle humaine obligatoire plutôt que des scores machine seuls.

Faut-il remédier le PDF ou le reconstruire en formulaire Web?

Cela dépend de l'usage. Si un formulaire est rempli plus de quelques fois par mois, un formulaire HTML bien construit est habituellement la meilleure réponse : plus facile à garder accessible, adapté au mobile, et il valide la saisie à la source. Remédiez le PDF quand le formulaire est rarement utilisé, de format juridiquement fixé, ou doit rester imprimable et signable tel quel. Un hybride — formulaire Web devant, PDF accessible comme document d'archives — satisfait souvent à la fois les résidents et le service des archives.

Comment tester un formulaire remédié?

Remplissez-le. Au clavier seulement, de la première instruction jusqu'à la soumission; puis de nouveau avec un lecteur d'écran, en écoutant ce que chaque champ annonce. Les vérificateurs automatisés confirment que les étiquettes existent — seul un parcours humain confirme que les étiquettes ont du sens, que l'ordre permet d'aller jusqu'au bout, et qu'un message d'erreur n'abandonne pas l'utilisateur au bas de la page. Si vous avez des centaines de formulaires, testez un échantillon de cette façon et vous apprendrez vite de quelle génération de gabarit vous méfier.

Les formulaires sont là où l'accessibilité documentaire cesse d'être une abstraction. Réussissez-les en premier — ce sont les documents que les résidents ne peuvent pas contourner.

Sujetsformspdfwcagremediation