# WordPress 6.9 et les Abilities API : un contrôle d’accessibilité pour un agent

> Comment déclarer une capacité d'audit d'accessibilité encadrée grâce aux Abilities API de WordPress 6.9, pour qu'un agent IA vérifie un contenu avant publication.

- Auteur : Clément Hadrot
- Publié le : 2026-03-03
- Mis à jour le : 2026-03-03
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/wordpress-69-abilities-api-controle-accessibilite-agent/

## L’essentiel

- Déclarer une capacité d'audit plutôt que laisser l'agent improviser
- Limiter le périmètre : contraste, alt, structure de titres
- L'agent propose, un humain valide avant publication

« Une ability expose une action discrète, typée, que l'agent peut découvrir et invoquer sans connaître à l'avance votre code. » C'est à peu de choses près ce que dit la documentation des Abilities API introduites dans WordPress 6.9, sortie en décembre 2025. Traduit en langage de développeur : plutôt que de laisser un agent conversationnel deviner comment vérifier un contenu, on lui déclare une fonction précise, avec des entrées et des sorties documentées.

Pour l'accessibilité, cette approche change la donne. Jusqu'ici, brancher un agent IA sur un contrôle avant publication supposait soit un prompt système fragile, soit un plugin tiers fermé. Avec une ability déclarée dans le thème ou l'extension, le contrôle devient une fonction PHP ordinaire, testable, versionnée, et surtout limitée à ce qu'on a explicitement autorisé.

## Ce que change l'Abilities API pour l'accessibilité

Une ability se déclare avec `wp_register_ability()`, un identifiant, un schéma d'entrée et un callback. L'agent qui orchestre la publication d'un article peut alors « voir » qu'une capacité `a11y-audit-content` existe, l'invoquer avec le contenu du bloc en cours d'édition, et recevoir une réponse structurée plutôt qu'un texte libre à interpréter.

Le point important : l'ability ne fait que ce qu'on lui a écrit de faire. Elle n'a pas d'accès direct à la base au-delà de ce que le callback expose, et elle ne modifie rien sans qu'un second appel explicite le demande. On garde donc la main sur le périmètre exact du contrôle, contrairement à un agent à qui on donnerait un accès large à l'admin.

> L'essentiel à retenir : Déclarer une capacité d'audit plutôt que laisser l'agent improviser ; Limiter le périmètre : contraste, alt, structure de titres ; L'agent propose, un humain valide avant publication

## Déclarer une capacité d'audit encadrée

Voici une déclaration minimale, limitée à quatre vérifications simples sur le HTML d'un article avant sa publication : présence d'un texte alternatif sur les images, hiérarchie des titres, longueur des liens « cliquez ici », et contraste basique sur les couleurs inline déclarées dans les blocs.

```
add_action( 'abilities_api_init', function () {
    wp_register_ability( 'wpmoderne/a11y-audit-content', array(
        'label'               => __( 'Audit accessibilité avant publication', 'wpmoderne' ),
        'description'         => __( 'Vérifie alt, hiérarchie de titres et liens vagues.', 'wpmoderne' ),
        'input_schema'        => array(
            'type'       => 'object',
            'properties' => array(
                'post_id' => array( 'type' => 'integer' ),
            ),
            'required'   => array( 'post_id' ),
        ),
        'execute_callback'    => 'wpmoderne_run_a11y_audit',
        'permission_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
    ) );
} );
```

Le callback `wpmoderne_run_a11y_audit()` reste un simple parcours du contenu avec `DOMDocument` : on ne réinvente pas un moteur de règles RGAA complet, on couvre les erreurs les plus fréquentes qu'on retrouve d'un projet à l'autre.

## Ce que l'agent peut réellement vérifier

Sur nos chantiers, une déclaration d'ability raisonnable couvre :

- La présence d'un attribut `alt` sur chaque `<img>` du contenu, vide ou renseigné selon le contexte
- L'absence de saut de niveau de titre (un `<h4>` qui suit un `<h2>` sans `<h3>` intermédiaire)
- Les intitulés de lien génériques comme « cliquez ici » ou « en savoir plus » sans contexte
- Les tableaux de données sans `<th>` ni portée déclarée

Ce qui reste hors de portée d'un tel contrôle automatisé : la pertinence réelle d'un texte alternatif, la cohérence d'un parcours clavier complet, ou l'ordre de lecture logique d'une mise en page complexe. L'ability signale, elle ne remplace pas un audit manuel.

## L'agent propose, il ne publie pas seul

Le point de vigilance le plus important concerne le `permission_callback`. Il doit vérifier les capacités de l'utilisateur au nom duquel l'agent agit, jamais s'appuyer sur une clé d'API générique qui contournerait les rôles WordPress. Sur un projet client récent, l'ability retournait une liste d'anomalies dans un tableau structuré (type, sévérité, sélecteur concerné), affichée dans l'éditeur avant l'appel à `wp_publish_post()` ; l'agent ne bloquait jamais la publication lui-même, il se contentait d'alerter l'auteur.

Cette séparation entre détection et décision est, à notre avis, la seule façon responsable d'introduire un contrôle automatisé dans un flux éditorial : l'ability fait remonter l'information, un humain garde la responsabilité de publier ou de corriger.

## Notre verdict

Les Abilities API rendent enfin propre ce qu'on bricolait auparavant avec des hooks `save_post` et des appels REST maison vers un service d'IA externe. Le gain principal n'est pas la détection elle-même, qui reste modeste, mais la traçabilité : on sait exactement quelle fonction a été appelée, avec quelles permissions, et ce qu'elle a retourné. Pour un début 2026, c'est un socle solide sur lequel construire un contrôle d'accessibilité plus ambitieux, sans jamais perdre la main sur ce que l'agent est autorisé à faire.