Checklist RGAA pour valider un formulaire de contact avant mise en ligne

Le formulaire de contact est souvent le composant le plus simple d’un site, et pourtant l’un des plus fréquemment recalés en audit RGAA : labels manquants, champs obligatoires signalés par un seul astérisque sans explication, message de succès qui s’affiche sans être annoncé à un lecteur d’écran. Cette checklist couvre les douze points que nous vérifions systématiquement avant de considérer un formulaire de contact prêt pour la mise en ligne, sur un thème classique comme sur une page construite avec l’éditeur de blocs.

Elle ne remplace pas un audit RGAA complet mené par un expert, mais elle referme l’essentiel des non-conformités qui reviennent projet après projet sur ce composant précis.

Les douze points de contrôle

1. Chaque champ possède un <label> relié par l’attribut for à l’id du champ, jamais un simple texte placé à côté sans association technique.
2. Le placeholder n’est jamais utilisé comme seul label. Il disparaît à la saisie et n’est pas systématiquement restitué par tous les lecteurs d’écran de la même façon qu’un label persistant.
3. Les champs obligatoires sont signalés dans le texte, pas seulement par un astérisque coloré : « Nom (obligatoire) » ou un texte d’introduction explicite au début du formulaire expliquant la convention utilisée.
4. L’attribut required est posé en HTML sur les champs concernés, ce qui déclenche la validation native du navigateur et l’annonce correspondante par les lecteurs d’écran.
5. Le regroupement de champs liés (adresse postale en plusieurs champs, par exemple) utilise <fieldset> et <legend> plutôt qu’un simple titre visuel au-dessus du bloc.
6. Les cases à cocher et boutons radio ont chacun leur propre <label>, et le groupe entier une <legend> décrivant la question posée.

Suite de la checklist

1. Le contraste du texte des labels, des messages d’aide et des placeholders respecte un ratio de 4,5:1 minimum sur son fond.
2. Les messages d’erreur sont associés à leur champ via aria-describedby, et jamais transmis par la couleur seule.
3. Le focus visuel reste visible sur chaque champ, bouton et lien du formulaire, sans outline: none non compensé par un autre style de focus.
4. L’ordre de tabulation suit l’ordre visuel logique du formulaire, sans tabindex positif qui viendrait perturber cet ordre naturel.
5. Le message de confirmation d’envoi est soit placé dans le flux de tabulation avec un focus déplacé vers lui, soit annoncé via une région aria-live, jamais affiché silencieusement en haut de page pendant que le focus reste sur le bouton d’envoi.
6. Le champ CAPTCHA, s’il existe, propose une alternative accessible (audio, ou mieux, une solution sans interaction comme une vérification invisible côté serveur).

Exemple d’un champ conforme

<label for="contact-telephone">Téléphone (obligatoire)</label>
<input type="tel" id="contact-telephone" name="telephone" required
       aria-describedby="telephone-aide">
<p id="telephone-aide" class="aide-champ">Format attendu : 10 chiffres, sans espace.</p>

Le message de confirmation, souvent oublié

<div role="status" aria-live="polite">
  <p>Votre message a bien été envoyé, nous vous répondrons sous 48 heures.</p>
</div>

Le rôle status associé à aria-live="polite" garantit que ce message est annoncé dès son apparition, sans avoir à déplacer le focus, ce qui convient bien à une confirmation qui n’exige aucune action supplémentaire de l’utilisateur.

Ce que cette checklist ne couvre pas

Elle ne traite pas des formulaires à plusieurs étapes, qui posent des questions supplémentaires sur l’annonce de la progression et la conservation des données entre les étapes — un sujet suffisamment vaste pour mériter son propre traitement séparé.

En résumé

Un formulaire de contact conforme au RGAA ne demande aucune bibliothèque particulière : uniquement du HTML sémantique bien structuré, des attributs ARIA ciblés là où le HTML seul ne suffit pas, et un test final au clavier suivi d’une lecture complète avec un lecteur d’écran avant la mise en ligne définitive.