# Contact Form 7 et les messages d’erreur non annoncés : le correctif à appliquer

> Un formulaire Contact Form 7 affiche ses erreurs de validation à l'écran mais reste muet pour un lecteur d'écran. Diagnostic du balisage par défaut et correctif par une région annoncée.

- Auteur : Clément Hadrot
- Publié le : 2026-06-17
- Mis à jour le : 2026-06-17
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/contact-form-7-messages-erreur-non-annonces/

## L’essentiel

- Les erreurs de Contact Form 7 s'affichent visuellement sans être annoncées
- Une région aria-live encadre le résumé d'erreurs après soumission
- Le correctif s'ajoute par filtre, sans toucher au cœur du plugin

`wpcf7-not-valid-tip` : c'est la classe CSS que Contact Form 7 attribue par défaut à chaque message d'erreur de champ, visible en rouge sous le champ concerné après une tentative de soumission invalide. Le problème ne se voit pas dans le CSS mais dans le HTML généré : ce message n'est associé à aucune région annoncée dynamiquement, et un lecteur d'écran ne signale strictement rien au moment où il apparaît.

Un utilisateur voyant comprend immédiatement qu'un champ pose problème grâce à la couleur et à la position du message. Un utilisateur non-voyant, lui, reste au même endroit du formulaire sans aucune indication qu'une erreur vient de survenir, sauf à retourner manuellement au champ pour vérifier.

## Diagnostic : un DOM mis à jour sans annonce

En inspectant le comportement après soumission, Contact Form 7 insère bien dynamiquement les messages d'erreur dans le DOM via JavaScript, mais le conteneur englobant, généralement une `<div class="wpcf7-response-output">`, ne porte par défaut ni `role="alert"` ni `aria-live`. Résultat : la mise à jour du DOM est invisible pour la technologie d'assistance, qui n'a aucune raison de la lire à voix haute puisque rien ne signale qu'il s'agit d'une zone à surveiller.

C'est un défaut classique de formulaire AJAX : le contenu change visuellement, mais rien dans le balisage n'indique qu'un changement mérite d'être annoncé immédiatement plutôt qu'ignoré silencieusement, comme le sont la plupart des mises à jour du DOM en continu.

> L'essentiel à retenir : Les erreurs de Contact Form 7 s'affichent visuellement sans être annoncées ; Une région aria-live encadre le résumé d'erreurs après soumission ; Le correctif s'ajoute par filtre, sans toucher au cœur du plugin

## Le correctif : encadrer la sortie de réponse avec aria-live

Contact Form 7 propose un hook dédié, `wpcf7_form_response_output`, qui filtre le HTML de la zone de réponse avant son insertion. On peut s'en servir pour ajouter les attributs manquants sans toucher aux fichiers du plugin :

```
add_filter( 'wpcf7_form_response_output', function ( $output, $class, $content, $contact_form, $result ) {
    $status = $result->status;

    if ( in_array( $status, array( 'validation_failed', 'spam', 'aborted' ), true ) ) {
        $output = str_replace(
            'class="' . esc_attr( $class ) . '"',
            'class="' . esc_attr( $class ) . '" role="alert" aria-live="assertive"',
            $output
        );
    }

    return $output;
}, 10, 5 );
```

Le choix de `aria-live="assertive"` plutôt que `polite` est volontaire : une erreur de validation bloquante justifie une interruption immédiate de la lecture en cours, contrairement à une simple mise à jour de confort qu'on préférerait annoncer sans couper l'utilisateur.

## Traiter aussi les champs individuels

Le correctif ci-dessus couvre le résumé global d'erreurs, mais chaque message individuel sous un champ mérite également d'être associé au champ concerné via `aria-describedby`, pour qu'un lecteur d'écran annonce l'erreur au moment où l'utilisateur revient sur le champ, pas seulement lors du résumé global.

- Ajouter un identifiant unique à chaque `span.wpcf7-not-valid-tip` généré
- Référencer cet identifiant dans l'attribut `aria-describedby` du champ correspondant, via un script exécuté après l'événement `wpcf7invalid` déclenché par le plugin
- Vérifier que l'attribut `aria-invalid="true"` est bien positionné sur le champ en erreur, ce que Contact Form 7 fait déjà correctement par défaut

## Vérifier le correctif sans lecteur d'écran complet

Pour un contrôle rapide sans monter un environnement NVDA complet, l'onglet Accessibility des outils de développement du navigateur permet de suivre en direct l'arbre d'accessibilité et de repérer si le rôle `alert` apparaît bien au bon moment. Un test complet à la voix reste néanmoins nécessaire avant mise en production, l'onglet navigateur ne garantissant pas le comportement exact de chaque lecteur d'écran.

## Prévention

Ce défaut concerne en réalité la plupart des plugins de formulaire qui gèrent leur validation entièrement en JavaScript côté client sans prévoir de région annoncée par défaut. Avant d'adopter une extension de formulaire pour un projet, un test de soumission invalide au clavier avec un lecteur d'écran actif permet de repérer ce genre de lacune avant qu'elle ne se généralise sur plusieurs formulaires du même site.