Partie 9 — Formulaires accessibles

⏱️ TL;DR — Les formulaires sont l’endroit où l’accessibilité se joue vraiment : inscription, connexion, paiement, contact, recherche. C’est là que l’utilisateur agit, et c’est là que l’a11y échoue le plus souvent — un champ sans label, une erreur affichée juste en rouge, un groupe de cases sans structure, et l’utilisateur de lecteur d’écran est bloqué. Cette partie couvre tout ce qui compte : labels liés, groupes et structure, gestion des erreurs annoncées, saisie facilitée. On termine en corrigeant, de A à Z, le formulaire d’inscription d’A11yLearn.

Le problème qu’on résout

Un formulaire, c’est un dialogue : l’interface demande, l’utilisateur répond. Pour un utilisateur de lecteur d’écran ou de navigation clavier, ce dialogue repose entièrement sur ce que ton HTML déclare. Si le champ n’a pas de label associé, la question n’est jamais posée. Si l’erreur n’existe qu’en rouge, la réponse « c’est faux » n’est jamais donnée. On répare ça méthodiquement : chaque champ nommé, chaque groupe structuré, chaque erreur identifiée en texte et annoncée, chaque saisie facilitée.

Ce que tu sauras faire à la fin de cette partie

• Associer chaque champ à un <label> et savoir pourquoi le placeholder n’est pas un label.
• Structurer un formulaire : grouper les champs liés avec <fieldset> et <legend>, signaler les champs requis correctement.
• Construire une gestion d’erreurs accessible : erreur en texte, liée au champ, annoncée, avec suggestion de correction.
• Faciliter la saisie : autocomplete, type et inputmode adaptés, éviter la saisie redondante, authentification sans test cognitif.
• Reprendre un formulaire réel inaccessible et le corriger complètement.

Les chapitres

On commence : Les labels — le pilier de tout formulaire accessible.