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

Blocs Gutenberg

Bloc pour collectivité : accessibilité RGAA d’un composant interactif

Une liste de contrôle concrète pour un bloc à onglets ou accordéon développé sur mesure pour un site public soumis au RGAA.

Par WordPress Développement • 26 juin 2022 • 4 min de lecture • Aucun commentaire
Bloc pour collectivité : accessibilité RGAA d'un composant interactif

« Le composant fonctionne à la souris » ne veut rien dire pour un site soumis au RGAA : un bloc à onglets développé pour un site de collectivité territoriale doit fonctionner intégralement au clavier, avec un lecteur d’écran, et sans piège de focus, sous peine de non-conformité sur un point souvent contrôlé en priorité lors d’un audit.

Cette liste de contrôle reprend, point par point, ce qui a été vérifié sur un bloc à onglets développé pour une mairie, avant sa mise en production sur un site public. Elle ne remplace pas un audit RGAA complet réalisé par un expert accessibilité, mais couvre les erreurs les plus fréquentes sur ce type de composant.

  1. Chaque onglet est atteignable au clavier via la touche Tab, dans un ordre logique correspondant à l’ordre visuel.
  2. Une fois un onglet actif, les touches flèche gauche et flèche droite permettent de naviguer entre les onglets sans repasser par Tab, conformément au pattern ARIA Tabs recommandé.
  3. La touche Entrée ou Espace active l’onglet sélectionné, sans dépendre exclusivement du survol ou du clic à la souris.
  4. Aucun piège de focus : il reste toujours possible de sortir du composant avec Tab, sans rester bloqué à l’intérieur.

Attributs ARIA cohérents

Le rôle tablist englobe les boutons d’onglets, chacun porteur du rôle tab, avec aria-selected qui reflète l’état réel, pas seulement une classe CSS visuelle :

<div role="tablist" aria-label="Sections de la page">
    <button role="tab" aria-selected="true" aria-controls="panneau-1" id="onglet-1">
        Horaires
    </button>
    <button role="tab" aria-selected="false" aria-controls="panneau-2" id="onglet-2" tabindex="-1">
        Contacts
    </button>
</div>
<div role="tabpanel" id="panneau-1" aria-labelledby="onglet-1">
    <p>Contenu de la section Horaires.</p>
</div>
L'essentiel à retenir : Navigation clavier complète, sans piège de focus ; Attributs ARIA cohérents avec le comportement réel ; Contraste et taille de cible vérifiés, pas seulement supposés

Points de contrôle visuels

  1. Le contraste entre le texte des onglets et leur fond respecte un ratio minimum de 4,5:1 pour le texte courant, vérifié avec un outil de mesure de contraste plutôt qu’à l’œil.
  2. L’onglet actif se distingue visuellement sans dépendre uniquement de la couleur (ajout d’un soulignement ou d’une bordure, pas seulement un changement de teinte).
  3. La zone cliquable de chaque onglet mesure au moins 44 pixels de hauteur sur mobile, pour rester utilisable au doigt sans viser un élément trop petit.
  4. Le focus visible (contour ou surlignage) reste apparent sur chaque onglet lors de la navigation au clavier, jamais supprimé par un outline: none non compensé.

Points de contrôle techniques complémentaires

  1. Le contenu du panneau actif reste présent dans le DOM même quand un panneau est masqué visuellement, sauf à utiliser hidden correctement pour les panneaux inactifs.
  2. Aucune information n’est transmise uniquement par une icône sans texte alternatif ou libellé associé.
  3. Le bloc reste utilisable si JavaScript échoue à se charger : à défaut d’une dégradation élégante complète, un message clair informe l’utilisateur plutôt qu’un composant totalement silencieux.
  4. Le titre de chaque section reste un véritable titre HTML (h3 par exemple) à l’intérieur du panneau, pas seulement un texte stylé visuellement comme un titre.
  5. Un test réalisé avec un lecteur d’écran (NVDA ou VoiceOver) confirme que l’annonce vocale correspond bien au comportement attendu, pas seulement une lecture théorique du code ARIA.

Ce que cette liste ne remplace pas

Un audit RGAA complet couvre 106 critères répartis sur treize thématiques, bien au-delà d’un seul composant interactif : structure des titres du site entier, formulaires, multimédia, tableaux de données, et bien d’autres aspects qui dépassent largement ce bloc précis. Les obligations légales détaillées, qui varient selon le type d’organisme et son schéma pluriannuel d’accessibilité, relèvent d’un accompagnement juridique et non d’une checklist technique.

En résumé

Un composant interactif accessible ne s’improvise pas après coup : chacun des treize points ci-dessus a été vérifié avant la mise en production, pas ajouté en correction suite à un signalement. Pour un site de collectivité, cette rigueur en amont évite des reprises coûteuses une fois le composant déjà généralisé sur plusieurs pages.

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