Accessible Forms · Démo en direct
Des formulaires accessibles qui fonctionnent pour tout le monde.
Conçus pour respecter les WCAG 2.2 AA dès la base : essayez chaque formulaire au clavier ou avec un lecteur d’écran, sur n’importe quel appareil.
- ✓WCAG 2.2 AA
- ✓Bloc & code court
- ✓Prêt pour le clavier & les lecteurs d’écran
- ✓Se réorganise jusqu’à 320px
- ✓Aucun script tiers
Exemple complet
Formulaire de demande - tous les types de champs
Un formulaire présentant des champs texte, e-mail, téléphone, adresse web, nombre, liste déroulante, boutons radio, cases à cocher, un champ de paragraphe et une case de consentement : chacun correctement étiqueté et regroupé.
Astuce : Envoyez le formulaire de demande vide. Observez le récapitulatif des erreurs apparaître, prendre le focus et renvoyer directement vers chaque champ : le comportement dont dépend un utilisateur de lecteur d’écran.
Réutilisable
Le même moteur, des usages différents
Chaque formulaire est enregistré une seule fois et placé par son identifiant, de sorte qu’une courte inscription à la newsletter et un formulaire d’avis plus long partagent la même base accessible.
Pas seulement en bloc
Deux façons de placer un formulaire
Utilisez le bloc dans l’éditeur, ou le code court partout où les codes courts fonctionnent : l’éditeur classique, les widgets, et les constructeurs de pages comme Elementor, Beaver Builder et Divi. Les deux produisent exactement le même balisage accessible.
Code court (fonctionne partout)
Collez-le dans n’importe quelle page, article, widget ou élément de code court d’un constructeur de pages.
[ananyoo_form id="123"]
Bloc (Gutenberg)
Ajoutez le bloc Accessible Form et choisissez votre formulaire dans la liste déroulante. Aucun code, même résultat.
Insérer le bloc → « Accessible Form » → choisir le formulaire
Contexte
Pourquoi les formulaires accessibles comptent
Un formulaire est souvent l’endroit où un visiteur devient client : une demande, une inscription, une demande d’assistance. Lorsqu’un formulaire est difficile à utiliser, ce visiteur s’en va, tout simplement. Les formulaires accessibles suppriment les obstacles courants : un champ sans véritable étiquette, une erreur indiquée seulement en rouge, une commande trop petite pour être touchée, ou un ordre de focus qui saute dans tous les sens. Bien conçu, le même formulaire sert au même titre l’utilisateur de souris, celui du clavier seul et celui d’un lecteur d’écran.
Ces formulaires accessibles respectent les directives WCAG 2.2 dès le départ, et non après coup. Chaque champ est étiqueté et associé par programmation, les commandes groupées utilisent fieldset et legend, les erreurs sont décrites avec des mots à côté du champ et dans un récapitulatif qui prend le focus, et vos réponses sont conservées lorsqu’une correction est nécessaire : personne n’a à ressaisir tout un formulaire à cause d’une seule erreur.
Vous pouvez voir cette approche appliquée à des projets réels dans nos étude de cas sur l’accessibilité web, en savoir plus sur l’ extension Accessible Forms, ou contacter M/S. Anblik pour discuter de votre propre site. Vous pouvez aussi parcourir autres démos d’extensions accessibles sur ce site.
Questions
Formulaires accessibles : questions fréquentes
Les formulaires accessibles ont-ils besoin d’un CAPTCHA ?
Non. Un CAPTCHA à énigme est en soi un obstacle. Ces formulaires arrêtent la plupart des robots grâce à un piège invisible (honeypot) et à une vérification du temps de soumission, qui n’ajoutent aucun effort pour les vrais visiteurs et respectent l’authentification accessible de WCAG 2.2.
Ces formulaires fonctionnent-ils sans JavaScript ?
Oui. Sur un site en production, le serveur valide le formulaire et le réaffiche avec vos valeurs conservées et la liste des erreurs. JavaScript ne fait qu’améliorer la gestion du focus et ajouter une vérification anticipée. Un formulaire accessible ne devrait jamais dépendre de scripts pour être utilisable.
Puis-je utiliser ces formulaires en dehors de l’éditeur de blocs ?
Oui. Un code court place n’importe quel formulaire dans l’éditeur classique, dans les widgets et dans les constructeurs de pages tels qu’Elementor, Beaver Builder et Divi. Le bloc et le code court produisent le même balisage accessible.