Composant de saisie personnalisé

Qu'est-ce qu'un composant de saisie personnalisé ?

Un composant de saisie personnalisé est un champ de formulaire que vous construisez vous-même au lieu d'utiliser celui du navigateur : un sélecteur de plage de dates, un champ d'étiquettes, une liste déroulante avec recherche (combobox), un champ de téléphone avec masque ou un curseur stylé. Pour l'utilisateur, il doit se comporter comme un champ de saisie ; pour le code, il doit participer au formulaire comme tel : un nom, une valeur, une étiquette, une validation et la prise en charge du clavier. S'il manque l'un de ces éléments, c'est un widget qui ressemble à un champ, pas un champ.

Le natif d'abord, le sur-mesure en dernier recours

MDN recense de nombreux types de champs natifs : text, email, url, tel, number, range, date, time, datetime-local, month, week, color et file, ainsi que les attributs inputmode, autocomplete, required, pattern et min/max. Ils apportent gratuitement le comportement au clavier, les claviers mobiles, la saisie automatique et la validation. Le guide ARIA Authoring Practices (APG) du W3C énonce clairement le coût de l'alternative : contrairement aux champs HTML, les rôles ARIA ne donnent au navigateur ni comportement clavier ni style, il faut tout construire, et « pas d'ARIA vaut mieux qu'un mauvais ARIA ». Ne construisez un composant maison que si aucun contrôle natif ne convient, par exemple une combobox avec recherche ou un champ à valeurs multiples.

Comment en construire un qui fonctionne

• Partez d'un élément natif quand c'est possible. Un conteneur stylé autour d'un vrai <input> ou <select> conserve l'essentiel du comportement.
• Suivez le modèle de l'APG pour votre widget (combobox, listbox, curseur, etc.). Il définit les rôles, états et touches attendus. Un rôle est une promesse : si vous posez role="combobox", vous devez tenir ce qu'il implique.
• Donnez-lui une étiquette visible liée au contrôle, et n'utilisez pas le texte indicatif (placeholder) comme étiquette. Selon MDN, il disparaît à la saisie et n'est pas annoncé de façon fiable.
• Rendez-le utilisable au clavier, avec un ordre de focus logique, un style de focus visible et les touches prévues par le modèle. Testez sans souris.
• Exposez l'état avec ARIA là où la sémantique native manque : nom, rôle, déplié, invalide, obligatoire.
• Intégrez-le au formulaire. Un web component peut être associé à un formulaire : définissez static formAssociated = true, appelez attachInternals(), puis utilisez setFormValue() pour la valeur envoyée et setValidity() pour la validation. Le même objet ElementInternals peut définir un rôle par défaut et des propriétés ARIA. MDN le signale comme largement disponible dans les navigateurs depuis mars 2023. Sans cela, la valeur de votre composant n'est pas envoyée avec le formulaire.
• Gardez un repli natif. Si JavaScript échoue, un champ simple devrait continuer à fonctionner.

Erreurs fréquentes

• Un <div> avec un gestionnaire de clic, sans rôle, étiquette ni prise en charge du clavier.
• Réimplémenter un contrôle natif (un champ date, un sélecteur de fichier) avec une accessibilité moindre que celle du navigateur.
• Signaler la validation uniquement par la couleur, ou par un message d'erreur que les lecteurs d'écran ne lisent jamais.
• Casser le copier-coller, la saisie automatique, l'annulation ou la sélection de texte avec un masque de saisie trop agressif.
• Tester sur un seul navigateur et sans technologie d'assistance. L'APG demande elle-même de tester chaque combinaison de navigateur et de technologie d'assistance avant la mise en production.

Champs personnalisés, normes et surveillance

Les champs personnalisés touchent directement aux règles pour l'accessibilité des contenus web (WCAG) : étiquettes, accès au clavier et identification des erreurs en relèvent, et ils façonnent l'ensemble de l'expérience utilisateur. Un éditeur de texte enrichi en est un exemple courant, et l'un des plus difficiles à rendre accessible. Un code de widget lourd coûte aussi en vitesse. La surveillance de la vitesse des pages de LoadFocus lance des audits Lighthouse planifiés, y compris la catégorie Accessibilité et les Core Web Vitals : un formulaire lent ou signalé apparaît donc après une mise en production. Les contrôles automatiques ne détectent qu'une partie des problèmes, gardez donc des tests manuels au clavier et au lecteur d'écran.

Questions fréquentes sur les composants de saisie

Quand utiliser un champ personnalisé plutôt qu'un champ natif ?

Quand aucun contrôle natif ne convient, comme une combobox avec recherche, un champ d'étiquettes ou une plage de dates. Pour le texte, les nombres, les dates, les couleurs et les fichiers, un champ natif est plus accessible et moins coûteux à maintenir.

Les champs personnalisés sont-ils envoyés avec le formulaire ?

Seulement s'ils y sont reliés. Un élément personnalisé associé au formulaire via ElementInternals peut définir la valeur envoyée et sa validité. Sinon, gardez un champ natif caché synchronisé ou envoyez la valeur vous-même.

Faut-il toujours ARIA ?

Non. Un contrôle fondé sur un vrai champ en demande peu, voire pas. ARIA comble les manques sémantiques des widgets maison, et un mauvais ARIA est pire que pas d'ARIA.

Comment tester l'accessibilité d'un champ personnalisé ?

Utilisez-le uniquement au clavier, vérifiez qu'un lecteur d'écran annonce l'étiquette et l'état, et lancez un audit automatique. Testez ensuite avec les navigateurs et technologies d'assistance que vos utilisateurs emploient réellement.