WordPress 6.9, publié en décembre dernier, a fait entrer dans le cœur les Abilities API : un mécanisme qui permet à un plugin de déclarer des capacités structurées, avec une entrée et une sortie définies, appelables aussi bien par du code PHP classique que par des agents automatisés ou des intégrations MCP. Pour une équipe qui automatise déjà une partie de sa qualité, c’est une occasion naturelle d’y exposer un contrôle d’accessibilité.
Ce tutoriel montre comment déclarer une ability qui lance un contrôle d’accessibilité basique sur le contenu d’un article, directement depuis WordPress, sans dépendre d’un service externe.
Étape 1 — Comprendre ce qu’apporte une ability
Une ability se déclare avec un nom unique, une description destinée à être comprise par un agent appelant, un schéma d’entrée et un schéma de sortie, ainsi qu’une fonction de rappel qui exécute le traitement. C’est un contrat explicite, bien plus structuré qu’un simple hook ou qu’un endpoint REST improvisé.
Étape 2 — Déclarer l’ability de contrôle d’accessibilité
La déclaration se fait sur le hook dédié à l’enregistrement des abilities, avec wp_register_ability() :
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'wp-moderne/controle-accessibilite-article', array(
'label' => __( 'Contrôler l’accessibilité d’un article', 'wp-moderne' ),
'description' => __( 'Analyse le contenu d’un article et retourne une liste d’anomalies d’accessibilité détectables automatiquement.', 'wp-moderne' ),
'input_schema' => array(
'type' => 'object',
'properties' => array(
'post_id' => array( 'type' => 'integer' ),
),
'required' => array( 'post_id' ),
),
'output_schema' => array(
'type' => 'object',
'properties' => array(
'anomalies' => array( 'type' => 'array' ),
'score' => array( 'type' => 'integer' ),
),
),
'execute_callback' => 'wp_moderne_executer_controle_accessibilite',
'permission_callback' => function () {
return current_user_can( 'edit_posts' );
},
) );
} );
Étape 3 — Écrire la fonction de contrôle
La fonction appelée reprend des vérifications simples, déjà utilisées dans un script de recette maison : images sans texte alternatif, titres qui sautent un niveau, liens au texte non explicite comme « cliquez ici » :
function wp_moderne_executer_controle_accessibilite( $input ) {
$post = get_post( $input['post_id'] );
$anomalies = array();
if ( preg_match_all( '/<img(?![^>]*alt=)[^>]*>/i', $post->post_content, $matches ) ) {
$anomalies[] = sprintf( '%d image(s) sans attribut alt', count( $matches[0] ) );
}
if ( stripos( $post->post_content, '>cliquez ici<' ) !== false ) {
$anomalies[] = 'Lien avec un intitulé non explicite détecté (« cliquez ici »)';
}
$score = max( 0, 100 - ( count( $anomalies ) * 15 ) );
return array(
'anomalies' => $anomalies,
'score' => $score,
);
}
Étape 4 — Rendre l’ability appelable depuis un agent
Une fois déclarée, cette ability devient invocable par tout consommateur compatible, y compris un serveur MCP exposé côté WordPress : un agent de supervision peut demander un contrôle d’accessibilité avant de valider automatiquement la publication d’un article, ou pour flaguer un contenu à revoir avant sa mise en ligne planifiée.
Étape 5 — Ne pas se substituer à l’audit humain
Ce contrôle reste volontairement limité aux anomalies détectables par analyse de texte : il ne remplace ni un test clavier, ni une vérification de contraste réel, ni un test avec lecteur d’écran. Il sert de garde-fou automatisé de première ligne, pas de certification RGAA.
Limiter les faux positifs
Le score retourné doit être présenté comme un indicateur, jamais comme une note de conformité. Sur les projets où cette ability a été testée, un score parfait de 100 n’a jamais dispensé de l’audit manuel prévu avant mise en production, exactement comme un scanner d’accessibilité classique.
Une ability qui contrôle l’accessibilité doit rester honnête sur ses limites dans sa propre description : un agent qui l’invoque doit comprendre qu’il obtient un signal partiel, pas un verdict.
En résumé
Les Abilities API de WordPress 6.9 offrent un cadre propre pour exposer un contrôle d’accessibilité automatisé de premier niveau, appelable par un agent ou une tâche planifiée. C’est un complément utile à l’audit humain, à condition de ne jamais présenter son score comme une preuve de conformité RGAA.
