Tests et outils

Corriger et revérifier les problèmes d'accessibilité sur un site client WordPress

Ce guide suit une page d'un site WordPress de la première analyse à la nouvelle vérification. Le site est une démonstration que nous avons créée pour cet article le 08.11.26, pas un site client : WordPress 6.8.3, le thème par défaut Twenty Twenty-Five et une page d'accueil avec le type de contenu qu'une agence récupère habituellement. Tous les constats et mesures ci-dessous proviennent de ce site. Les vérifications ont été faites avec axe-core 4.13.0, le moteur de règles qu'AllyProof utilise avec HTML_CodeSniffer ; une analyse AllyProof de la même page peut donc signaler des constats supplémentaires.

Ce que la première analyse a trouvé

Trois groupes de problèmes, tous classés sérieux :

Constat	Où	WCAG
Contraste du texte 2,52:1 (4,5:1 requis)	Paragraphe d'introduction avec une couleur de texte grise personnalisée (#a3a3a3 sur blanc)	1.4.3
Lien sans nom accessible	Logo lié dont le texte alternatif a été laissé vide	2.4.4, 4.1.2
Une liste contient une liste	Navigation d'en-tête : le repli par défaut « Liste des pages » a produit un ul directement dans le ul de navigation	1.3.1

Le troisième n'a pas été ajouté volontairement. Il provient de l'en-tête par défaut de WordPress sur un site où personne n'avait encore créé de menu, ce qui correspond à de nombreux sites clients fraîchement transmis.

Ce que l'analyse ne pouvait pas voir

Deux problèmes de la même page ont passé toutes les règles automatisées :

• Une photo porteuse de sens marquée comme décorative. Quand le texte alternatif du bloc Image reste vide, WordPress génère alt="". Les lecteurs d'écran ignorent alors l'image. Pour une photo de l'accueil du cabinet, cela masque du contenu - mais seule une personne peut décider si une image a du sens, donc aucune règle ne le signale.
• Un texte indicatif utilisé comme seule étiquette. Le formulaire d'inscription collé contenait un champ e-mail avec placeholder="Your email" et sans étiquette. axe-core accepte le texte indicatif comme nom accessible, la règle passe donc, mais l'indication disparaît dès que l'on tape. Une étiquette visible est la correction fiable.

Notez ces points comme revue manuelle à côté des constats automatisés : la transmission reste honnête, le résultat d'analyse est une première liste, pas la liste complète.

Les corrections, dans l'éditeur WordPress

1. Contraste. Sélectionnez le paragraphe, ouvrez Styles > Couleur > Texte et choisissez une couleur plus foncée. Nous avons utilisé #525252, qui atteint 7,81:1 sur blanc. Préférez une couleur de la palette du thème pour que les modifications futures restent cohérentes.
2. Logo lié. Sélectionnez le bloc Image et renseignez le Texte alternatif. Pour une image servant de lien, décrivez la destination : « À propos de Riverside Dental ».
3. Photo de l'accueil. Ajoutez un texte alternatif qui dit ce que montre l'image : « Comptoir d'accueil du cabinet Riverside Dental ». Si une image est réellement décorative, un texte alternatif vide est correct - à condition que ce soit un choix délibéré et non un réglage par défaut.
4. Navigation. Dans l'Éditeur de site, sélectionnez la Navigation de l'en-tête, puis la Liste des pages qu'elle contient, et convertissez-la en liens individuels (l'éditeur propose une action de modification sur le bloc Liste des pages ; le libellé varie selon les versions). Le menu affiche ensuite une seule liste de liens.
5. Formulaire d'inscription. Dans le bloc HTML personnalisé, ajoutez une étiquette visible <label for="newsletter-email">Adresse e-mail</label>, donnez au champ l'id correspondant et ajoutez autocomplete="email". Si le formulaire provient d'un service d'e-mailing, vérifiez d'abord si son éditeur de formulaire propose un réglage d'étiquette, pour que la correction résiste à un nouveau collage.

La nouvelle vérification

La même exécution d'axe-core après les modifications n'a renvoyé aucun constat automatisé, à 1280 pixels et à 375 pixels de large (où le thème replie la navigation). Les deux points de revue manuelle ont été résolus par les modifications des étapes 3 et 5.

Ce qu'une personne doit encore vérifier avant d'annoncer au client que la page est terminée :

• Parcourez la page avec la touche Tab : tous les liens, le bouton du menu et le formulaire sont atteignables, le focus est visible et l'ordre est logique.
• Ouvrez et fermez le menu mobile au clavier et avec un lecteur d'écran.
• Lisez les textes alternatifs à voix haute dans leur contexte : transmettent-ils ce qu'un visiteur voyant retire de l'image ?
• Envoyez le formulaire vide puis avec une adresse invalide, et vérifiez que l'erreur est annoncée et expliquée.

Le même cycle avec AllyProof

Le test gratuit d'une page affiche les constats automatisés pour une URL. Après avoir déployé une correction, utilisez Lancer une nouvelle analyse sur le résultat : sinon, un test répété dans les 24 heures affiche le résultat en cache, ce qui ne serait pas une nouvelle vérification. Pour un site client que vous maintenez, ajoutez-le comme site : chaque analyse suivante - manuelle ou planifiée (mensuelle en Free, hebdomadaire en Business) - marque comme résolus les problèmes qu'elle ne trouve plus, et l'historique montre quelles corrections ont abouti. Business coûte 35 € par site et par mois, ou 336 € par site et par an, avec un essai de 14 jours pour les comptes éligibles (moyen de paiement requis ; renouvellement jusqu'à résiliation).

Pour le point client, envoyez trois éléments : ce qui a été trouvé et corrigé, avec les dates, ce qu'a montré la nouvelle vérification automatisée, et quelles vérifications manuelles sont terminées ou encore ouvertes. C'est plus utile à un client qu'un score, et cela ne promet pas une conformité qu'une analyse ne peut pas établir.

Questions fréquentes

Pourquoi WordPress génère-t-il alt="" quand le texte alternatif est laissé vide ?

Un attribut alt vide indique aux technologies d'assistance que l'image est décorative et peut être ignorée. C'est correct pour une décoration, mais cela masque une image porteuse de sens. Les outils automatisés ne peuvent pas faire la différence et ne le signalent donc pas.

Pourquoi la navigation WordPress par défaut échoue-t-elle à la règle axe « list » ?

Tant qu'aucun menu n'a été créé, le bloc Navigation des thèmes à blocs se rabat sur une Liste des pages. Dans cet exemple, cela a produit un élément ul directement à l'intérieur d'un autre ul. Convertir la Liste des pages en liens individuels a supprimé la liste imbriquée.

Une nouvelle analyse sans constat signifie-t-elle que le site WordPress est accessible ?

Non. Elle signifie que les règles automatisées exécutées n'ont rien trouvé sur les pages et états testés. L'utilisation au clavier, la visibilité du focus, la restitution par lecteur d'écran et la qualité des textes alternatifs doivent toujours être vérifiées par une personne.