Test d’accessibilité - EZZE WCAG Pro Documentation

Contrôles automatiques pour une URL unique ou des exécutions par lots sur de nombreuses pages.

Avec le forfait Free, le tableau de bord affiche la couverture des tests sans état des lots. Les redirections automatiques, les tests en arrière-plan et la programmation sont disponibles à partir de Basic. Les sections s’intitulent « Tester une page » et « Tester plusieurs pages ».

Le masquage intégré comprend des intégrations pour Borlabs Cookie 2.x et 3.x ; consulte la section sur les versions des bannières pour les versions vérifiées et les correctifs EZZE nécessaires. Il s’applique uniquement aux requêtes de test munies d’une clé valide ; les réglages des bannières pour les visiteurs ordinaires restent inchangés. Les captures enregistrées ne sont pas modifiées : lance un nouveau test après une correction. Les dates et heures suivent le format de la vue concernée ; le format de l’heure provient de WordPress, dans Réglages → Général (par exemple, H:i pour le format 24 heures).

Avant le premier test : activer les fonctions cloud

Le Accessibility Test s’exécute via le service cloud EZZE. Tant que la connexion cloud gratuite n’est pas active, la page de test affiche donc une carte d’activation complète à la place du formulaire de lancement. Le titre de la page et l’aide restent disponibles ; la feuille d’aide distingue l’offre Free des offres payantes et explique le périmètre et les limites correspondants, les types de test disponibles, l’interprétation des résultats, les problèmes de démarrage courants, le traitement cloud et le quota d’URL. La navigation de test et les réglages ne s’affichent qu’après l’activation et ne peuvent pas être ouverts auparavant à l’aide d’un lien direct vers un onglet. Ouvrir l’activation des Fonctionnalités Cloud ouvre le panneau Fonctionnalités Cloud dans le Tableau de bord, où vous démarrez l’activation gratuite Freemius. Aucune clé de licence ni information de paiement n’est requise. Lors d’une première activation, la barre latérale et la liste de résultats vide sont masquées afin que l’activation reste la prochaine étape claire. Les résultats déjà enregistrés restent visibles. Si la confirmation par e-mail est encore en attente, vous pouvez poursuivre l’activation ou renvoyer l’e-mail.

Ce qu’il fait

Le Accessibility Test exécute une analyse d’accessibilité dans le navigateur (règles de type axe) comparable aux outils de développement courants. Les résultats sont détaillés avec gravité et pistes de remédiation.

Pourquoi l’utiliser

Automatisation : détecte une partie des problèmes (souvent ~30–40 % des échecs WCAG détectables automatiquement)
Suivi : les réexécutions montrent les tendances
Priorisation : met d’abord en avant les constats fréquents ou graves
Historique : la chronologie documente l’effort
QA de publication : à lancer avant ou après publication

Limites

Réexécutions par URL : illimitées sur tous les plans (même URL rejouable librement)
URLs distinctes par mois :

Important : chaque URL normalisée ne compte qu’une fois par mois vers le plafond, même si tu la testes souvent. Les vues ordinateur et mobile produisent des résultats séparés, mais ne consomment pas une deuxième URL pour la même adresse. Les différences limitées au protocole, à la casse de l’hôte, aux ports par défaut, au slash final ou aux paramètres de suivi ne créent pas une autre entrée ; les paramètres de requête ayant une signification fonctionnelle restent distincts.

Bannières de cookies, bots et capture du viewport

La capture du viewport est activée par défaut pour les nouveaux réglages, y compris avec Free. Tu peux la désactiver à tout moment ; une désactivation déjà enregistrée est conservée lors des mises à jour. Cela ne remplace pas l’activation obligatoire du cloud et ne lance aucun test automatiquement.

Si tu actives la capture optionnelle du viewport dans les réglages du Accessibility Test, le mode de capture dépend de l’offre. Avec Free, l’aperçu compact provient de la même exécution PageSpeed que le score et les contrôles ; l’exécution effectue aussi le travail de performance nécessaire à l’image et peut donc durer un peu plus longtemps. À partir de Basic, l’extension envoie au proxy EZZE une tâche distincte de capture haute résolution immédiatement après l’enregistrement du résultat. Le résultat n’attend pas : l’emplacement de l’image affiche un état de chargement pendant le traitement de la file séparée, puis la capture terminée est enregistrée avec le résultat.

L’aperçu Free appartient exactement à l’exécution évaluée. À partir de Basic, la capture haute résolution est techniquement un chargement de page séparé effectué juste après ; elle peut donc différer si la page change pendant ce court intervalle. La file réessaie les erreurs temporaires un nombre limité de fois et termine chaque tâche dans un délai maximal de 15 minutes. Si la capture échoue encore, la zone affiche La capture d’écran n’a pas pu être créée. L’action en dessous devient Retester le contenu et lance un nouvel Accessibility Test. Une tâche terminée ou expirée n’est pas reprise à un moment ultérieur arbitraire.

L’extension ne peut pas accepter une boîte de dialogue de consentement ni pré-positionner des cookies : seuls ton site et ta pile de consentement déterminent ce que voit l’exécution automatisée.

Capture : une superposition de consentement peut rester visible sur la miniature même si votre CMP active des options comme cookies pour bots/crawlers. Causes fréquentes : le user-agent ne classe pas le client de mesure cloud comme prévu, une autre couche affiche une bannière (thème, tag manager, scripts, version du CMP), ou le moment de la capture coïncide encore avec l’overlay.
Audits / score : une superposition de cookies ou de consentement peut modifier fortement le résultat : tant qu’une bannière ou une fenêtre modale bloque ou masque le contenu, une grande partie de la page peut échapper aux contrôles automatisés et tous les éléments ne sont pas réellement testés. Les audits et le score peuvent différer nettement de ce qu’un visiteur voit après acceptation des cookies — pas seulement sur la miniature.
Prochaines étapes pratiques : consultez la documentation de votre fournisseur de consentement (bots/crawlers, outils de mesure, URL de prévisualisation documentées). Les développeurs peuvent utiliser le filtre WordPress ezzewcag_accessibility_test_cloud_url pour ajouter uniquement pour le test cloud des paramètres de requête documentés par le fournisseur.

Remarque : les mesures techniques ne remplacent pas votre propre revue vie privée / conformité. Si vous reposez sur des exceptions bots/crawlers, vérifiez auprès du fournisseur si le trafic de mesure du Accessibility Test cloud est couvert.

Masquer la bannière de cookies (réglages du Accessibility Test)

Dans les réglages du Accessibility Test, tu peux activer Bannières de cookies dans les tests. L’extension ajoute alors une clé cachée uniquement à l’URL utilisée pour l’exécution cloud. Ton site peut reconnaître cette seule requête et masquer la bannière de cookies pour la mesure automatisée. Les visites normales restent inchangées, mais la bannière de cookies elle-même n’est pas testée tant que l’option est activée.

Les services pris en charge et le dépannage peuvent être dépliés directement dans le réglage. Sous Réglages techniques, tu peux consulter la clé actuelle. Génère une nouvelle clé uniquement si la clé actuelle a pu être divulguée.

Pour les requêtes de test valides, l’extension envoie automatiquement des en-têtes anti-cache et définit le signal WordPress DONOTCACHEPAGE. Cela protège les caches de pages qui laissent la requête atteindre WordPress. Tu ne dois exclure de ce cache les requêtes contenant ezzewcag_cmp que si un cache en amont ou un CDN ignore complètement les paramètres d’URL. Les visiteurs ordinaires n’ont pas besoin d’ouvrir le lien de test pour que ce cas particulier puisse se produire.

Versions des bannières de cookies et limites de prise en charge

Date de vérification : 11 septembre 2026. Ces indications concernent le masquage pendant l’Accessibility Test, pas la compatibilité générale ni la politique de maintenance du fournisseur. Le masquage est également disponible avec Free ; un forfait payant ne résout pas une version de bannière incompatible.

Bannière / version	Intégration et vérification
Borlabs Cookie 2.x	Intégration dédiée à l’ancienne structure du frontend ; 2.2.34 vérifiée avec succès sur une installation réelle avec le correctif EZZE et une nouvelle capture du résultat. Cela ne signifie pas que toutes les versions 2.x ont été testées.
Borlabs Cookie 3.x	Intégration distincte utilisant les interfaces 3.x. La vérification de 2.2.34 ne valide pas une sous-version particulière de 3.x.
Borlabs Cookie 1.x	Aucune intégration documentée ni prise en charge confirmée. Avant de changer, vérifie la version cible prise en charge par le fournisseur et la procédure de migration.
Complianz, Cookiebot, Real Cookie Banner, iubenda	Intégrations fournies via les interfaces respectives des extensions. Aucune liste exhaustive de versions testées ni version minimale chiffrée confirmée. Il faut vérifier l’installation concernée.
CookieYes / ancien GDPR Cookie Consent	Intégration via l’ancien hook de l’extension. Aucune limite de version chiffrée confirmée entre cette intégration et celle de l’application web.
CookieYes connecté à son application web	Un autre mécanisme supprime le script de chargement externe de `cdn-cookieyes.com`. Les scripts hébergés localement, modifiés ou injectés autrement ne sont pas automatiquement couverts.

D’autres scripts externes de OneTrust, Osano, Termly, Quantcast Choice, Didomi, TrustArc, Usercentrics, CookieScript et CookieFirst sont supprimés à partir de domaines de scripts connus. Cela ne garantit pas toutes les versions ou méthodes d’installation. Les bannières personnalisées et les autres intégrations peuvent nécessiter l’adaptation pour développeurs décrite ci-dessous.

Bannière visible : vérification des versions et conseils pour le support

Relève le nom et la version exacte de la bannière, la version EZZE avec son état de correctifs/build, l’URL concernée et la date et l’heure du test. « Détecté » confirme la détection de l’extension, pas le masquage réussi dans cette configuration.
Vérifie que l’activation cloud est terminée et que le masquage est activé. Vérifie ensuite les caches/CDN et les bannières supplémentaires provenant du thème, du gestionnaire de balises ou d’autres extensions.
Pour Borlabs 2.x, EZZE doit inclure le correctif de l’ancienne intégration. Le paquet Free 1.0.0 généré initialement ne contient pas ce correctif ultérieur ; une installation corrigée individuellement peut toujours afficher 1.0.0. Vérifie le paquet et le journal des modifications. Le paquet 1.0.0 généré de nouveau via Freemius le 11 septembre 2026 contient le correctif (preuve de compilation : 34634511889). Les anciens téléchargements portant le même numéro de version ne le contiennent pas automatiquement. La solution vérifiée avec 2.2.34 ne nécessite pas de passer à Borlabs 3.x.
Recommande des mises à jour ciblées : une mise à jour EZZE n’aide que si le paquet disponible contient le correctif concerné. Une mise à jour de la bannière peut convenir pour une version sans intégration ou un correctif confirmé par le fournisseur ; vérifie d’abord la version cible et les consignes de migration. N’invente pas de version minimale et ne promets pas qu’une mise à jour résoudra le problème sans preuve.
Lance ensuite un nouveau test. Les captures enregistrées ne changent pas rétroactivement. Si la bannière reste visible, transmets les informations ci-dessus et la nouvelle capture au support, mais jamais la clé secrète du test ni une URL contenant sa valeur.

Exemple de réponse du support : « Borlabs Cookie 2.x nécessite l’intégration EZZE correspondante. Le masquage a été vérifié avec Borlabs 2.2.34 et le correctif EZZE. Vérifie d’abord si ton installation EZZE contient ce correctif, active le masquage et lance un nouveau test. Il n’est pas nécessaire de passer systématiquement à Borlabs 3.x pour cela. »

Pour les développeurs : CMP non intégré dans l’extension

Indicateur d’URL documenté : si le fournisseur documente un paramètre de requête qui désactive ou saute la bannière (aperçu, mesure, mode bot, etc.), ajoute-le avec le filtre ezzewcag_accessibility_test_cloud_url (exemple ci-dessous). L’extension enregistre son paramètre secret avec la priorité 15. Utilise une priorité plus basse (p. ex. 10) pour que les deux finissent dans l’URL, ou plus haute (p. ex. 20) si ton callback doit voir l’URL après ajout de la clé.
Hooks PHP documentés : accroche ezzewcag_accessibility_test_register_cmp_bypass. Il ne s’exécute que lorsqu’un contournement valide est détecté (secret correct dans la chaîne de requête et réglage activé). Dans ton callback, enregistre les filtres du CMP pour que la bannière ne se charge pas pour cette requête uniquement. L’extension déclenche cette action tôt sur plugins_loaded et init.
Détection personnalisée : si le cache ou le proxy supprime la chaîne de requête mais que tu peux encore identifier la mesure cloud (p. ex. User-Agent), étends la détection avec le filtre ezzewcag_accessibility_test_cmp_bypass_active. Il reçoit le booléen par défaut et le nom du paramètre configuré.
Renommer le paramètre : seulement si ta pile l’exige : filtre ezzewcag_accessibility_test_cmp_bypass_query_arg. Le même nom doit être utilisé côté serveur lors de la lecture.

Dans du code personnalisé, appelle WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() pour vérifier si le contexte de contournement s’applique à la requête HTTP en cours.

Exemple : hooks d’un CMP personnalisé via l’action de l’extension

Remplace la ligne commentée par des filtres ou appels décrits dans la documentation développeur de ton CMP. Cet extrait n’est pas fourni avec l’extension. Le functions.php du thème enfant suffit en général. Utilise un MU plugin ou une petite extension dédiée seulement si tu veux que le code reste actif lors d’un changement de thème (ou si tu n’utilises pas de thème enfant).

<?php
/**
* Uniquement pendant un contournement valide du test cloud (secret dans l’URL + réglage actif).
* Enregistre les hooks de ton CMP pour masquer la bannière uniquement pour ce chargement.
*/
add_action(
'ezzewcag_accessibility_test_register_cmp_bypass',
static function () {
if ( ! class_exists( 'WCAG_Accessibility_Test_CMP_Bypass' ) ||
! WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() ) {
return;
}
// Exemple : add_filter( 'your_cmp_show_banner', '__return_false' );
}
);

Exemple de code (développeurs) : paramètres de requête pour le test cloud

Ce code n’est pas fourni avec l’extension. Placez-le dans un MU plugin (recommandé : p. ex. wp-content/mu-plugins/wcag-cloud-test-consent-tweaks.php) ou dans le functions.php du thème enfant. Sauvegardez d’abord ; déployez seulement si vous comprenez l’impact.

Paramètres de requête réservés aux tests cloud (filtre de l’extension)

À utiliser lorsque votre CMP documente un indicateur d’URL pris en charge pour les flux de prévisualisation / consentement. Remplacez YOUR_QUERY_KEY et YOUR_QUERY_VALUE par les noms exacts du fournisseur ; sinon n’utilisez pas cette approche. Le filtre s’applique à chaque exécution cloud du Accessibility Test, sauf si vous ajoutez vos propres conditions dans le callback.

<?php
/**
* Uniquement pour les exécutions cloud EZZE WCAG Pro : ajuster l’URL avant la requête proxy.
*
* Personnaliser : YOUR_QUERY_KEY / YOUR_QUERY_VALUE selon la documentation du CMP.
*/
add_filter(
'ezzewcag_accessibility_test_cloud_url',
static function ( $url, $strategy, $post_id, $page_type ) {
return add_query_arg(
'YOUR_QUERY_KEY',
'YOUR_QUERY_VALUE',
$url
);
},
10,
4
);

Lots manuels : plafond quotidien

Par site et par jour civil (fuseau horaire WordPress Réglages → Général), jusqu’à 10 lancements de lot manuel protègent l’infrastructure. Les exécutions planifiées ou déclenchées à la publication suivent des règles distinctes.

Modes

Test unitaire (Free) :

Tester une URL
Tu peux rechercher dans la liste groupée du sélecteur de contenu. Les catégories et les entrées défilent ensemble. Appuie sur Échap pour fermer la liste et ramener le focus au champ de sélection.
Le sélecteur affiche le titre et le chemin URL sur une seule ligne compacte, sans le domaine du site actuel. La recherche inclut aussi l’URL complète. Au survol du bouton d’information ou au focus sur une entrée, le titre complet et le permalien apparaissent à côté du bouton d’information. Sur les vues étroites, le chemin est masqué ; le bouton d’information permet de consulter l’adresse complète avant de sélectionner le contenu.
Résultats en ligne
Si la réponse du serveur est interrompue dans la vue de test alors que le test continue, la vue effectue de courtes requêtes de statut pour attendre ce même test. Le résultat terminé apparaît automatiquement dans la liste, sans recharger la page ni relancer le test. La récupération attend au maximum dix minutes ; si elle n’aboutit pas, tu peux actualiser la liste des résultats. Un véritable test concurrent reste bloqué.
Liste détaillée des problèmes
Disponible depuis la barre d’administration, l’éditeur ou l’interface de l’extension
Si une erreur temporaire de transport, de limitation des requêtes ou de service empêche le service de test cloud de démarrer un test, l’extension attend brièvement puis relance le démarrage une seule fois. Le message n’explique que le service est temporairement indisponible que si cette tentative échoue également. Les erreurs de quota, d’autorisation et d’URL ne sont pas relancées automatiquement.
Lorsque le test mobile est activé, le test unitaire s’exécute en deux étapes distinctes. Si seule l’étape mobile rencontre un échec temporaire de chargement ou de service, l’extension la relance exactement une fois. Si elle échoue encore, le résultat desktop réussi reste disponible et s’affiche avec une erreur mobile claire.

Tests par lots (à partir de Basic) :

Mettre en file de nombreuses URL à partir de Basic
Traitement en arrière-plan (WP-Cron ou Action Scheduler)
Chaque étape suivante est planifiée de manière persistante ; si une file en cours reste sans worker actif, l’extension reprend automatiquement la même exécution sans retester les pages déjà terminées
Sélectionner types de contenu, archives, taxonomies ou pages spéciales (p. ex. page d’accueil)
Tableau de résultats avec filtres / tris
Les réexécutions écrasent les résultats stockés pour la même URL
Avant l’estimation et le démarrage, la file du lot est dédupliquée avec cette même URL normalisée ; un élément lié à un contenu WordPress publié est prioritaire sur un élément reposant uniquement sur une URL
En cas d’échec de certains éléments (délais dépassés, erreurs temporaires…), retestez en un clic tous les éléments encore en échec de cette exécution, depuis la liste d’erreurs affichée après le lancement
Si seule la vue mobile d’un résultat enregistré échoue, relancez uniquement ce viewport mobile directement depuis la vue détaillée du résultat
L’activité en direct conserve le même contenu pendant toute sa séquence de viewports : après le test ordinateur, son titre reste affiché, la puce ordinateur montre le résultat terminé et la puce mobile passe de Préparation au test en cours. Le contenu ne rejoint la liste des éléments terminés qu’après la fin de tous les viewports activés. Les exécutions limitées à l’ordinateur n’affichent aucune puce mobile ; entre deux contenus, le prochain contenu connu est déjà affiché comme en préparation. Un rechargement restaure le même état à partir des données persistées du worker, de la file et des fins de test. Si vous réactivez l’actualisation automatique après une pause, l’extension synchronise d’abord la vue complète des résultats actuels, puis reprend les mises à jour incrémentielles.
La liste des tests récemment terminés dans l’activité en direct commence vide à chaque nouveau lot et affiche uniquement les résultats de cette exécution. Les nouveaux résultats sont ajoutés sans reconstruire les lignes existantes à chaque interrogation du statut ; les puces de résultat inchangées conservent le focus clavier. Un rechargement restaure l’activité enregistrée de la même exécution.
Tant qu’un test dans le cloud est en attente, son contenu reste visible entre les consultations de statut. L’attente de la prochaine consultation n’affiche pas temporairement le contenu suivant.
Préparation apparaît uniquement tant que le cloud n’a pas confirmé l’exécution de la vue sélectionnée. Pendant l’exécution, son indicateur Ordinateur ou Mobile est actif sans cette mention. Les vues terminées affichent leur résultat ; la vue suivante peut afficher brièvement Préparation avant de démarrer.
Avant le début du test d’un contenu, seule la mention Préparation apparaît. Les badges Ordinateur et Mobile apparaissent au début du test. Pendant la préparation ultérieure de la vue mobile, le résultat ordinateur reste visible et Mobile · Préparation forme un groupe à côté.
Si votre session d’administration expire, les mises à jour en arrière-plan sont suspendues pendant la reconnexion. Aucun avis de session supplémentaire ne masque la fenêtre de connexion WordPress. En l’absence de fenêtre de connexion, un seul avis au maximum apparaît. Après confirmation de la connexion, les vues sont actualisées ; les actions de démarrage, de suppression et d’annulation ne sont pas répétées automatiquement. Le lot continue sur le serveur.

Après publication / mise à jour :

Test automatique optionnel lors de la première publication d’articles / pages (désactivé par défaut)
Test automatique optionnel lors de l’enregistrement d’articles / pages déjà publiés à partir de Basic (désactivé par défaut)
Rôles configurables pour les deux (par défaut : administrateur, éditeur, auteur)
E-mail optionnel après le test à la publication (activé par défaut si le test auto à la publication est activé) et à la mise à jour (désactivé par défaut)

Lots planifiés (à partir de Basic) :

Exécutions récurrentes (hebdomadaire, mensuelle, intervalle personnalisé) à partir de Basic
Cadence configurable
Choisir types de contenu, archives, taxonomies
Exécution via WP-Cron ou Action Scheduler

Intégrations et droits

Points d’entrée :

Barre d’administration : action de test rapide sur le front-end
Panneau de l’éditeur : dans l’éditeur de blocs, la barre latérale Accessibilité affiche les derniers résultats Desktop et Mobile, un lien vers les résultats de l’extension et une action pour lancer un test sur l’URL éditée. L’éditeur classique propose le même panneau dans la boîte Publier s’il est activé. Il apparaît uniquement pour les types de contenu pris en charge et les utilisateurs autorisés à lancer des tests. Le contenu publié peut être testé ; les brouillons suivent les garde-fous documentés.

Capacités :

Qui peut lancer des tests unitaires : configurable (par défaut : administrateur, éditeur)
Qui peut tester le contenu d’autres utilisateurs : configurable (par défaut : administrateurs uniquement)
Qui peut démarrer des lots : configurable (par défaut : administrateurs uniquement)
Qui peut supprimer des résultats : configurable (par défaut : administrateurs uniquement)

Test auto à la publication :

Activer / désactiver (désactivé par défaut)
E-mail optionnel après le test (activé par défaut si le test auto à la publication est activé)
Choisir quels rôles déclenchent les exécutions (par défaut : administrateur, éditeur, auteur)

Test auto à la mise à jour (à partir de Basic) :

Activer / désactiver (désactivé par défaut)
S’exécute lors de l’enregistrement d’un article ou d’une page déjà publié(e)
Utilise la même liste de rôles que le test à la publication
E-mail optionnel après le test à la publication (activé par défaut si le test auto à la publication est activé) et à la mise à jour (désactivé par défaut)
L’e-mail de résultat récapitule l’état, le contenu testé, les scores ordinateur/mobile, la date et les liens directs dans une mise en page adaptative. Sur téléphone, les métriques, les détails et les actions s’empilent, et une version en texte brut est également incluse.

Lots planifiés (à partir de Basic) :

Intervalle : hebdomadaire, mensuel, personnalisé (jours)
Types de contenu : p. ex. article, page
Archives / taxonomies / pages spéciales : selon les réglages proposés
E-mail optionnel après chaque lot manuel ou planifié : distingue clairement les exécutions terminées, échouées et annulées, et n’affiche que les informations utiles, telles que les pages traitées, les problèmes, la durée, le type de test, le viewport, l’initiateur et les dates. Les nouvelles tentatives et les exemples d’erreurs n’apparaissent que s’ils existent. Les alertes de limite indiquent la raison, le périmètre prévu et les étapes suivantes.

Identifiant de support en cas de problème avec une exécution par lots

Si une exécution par lots dure anormalement longtemps, ne progresse plus, échoue ou se termine de façon inattendue, indique son identifiant de support complet dans ta demande d’assistance. Cela permet d’identifier précisément l’exécution concernée. Décris brièvement ce qui s’est passé ainsi que la progression ou le message d’erreur affiché.

Sur la page Test d’accessibilité, ouvre Historique des lots à côté de l’aide. Un panneau latéral s’ouvre sur ordinateur et un panneau inférieur sur téléphone. La dernière exécution est dépliée ; tu peux déplier les précédentes individuellement. Chaque exécution conserve son propre résumé avec état, nombre de pages, début, fin, durée, nouvelles tentatives, périmètre et erreurs de test, ainsi que le type de test, le Viewport et l’utilisateur à l’origine du lancement. Les anciennes exécutions peuvent manquer de données qui n’étaient pas encore enregistrées. La petite icône de copie à côté de l’identifiant de support copie uniquement cet identifiant. Utilise Télécharger le diagnostic pour enregistrer les données. Les e-mails de fin contiennent aussi cet identifiant. Copie toujours la chaîne complète commençant par EW-B-.

L’identifiant de support reste le même lorsque la même exécution reprend. Une nouvelle exécution reçoit un nouvel identifiant. Copier l’identifiant ou télécharger le diagnostic ne crée pas de demande d’assistance.

Signale les problèmes rapidement : les résumés et les événements de diagnostic sont conservés pendant 90 jours, puis supprimés automatiquement. Les exécutions antérieures à l’introduction des identifiants de support n’en reçoivent pas rétroactivement ; dans ce cas, indique ton site web ainsi que la date et l’heure de début de l’exécution concernée.

Résultats

Chaque exécution inclut :

Score global : score d’accessibilité 0–100
Code couleur du score dans la liste des résultats : 90–100 en vert, 50–89 en jaune et 0–49 en rouge. La valeur numérique reste toujours visible afin que l’évaluation ne repose pas uniquement sur la couleur.
Catégories : regroupées par domaines d’audit
Redirections : l’extension vérifie le chemin de redirection avant de lancer un test cloud. Un test individuel affiche d’abord l’URL demandée et présente une destination résolue avec son titre WordPress, son type de contenu localisé et son URL liée, sans créer de score. Pour une destination interne, Tester la destination de redirection lance un test confirmé séparément ; les destinations externes ne sont jamais testées. Un résultat terminé appartient à la destination, tandis que l’URL demandée reste visible comme provenance et sert pour Retester.
Filtres de résultats : combine le type de contenu, le type de page, le statut du contenu, l’état des problèmes, le score, l’ancienneté et la source du test. « Résultats orphelins » affiche les tests dont le contenu WordPress associé n’est plus publié, par exemple parce qu’il est dans la corbeille, enregistré comme brouillon ou supprimé définitivement. Ces lignes portent l’étiquette visible « Orphelin » et peuvent être supprimées individuellement ou ensemble. Les résultats reposant uniquement sur une URL, une archive ou une taxonomie avec post_id = 0 restent valides. L’avis et le filtre comptent les mêmes entrées dédupliquées, de sorte que les anciens tests du même contenu ne gonflent pas le nombre. « Sans problème » affiche uniquement les entrées dont les résultats ordinateur et mobile ne contiennent aucun problème. Les filtres actifs apparaissent sous forme d’étiquettes supprimables individuellement et restent actifs pendant la session du navigateur. Sur téléphone, le filtre combiné s’ouvre dans une feuille inférieure ; Appliquer valide le brouillon, tandis qu’Annuler, Fermer, Échap, l’arrière-plan ou un glissement vers le bas conserve les filtres appliqués.
Détails adaptatifs : sur téléphone, le résultat s’ouvre dans une feuille inférieure ciblée, alignée sur les bords gauche, droit et inférieur de la fenêtre, avec des coins arrondis uniquement en haut. L’en-tête et l’action de fermeture restent fixes. La poignée supérieure peut être tirée vers le bas avec le pouce pour fermer la feuille ; celle-ci descend tandis que l’assombrissement s’estompe et que la page reste visible. Sur les écrans plus larges, il reste intégré à la liste des résultats.
Score actuel et tableau de bord : seuls les résultats de contenus WordPress publiés et les résultats valides reposant uniquement sur une URL alimentent les métriques actuelles, Analytics, AI Insights et les rapports. Les contenus dans la corbeille, en brouillon ou supprimés n’influencent pas le score actuel. Leur historique d’exécution reste disponible pour la traçabilité et ne peut pas réintégrer le périmètre actuel lors d’une nouvelle agrégation.
Nettoyage : la suppression de résultats actuels ou orphelins retire également leurs problèmes, explications et résultats d’audit/WCAG enregistrés. Les enregistrements historiques restent intacts ; les autres viewports actuels ou résultats d’autres utilisateurs ne sont pas supprimés par erreur.
Sélecteur ordinateur/mobile : le score, la capture, le nombre de problèmes et les détails des vérifications concernent toujours uniquement la vue sélectionnée.
Groupes de vérifications : les vérifications échouées, manuelles, réussies et non applicables sont affichées avec leur nombre et peuvent être développées séparément. Pour les nouveaux résultats, les groupes manuels, réussis et non applicables contiennent aussi le nom et la description localisés de chaque vérification. Les vérifications non applicables expliquent pourquoi deux pages peuvent comporter un nombre différent de vérifications évaluées automatiquement.
Inspecteur d’accessibilité : l’action globale Ouvrir l’Inspecteur ouvre tous les éléments affectés sur la page testée ; l’icône en forme de chapeau et de lunettes ouvre le même Inspecteur sur le constat exact. Les commandes précédent, suivant et vue d’ensemble permettent de parcourir tous les éléments, tandis que plusieurs constats visant le même élément DOM restent sélectionnables. L’Inspecteur non modal distingue les correspondances visibles, les éléments masqués présents dans le DOM, les éléments structurels sans boîte propre, les sélecteurs absents et les sélecteurs ambigus. Il indique l’élément et son rôle, sa taille, la cause de visibilité et une estimation de l’arbre d’accessibilité. Sur ordinateur, l’Inspecteur est d’abord aligné sur les bords supérieur, droit et inférieur du viewport disponible et reste sous la barre d’administration WordPress lorsqu’elle est visible. Un bouton compact avec icône ouvre les choix d’ancrage à droite, à gauche, en haut ou en bas, tandis qu’un bouton séparé avec l’icône œil barré masque l’Inspecteur ; ce choix est enregistré uniquement dans le navigateur. Les panneaux latéraux ajoutent une navigation numérotée entre tous les éléments affectés, et les panneaux supérieur et inférieur placent côte à côte la navigation, le contexte et la correction. Les téléphones conservent le panneau inférieur fixe sans choix de position. Le masquage réduit le panneau à un bouton libellé sur le bord tout en conservant la cible, le surlignage et l’aperçu du navigateur ; ce bouton le restaure. Il n’existe aucune action de fermeture permanente et Échap laisse ouvert l’Inspecteur associé au résultat. Toutes les offres peuvent ouvrir AI Element Fix ou le générer dans leur quota. L’aperçu du navigateur est disponible uniquement pour les attributs de nom accessible autorisés, pour des couleurs de texte ou d’arrière-plan strictement limitées dans les constats de contraste et pour un soulignement permanent avec link-in-text-block. L’aperçu du lien peut contenir en plus exactement une couleur de texte hexadécimale à six chiffres ; la couleur seule n’est pas acceptée. Un aperçu de couleur montre les couleurs et les rapports de contraste avant et après, calcule le seuil applicable et indique par écrit si le résultat est conforme, non conforme ou non vérifiable de manière fiable. Les arrière-plans complexes restent des instructions manuelles. Lorsqu’aucun correctif sûr ne peut être dérivé, l’Inspecteur identifie explicitement la suggestion comme une instruction manuelle. Chaque aperçu est temporaire et est annulé lors de l’annulation ou de la navigation ; le masquage, la restauration et le changement d’ancrage le conservent. Aucun contenu ni style n’est enregistré. Aucun HTML, JavaScript ou CSS arbitraire produit par l’IA n’est appliqué. L’aide gratuite Explication et solution ne nécessite aucune requête IA. La réduction des mouvements désactive les animations et le défilement fluide.
Navigation et gravité dans l’Inspecteur : dans un panneau latéral, Vue d’ensemble est la première action du rail, au-dessus des éléments affectés numérotés. Le point coloré indiquant la gravité de chaque numéro est répété sous forme de texte localisé dans le nom accessible de l’action, l’entrée de la vue d’ensemble et le constat actif, afin que sa signification ne dépende jamais uniquement de la couleur.
Actions d’aperçu de l’Inspecteur : au départ, seule l’action Appliquer l’aperçu est disponible. Après une application réussie, elle est remplacée par Annuler l’aperçu sans réinitialiser la position de défilement de la zone de l’Inspecteur.
Présentation de l’Inspecteur : lorsqu’une zone doit défiler, le fonctionnement natif à la molette, au toucher et au clavier reste disponible, tandis qu’une barre de défilement fine en superposition est affichée. Lorsqu’il est ancré en haut ou en bas, le contexte de l’élément et la correction défilent indépendamment et chaque colonne affiche sa propre barre en cas de dépassement. Sur téléphone, la zone de poignée et l’en-tête forment une surface continue de la même couleur ; un geste volontaire vers le bas depuis la poignée ou une zone non interactive de l’en-tête masque l’Inspecteur sans terminer la session d’inspection. Pour les liens et autres éléments en ligne répartis sur plusieurs lignes, l’Inspecteur surligne chaque fragment visible séparément au lieu d’englober le texte sans rapport entre les fragments dans un grand rectangle. Si un élément sélectionné est masqué uniquement par une animation d’entrée reconnue, l’Inspecteur fait défiler précisément jusqu’à cet élément, attend son apparition pendant une durée limitée, puis l’évalue à nouveau. Il n’ouvre pas les menus, boîtes de dialogue, éléments details ou onglets volontairement fermés. Si un nœud cible créé paresseusement n’existe pas encore, l’Inspecteur fait d’abord défiler jusqu’à l’ancêtre existant le plus proche du sélecteur ; ce n’est qu’ensuite qu’un parcours de secours limité peut s’exécuter, s’arrêter dès qu’une correspondance apparaît et revenir à la position initiale en cas d’échec.
Quota AI Element Fix : dans l’Inspecteur, tous les utilisateurs voient le quota restant pour AI Element Fix ; les anciennes explications IA consommées restent comptées. Le compteur s’actualise automatiquement après une nouvelle génération et affiche explicitement ses états de chargement et d’erreur.
Métadonnées : l’URL testée, l’utilisateur ayant lancé le test et le type de déclenchement (par exemple Manuel, Batch ou Planifié) restent visibles de façon compacte. Sur les écrans étroits, les URL longues sont d’abord raccourcies et peuvent être déployées entièrement si nécessaire ; le bouton de lien séparé ouvre la page dans un nouvel onglet.

Gestion des redirections

Test individuel : l’affichage de l’avis de redirection ne consomme aucun quota de test. Une destination interne n’est testée qu’après confirmation explicite. Le serveur résout à nouveau la destination lors de cette action afin que le navigateur ne puisse pas injecter une destination modifiée ou externe.
Tests par lot, planifiés, après publication et après mise à jour : Tester automatiquement les destinations de redirection internes est désactivé par défaut dans les réglages du test d’accessibilité. Lorsqu’il est désactivé, les éléments redirigés sont signalés comme ignorés, sans score ni constat. Lorsqu’il est activé, seules les destinations du même domaine sont testées automatiquement.
Attribution : un test de destination terminé est enregistré uniquement pour l’URL de destination finale et son identité de contenu WordPress. L’URL source est une métadonnée, pas un second résultat.
Sécurité et doublons : les destinations externes ne sont jamais demandées après leur réponse de redirection. Les boucles, destinations invalides, en-têtes de destination absents, URL inaccessibles et chaînes de redirection excessives sont des erreurs. Si plusieurs URL sources mènent à la même destination dans un lot, cette destination n’est testée qu’une fois.

Exemples

Exemple 1 : référence à l’échelle du site

Lancez un lot sur les modèles clés, corrigez les problèmes récurrents prioritaires, puis retestez.

Exemple 2 : après publication

Activez les tests automatiques pour que les nouveaux articles obtiennent un score sans clic manuel.

Exemple 3 : suivi

Planifiez des lots mensuels et surveillez Analytics pour les régressions.

Exemple 4 : flux éditorial

Laissez les éditeurs lancer des tests unitaires sur leurs propres articles pendant que les lots restent réservés aux administrateurs.

Conseils

Réalité : les tests automatiques ne détectent pas tout problème WCAG — la QA manuelle et l’avis d’experts restent indispensables.
Utilisez l’historique pour suivre les progrès
Traitez d’abord les éléments critiques / graves
Si vous atteignez les limites d’URL, passez à un plan supérieur ou priorisez les modèles à fort trafic
Les exécutions en arrière-plan ne doivent pas bloquer la navigation normale
Combinez des contrôles ciblés (pages modifiées) avec des passages planifiés

Remarque : aucun outil automatisé ne prouve une conformité WCAG complète. Utilisez ceci dans le cadre d’un programme d’accessibilité plus large.

Disponible pour : rôles configurables (par défaut : administrateur) Free

Tests par lots : à partir de Basic

Tests planifiés : à partir de Basic

Consultez le guide pas à pas sur la carte de l’élément, l’arbre d’accessibilité et l’aperçu : Inspecteur d’accessibilité : utilisation et explication des indications.

Cookies et statistiques