Formulaires de contact accessibles et acte européen sur l’accessibilité

Un formulaire de contact est souvent la seule porte entre un visiteur et votre entreprise. Si cette porte ne peut s’ouvrir qu’avec une souris, une bonne vue et la patience de résoudre une énigme en image floue, certaines personnes restent tout simplement dehors. Depuis la mi-2025, ce n’est plus seulement une question d’ergonomie : pour de nombreuses entreprises qui vendent à des consommateurs dans l’UE, c’est devenu une question juridique.

Ce que couvre l’acte européen sur l’accessibilité

L’acte européen sur l’accessibilité (directive (UE) 2019/882) s’applique depuis le 28 juin 2025. Il fixe des exigences d’accessibilité pour certains produits et services proposés aux consommateurs – parmi lesquels le commerce électronique, les services bancaires aux consommateurs, les livres numériques, les communications électroniques et certains éléments du transport de passagers. Pour un site web, cela concerne la boutique en ligne ou le service bancaire dans son ensemble, y compris les formulaires que les clients utilisent pour vous contacter, poser des questions ou formuler des réclamations. Les microentreprises qui fournissent des services en sont exemptées : les entreprises qui emploient moins de dix personnes et dont le chiffre d’affaires annuel ou le total du bilan annuel n’excède pas 2 millions d’euros. Les offres destinées exclusivement à d’autres entreprises ne relèvent en général pas de son champ d’application.

Chaque État membre a transposé la directive en droit national. En Allemagne, il s’agit du Barrierefreiheitsstärkungsgesetz (BFSG), en Pologne d’une loi de 2024 visant à garantir que certains produits et services satisfont aux exigences d’accessibilité. Les autorités de surveillance et les sanctions varient d’un pays à l’autre, mais la référence technique est globalement la même : en pratique la norme européenne EN 301 549, qui s’appuie elle-même sur les règles pour l’accessibilité des contenus web (WCAG).

Pourquoi cela vaut la peine même sans obligation légale

Peut-être votre entreprise est-elle exemptée, ou ne servez-vous que d’autres entreprises. Les formulaires accessibles en valent tout de même la peine, pour une raison simple : chaque personne qui abandonne en cours de route est une demande que vous ne recevrez jamais. Les corrections qui aident un utilisateur de lecteur d’écran aident aussi quelqu’un qui remplit le formulaire sur un téléphone dans le train, en plein soleil, avec un poignet cassé ou dans une langue qui n’est pas la sienne. Des libellés clairs et des messages d’erreur utiles signifient moins de formulaires abandonnés pour tout le monde – et aucun d’entre eux n’affaiblit votre protection anti-spam.

Une liste de contrôle pratique avec renvois aux WCAG 2.2

• Des libellés visibles liés à leurs champs (1.3.1, 3.3.2) : chaque champ possède un libellé visible qui lui est associé via for/id. Un texte indicatif (placeholder) seul n’est pas un libellé – il disparaît dès que quelqu’un commence à taper.
• Des messages d’erreur qui expliquent la correction (3.3.1, 3.3.3) : nommez le champ, dites ce qui ne va pas et comment le corriger – en texte, et pas seulement par une bordure rouge. « Veuillez saisir une adresse e-mail du type name@example.com » vaut mieux que « Saisie invalide ».
• Utilisation complète au clavier (2.1.1, 2.1.2) : chaque champ, case à cocher, CAPTCHA et le bouton d’envoi peuvent être atteints et utilisés avec Tab, Espace et Entrée, sans piège au clavier.
• Focus visible (2.4.7) : on voit toujours quel champ est actif. Supprimer le contour de focus du navigateur sans le remplacer ne satisfait pas à ce critère.
• Contraste suffisant (1.4.3) : le texte, les libellés et les messages d’erreur présentent un rapport de contraste d’au moins 4.5:1 par rapport à l’arrière-plan (3:1 pour les grands textes).
• Taille de la cible (2.5.8) : les boutons, cases à cocher et liens mesurent au moins 24 × 24 pixels CSS, ou disposent d’un espacement suffisant autour d’eux.
• Alternatives aux CAPTCHA (1.1.1) et authentification accessible (3.3.8) : le critère 1.1.1 exige une alternative textuelle et un CAPTCHA proposé sous plus d’une forme sensorielle ; le critère 3.3.8 couvre strictement les étapes de connexion, mais son idée s’applique aussi ici – une énigme comme recopier des lettres déformées ou résoudre une addition ne devrait pas être le seul moyen de passer. Proposez une alternative ou utilisez une méthode qui ne nécessite aucune énigme.
• Des honeypots masqués aux technologies d’assistance : le champ piège reçoit aria-hidden="true" sur son conteneur et tabindex="-1", afin que les utilisateurs de lecteurs d’écran et de clavier n’y aboutissent jamais.

CAPTCHA et honeypots : là où la protection anti-spam rencontre l’accessibilité

À strictement parler, le critère 3.3.8 concerne les étapes de connexion et d’authentification, et non les formulaires de contact. L’idée qui le sous-tend se transpose toutefois bien : taper des lettres déformées, résoudre une addition ou repérer des feux de circulation dans une grille d’images exclut complètement certaines personnes. Les options qui fonctionnent généralement sans aucune énigme – comme Cloudflare Turnstile, Friendly Captcha, un honeypot combiné à un contrôle de durée, ou un filtrage côté serveur comme Akismet – tiennent le spam à l’écart sans demander aux visiteurs de prouver quoi que ce soit. Un honeypot n’est bienveillant que s’il est réellement invisible, y compris pour les lecteurs d’écran et les utilisateurs du clavier :

<div class="hp" aria-hidden="true">
  <label for="hp-website">Laissez ce champ vide</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Testez votre propre formulaire en quinze minutes

1. 1Mettez la souris de côté et remplissez tout le formulaire uniquement au clavier. Pouvez-vous atteindre chaque champ et le bouton d’envoi, et voyez-vous toujours où vous vous trouvez ?
2. 2Envoyez le formulaire vide, puis avec une adresse e-mail erronée. Les erreurs apparaissent-elles sous forme de texte à côté du bon champ, et ce qu’il faut faire est-il clair ?
3. 3Ouvrez la page sur un téléphone ou zoomez le navigateur à 200 %. Tout est-il lisible, les boutons sont-ils faciles à toucher, et une bannière de cookies ou un widget de chat masque-t-il le bouton d’envoi ?
4. 4Activez un lecteur d’écran (VoiceOver, NVDA ou TalkBack) et écoutez : chaque champ est-il annoncé avec son libellé, et le honeypot reste-t-il silencieux ?
5. 5Lancez un contrôle automatisé comme axe-core. Il détecte rapidement les libellés manquants et les problèmes de contraste, mais pas tout – les étapes manuelles ci-dessus restent nécessaires.

Si vous préférez commencer par une vue d’ensemble, formexposed examine vos formulaires publics depuis l’extérieur, sans rien soumettre. Ses contrôles d’accessibilité exécutent axe-core sur chaque formulaire, signalent les CAPTCHA sans alternative accessible et les honeypots annoncés par les lecteurs d’écran, et examinent le formulaire sur un téléphone – zones tactiles, éléments superposés masquant le bouton d’envoi, défilement horizontal. La vérification gratuite indique le niveau global ; ces détails figurent dans le rapport complet. C’est un bon point de départ pour la liste ci-dessus, pas un substitut aux tests avec de vraies personnes.