Un site de commune ou d’établissement public ne peut pas se permettre d’attendre la stabilisation d’un outil pour respecter ses obligations d’accessibilité. C’est le constat de départ, sur ce test mené en marge d’un projet réel pour une collectivité, alors que l’éditeur de site n’existe encore que sous forme expérimentale dans le plugin Gutenberg, activable via son écran d’expérimentations.
L’idée n’est pas de livrer un site public sur cette base instable : aucune administration ne validerait un tel choix en 2020. Mais anticiper les points de vigilance dès maintenant, sur un environnement de test isolé, permet de préparer l’équipe au jour où cet éditeur deviendra une option crédible pour ce type de client. Voici les six points retenus après plusieurs sessions de test avec un lecteur d’écran.
1. Vérifier la hiérarchie de titres générée par les templates
Les tout premiers templates du Site Editor, construits à partir de blocs assemblés visuellement, ne garantissent aucune cohérence de hiérarchie de titres. Un pattern d’en-tête peut contenir un bloc Titre configuré en niveau 2, alors qu’un autre pattern, conçu séparément, réutilise également un niveau 2 pour le titre principal de la page. Résultat : deux titres de même niveau sur une même page, ce qui perturbe la navigation par lecteur d’écran.
Le contrôle consiste à parcourir chaque template généré et à vérifier, bloc par bloc, que la hiérarchie h1 à h6 reste logique, sans saut de niveau ni doublon au niveau principal.
2. Contrôler le focus clavier sur chaque bloc interactif
Le bloc Navigation, encore très jeune à cette date, gère mal certains cas de focus clavier : un menu déroulant testé au clavier reste parfois inaccessible sans la souris, faute de gestion correcte de la touche Échap ou des flèches directionnelles. Sur un site destiné au grand public, incluant potentiellement des usagers en situation de handicap moteur, ce point est bloquant.
- Naviguer entièrement au clavier, sans souris, sur chaque template généré par l’éditeur.
- Vérifier qu’un indicateur visuel de focus reste visible à chaque étape (bordure, contraste renforcé).
- Tester la fermeture d’un menu déroulant avec la touche Échap.
3. Tester le contraste des couleurs par défaut du thème
Les thèmes blocs de référence disponibles à cette période, pensés avant tout comme démonstrateurs techniques, n’ont pas toujours été audités pour le contraste. Un ratio de contraste insuffisant entre le texte et l’arrière-plan, sur un bouton ou un lien de navigation, doit être repéré tôt, avant que des dizaines de pages ne soient construites sur ce même gabarit visuel.
4. Vérifier le texte alternatif des images insérées via un pattern
Certains patterns pré-remplis, fournis comme exemples avec le thème bloc testé, contiennent des images de démonstration sans texte alternatif renseigné. Si l’équipe éditoriale copie ces patterns sans y penser, le défaut se propage sur tout le site. Un contrôle systématique, pattern par pattern, permet d’éviter ce piège avant qu’il ne devienne une habitude.
5. Documenter les limites connues du plugin à cette date
Certains comportements, à ce stade expérimental, ne sont tout simplement pas encore corrigés dans le plugin Gutenberg lui-même : par exemple, l’ordre de lecture au clavier de certains blocs imbriqués ne correspond pas toujours à l’ordre visuel affiché à l’écran. Plutôt que de chercher à corriger un bug qui appartient au cœur du projet, mieux vaut le documenter et suivre son évolution sur le suivi de tickets officiel du plugin.
Sur un projet public, on documente toujours les limites connues d’un outil expérimental, même quand elles ne sont pas corrigeables immédiatement : cela évite qu’un audit RGAA futur découvre le problème sans contexte.
6. Prévoir un audit complet une fois l’outil stabilisé
Cette liste ne remplace en rien un audit RGAA complet, qui suppose des tests bien plus larges, incluant la compatibilité avec plusieurs lecteurs d’écran et des critères réglementaires précis. Elle ne couvre pas non plus les fonctionnalités à venir du FSE, encore inconnues à cette date. Elle sert uniquement de grille de lecture rapide pour évaluer si l’éditeur de site mérite d’être suivi de près pour de futurs projets publics.
En résumé
Tester l’accessibilité d’un outil expérimental peut sembler prématuré, mais c’est précisément le bon moment pour remonter des signalements utiles à l’équipe du plugin Gutenberg, avant que des habitudes de conception inaccessibles ne se figent dans des milliers de patterns publiés. Sur un secteur aussi contraint que le public, mieux vaut arriver préparé le jour où l’éditeur de site deviendra une option sérieuse.
