Le WordPress d'aujourd'hui, décodé pour les développeurs

Accessibilité

Rendre accessible un site associatif WordPress géré par des bénévoles

Livrer un site accessible ne suffit pas si les bénévoles qui le maintiennent ensuite cassent tout au premier article publié. Voici les garde-fous à poser.

Par WordPress Développement • 30 septembre 2026 • 7 min de lecture • Aucun commentaire
Rendre accessible un site associatif WordPress géré par des bénévoles

Trois mois après la livraison, le site d’une association de quartier affichait des titres en gras plutôt qu’en <h2>, des images sans texte alternatif et un lien « cliquez ici » répété douze fois sur la page d’accueil. Rien de tout cela n’existait à la mise en ligne : ce sont les bénévoles, sans formation technique, qui avaient progressivement dégradé l’accessibilité en publiant du contenu au fil de l’eau, chacun avec ses propres habitudes.

Ce scénario est extrêmement fréquent sur les sites associatifs, où la maintenance passe de main en main sans continuité ni compétence technique dédiée. La solution ne peut pas reposer sur la bonne volonté ou la mémoire des bénévoles : elle doit être posée dans le thème lui-même, de façon à rendre les mauvaises pratiques plus difficiles que les bonnes.

Identifier les points de rupture les plus probables

Avant de coder quoi que ce soit, il faut lister les gestes de publication qui cassent le plus souvent l’accessibilité sur ce type de site : mise en gras d’un texte à la place d’un vrai titre, image collée depuis un téléphone sans description, lien générique sans contexte, tableau de données construit avec des espaces plutôt qu’une vraie structure. Ce sont ces gestes, pas des bugs de thème, qui expliquent l’essentiel des régressions.

Poser des garde-fous dans le thème

L'essentiel à retenir : Verrouiller les choix qui cassent l'accessibilité dans le thème ; Guider la saisie plutôt que faire confiance à la mémoire ; Prévoir des contrôles automatiques discrets

Le premier garde-fou consiste à bloquer la publication d’une image sans texte alternatif dans le contenu principal, via un filtre côté serveur plutôt qu’une simple consigne orale :

add_filter( 'rest_pre_insert_post', 'assoc_refuser_image_sans_alt', 10, 2 );

function assoc_refuser_image_sans_alt( $article, $requete ) {
    $statut = isset( $requete['status'] )
        ? $requete['status']
        : ( ! empty( $article->ID ) ? get_post_status( $article->ID ) : '' );

    if ( ! in_array( $statut, array( 'publish', 'future' ), true ) || ! isset( $article->post_content ) ) {
        return $article;
    }

    if ( preg_match_all( '/<img\b[^>]*>/i', $article->post_content, $balises ) ) {
        foreach ( $balises[0] as $balise ) {
            if ( ! preg_match( '/\balt="[^"]+"/i', $balise ) ) {
                return new WP_Error(
                    'assoc_alt_manquant',
                    'Publication refusée : une image n\'a pas de texte alternatif. Sélectionnez l\'image et décrivez-la dans le panneau de droite.',
                    array( 'status' => 400 )
                );
            }
        }
    }

    return $article;
}

Le filtre dynamique rest_pre_insert_post s’applique à l’enregistrement d’un article par l’éditeur de blocs, qui passe par la REST API. Le bénévole voit apparaître le message d’erreur en haut de l’éditeur au moment de publier, avec la marche à suivre : c’est une consigne donnée au bon moment, à l’endroit où l’on agit. Ce garde-fou n’est pas sans limite : une image purement décorative doit avoir un attribut alt vide, ce que ce code refuse. Il faut donc en parler avec l’association et, si le cas se présente souvent, prévoir une classe CSS ou un motif de blocs dédié aux illustrations décoratives, que le filtre laissera passer.

Restreindre les choix plutôt que les interdire après coup

Le deuxième garde-fou agit en amont : retirer de l’éditeur ce qui permet de mal faire. Un thème enfant peut verrouiller la palette de couleurs sur des teintes dont le contraste a été vérifié, supprimer la saisie de couleurs libres et limiter les blocs proposés :

add_action( 'after_setup_theme', 'assoc_limiter_editeur' );

function assoc_limiter_editeur() {
    add_theme_support( 'disable-custom-colors' );
    add_theme_support( 'disable-custom-font-sizes' );
    add_theme_support( 'editor-color-palette', array(
        array( 'name' => 'Bleu nuit', 'slug' => 'bleu-nuit', 'color' => '#14304f' ),
        array( 'name' => 'Blanc',     'slug' => 'blanc',     'color' => '#ffffff' ),
        array( 'name' => 'Jaune',     'slug' => 'jaune',     'color' => '#ffd54a' ),
    ) );
}

add_filter( 'allowed_block_types', 'assoc_blocs_autorises', 10, 2 );

function assoc_blocs_autorises( $blocs, $article ) {
    return array(
        'core/paragraph',
        'core/heading',
        'core/list',
        'core/image',
        'core/quote',
        'core/table',
        'core/buttons',
    );
}

Avec cette palette, un bénévole ne peut plus poser du texte jaune sur un fond blanc. Quant aux blocs autorisés, la liste courte réduit la surface d’erreur : pas de bloc HTML personnalisé, pas de bloc de colonnes imbriquées que personne ne sait relire avec un lecteur d’écran.

Guider la saisie avec des motifs prêts à l’emploi

Troisième levier : donner aux bénévoles des modèles de contenu déjà corrects. Depuis WordPress 5.5, la fonction register_block_pattern() permet de proposer un motif « Annonce d’événement » dont la structure (un titre de niveau 2, une liste des informations pratiques, un bouton dont le libellé est explicite) est juste dès l’insertion :

add_action( 'init', 'assoc_motifs' );

function assoc_motifs() {
    register_block_pattern( 'assoc/annonce-evenement', array(
        'title'      => 'Annonce d\'événement',
        'categories' => array( 'text' ),
        'content'    => '<!-- wp:heading -->
<h2>Titre de l\'événement</h2>
<!-- /wp:heading -->

<!-- wp:list -->
<ul><li>Date et heure :</li><li>Lieu :</li><li>Tarif :</li></ul>
<!-- /wp:list -->

<!-- wp:buttons -->
<div class="wp-block-buttons"><!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link">S\'inscrire à l\'événement</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->',
    ) );
}

Le bénévole n’a plus qu’à remplacer les textes. Le motif porte à sa place les bonnes pratiques : hiérarchie de titres respectée, liste plutôt que tableau d’espaces, lien explicite plutôt que « cliquez ici ».

Des contrôles automatiques discrets

Aucun garde-fou ne remplace un contrôle régulier. L’idéal est un contrôle automatique mensuel, exécuté sans intervention des bénévoles, qui signale les régressions à une seule personne référente. Un outil en ligne de commande comme Pa11y CI se configure avec un fichier JSON listant les pages clés :

{
    "defaults": {
        "standard": "WCAG2AA",
        "timeout": 30000
    },
    "urls": [
        "https://association-exemple.fr/",
        "https://association-exemple.fr/agenda/",
        "https://association-exemple.fr/contact/"
    ]
}

Planifié via une tâche cron du serveur, dont la sortie est adressée par courriel au référent, il signale les régressions sans que personne d’autre n’ait à s’en occuper. Rappelons qu’un contrôle automatique ne détecte qu’une partie des défauts d’accessibilité : il repère l’image sans alternative ou le contraste insuffisant, mais pas le libellé de lien ambigu ni l’ordre de lecture illogique. Il complète la relecture humaine, il ne la remplace pas.

Un site accessible le jour de la livraison est une photographie ; un site qui le reste un an après est un système.

Transmettre sans former tout le monde

Le dernier garde-fou est humain, et il doit rester léger. Une page d’une seule feuille, rangée dans l’espace d’administration, suffit : trois gestes à faire systématiquement (décrire chaque image, utiliser les titres proposés, écrire des liens compréhensibles hors contexte) et le nom du référent à prévenir en cas de doute. Les bénévoles changent, la feuille reste, et le thème applique le reste.

Conclusion

Sur un site associatif, l’accessibilité ne se décrète pas à la livraison : elle se protège. En verrouillant les choix risqués dans le thème, en guidant la saisie par des motifs corrects et en ajoutant un contrôle automatique discret, on rend la bonne pratique plus simple que la mauvaise. Les bénévoles gardent la liberté de publier, et le site garde son niveau d’accessibilité.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi