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

Accessibilité

Accessibilité d’un site média WordPress à la production éditoriale quotidienne

Sur un site d'actualité où des dizaines de rédacteurs publient chaque jour sans relecture technique systématique, seuls des contrôles automatisés à la publication tiennent la charge sur la durée.

Par WordPress Développement • 28 octobre 2023 • 4 min de lecture • Aucun commentaire
Accessibilité d'un site média WordPress à la production éditoriale quotidienne

Combien d’articles un rédacteur relit-il réellement pour leur accessibilité avant de cliquer sur « Publier », un jour de forte actualité où le rythme de production atteint plusieurs dizaines de contenus ? Sur un site média, la réponse honnête est généralement « aucun », faute de temps, de formation ou simplement de rappel au bon moment.

Ce texte ne traite pas de la formation éditoriale des rédacteurs, sujet en soi, mais des contrôles automatisables directement au moment de la publication, seule échelle de temps compatible avec un rythme de production quotidien aussi soutenu.

Pourquoi la relecture manuelle systématique échoue à cette échelle

Une checklist d’accessibilité de quinze points, aussi pertinente soit-elle en théorie, ne survit pas à un rythme de quarante publications quotidiennes réparties entre une dizaine de rédacteurs aux compétences techniques inégales. La seule solution durable consiste à déplacer le contrôle vers l’outil de publication lui-même, plutôt que de compter sur la discipline individuelle de chacun.

Bloquer uniquement ce qui compte vraiment à la publication

Un contrôle trop strict, qui empêche la publication pour des raisons mineures, pousse rapidement les rédacteurs à chercher des contournements ou à désactiver le contrôle. Concentrez le blocage sur deux ou trois défauts vraiment critiques et faciles à corriger sans compétence technique : une image sans alternative textuelle, un lien au texte non explicite du type « cliquez ici », un titre d’article manquant dans le corps du texte.

add_action( 'save_post', function ( $post_id, $post ) {
    if ( 'publish' !== $post->post_status ) {
        return;
    }
    if ( a11y_contient_image_sans_alt( $post->post_content ) ) {
        wp_die( 'Publication bloquée : au moins une image sans texte alternatif.' );
    }
}, 10, 2 );

Afficher l’alerte au bon endroit, dans l’éditeur

L'essentiel à retenir : Vérifier au moment de la publication, pas après coup ; Bloquer uniquement les défauts les plus graves et les plus fréquents ; Afficher l'alerte dans l'éditeur, pas dans un rapport séparé

Un rapport d’accessibilité généré une fois par semaine, consultable dans un tableau de bord séparé, n’atteint jamais les rédacteurs pressés par le rythme quotidien. L’alerte doit apparaître directement dans l’éditeur de blocs, au moment de la rédaction, sous forme d’une notice dans la barre latérale qui signale le défaut avant même la tentative de publication.

wp.data.subscribe( () => {
    const blocs = wp.data.select( 'core/block-editor' ).getBlocks();
    const imagesSansAlt = blocs.filter(
        b => b.name === 'core/image' && !b.attributes.alt
    );
    if ( imagesSansAlt.length > 0 ) {
        // Afficher une notice dans la barre latérale de l'éditeur
    }
} );

Cette approche transforme le contrôle d’accessibilité en un compagnon de rédaction plutôt qu’en un obstacle administratif découvert après coup, ce qui augmente considérablement le taux de correction spontanée par les rédacteurs eux-mêmes.

Traiter les cas particuliers : brèves, dépêches d’agence, contenus embarqués

Un site média republie souvent des dépêches d’agence ou des contenus embarqués (tweets, vidéos) dont la structure échappe partiellement au contrôle éditorial habituel. Prévoyez une liste d’exceptions documentée pour ces formats particuliers, plutôt que de bloquer systématiquement leur publication ou, à l’inverse, de désactiver le contrôle pour l’ensemble du site par facilité.

  • Un contrôle bloquant limité à deux ou trois défauts critiques et simples à corriger
  • Une alerte affichée dans l’éditeur, jamais dans un rapport séparé consulté à part
  • Une liste d’exceptions documentée pour les formats de contenu particuliers

Mesurer l’effet réel du dispositif dans le temps

Suivez le taux de défauts détectés à la publication sur plusieurs mois : une baisse continue indique que les rédacteurs intègrent progressivement les bons réflexes, tandis qu’un taux stable suggère que le message d’alerte reste mal compris ou mal placé, et qu’il faut retravailler sa formulation avant d’ajouter de nouveaux contrôles.

Un contrôle d’accessibilité qui interrompt la publication d’un rédacteur pressé sans lui expliquer quoi corriger précisément finit toujours par être contourné, jamais respecté.

Étendre progressivement le périmètre des contrôles

Une fois les premiers contrôles bien intégrés dans les habitudes de la rédaction, élargissez progressivement la liste des défauts vérifiés : structure de titres cohérente, tableaux de données correctement balisés, vidéos embarquées avec transcription associée. Chaque ajout doit rester compréhensible sans jargon technique par un rédacteur non spécialiste.

En résumé

Sur un site média à production quotidienne intense, seul un contrôle automatisé intégré directement dans l’éditeur, limité aux défauts vraiment critiques, tient la charge dans la durée, là où toute checklist reposant sur la discipline individuelle des rédacteurs finit par disparaître sous la pression du rythme de publication.

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