Aller au contenu
tak.tn
← Retour au blog
3 min de lecture

Accessibilité web : ce que le RGAA demande vraiment à un développeur

#accessibilité#drupal

L’accessibilité web a longtemps été traitée comme une option morale. Ce n’est plus le cas : c’est désormais une obligation légale pour une part croissante du web francophone — et, accessoirement, un marqueur de qualité qui sépare les équipes sérieuses des autres. Je travaille au quotidien avec les standards W3C sur les back-offices de France Télévisions, où l’accessibilité est une exigence de service public. Voici ce que ça signifie concrètement pour un développeur Drupal.

Le cadre : RGAA, WCAG, EAA

  • WCAG (Web Content Accessibility Guidelines) : le standard international du W3C. Le niveau visé en pratique est AA. C’est le socle technique commun.
  • RGAA (Référentiel Général d’Amélioration de l’Accessibilité) : la déclinaison française, avec une méthode de contrôle précise (106 critères). Obligatoire pour le secteur public français et les grandes entreprises, avec déclaration d’accessibilité publique et schéma pluriannuel.
  • European Accessibility Act : depuis juin 2025, l’accessibilité s’impose aussi à de larges pans du secteur privé européen — e-commerce, banque, transport, médias numériques. Si votre produit vend en Europe, vous êtes probablement concerné.

Traduction pour les équipes : « on verra l’accessibilité à la fin » n’est plus un plan. C’est une dette qui se constate dans un audit, se déclare publiquement, et s’attaque en justice.

Ce qui relève du développeur (et pas du designer)

Une bonne partie des critères se joue dans le code que nous écrivons chaque jour :

  1. La sémantique d’abord. Des vrais <button>, des vrais <a>, des titres hiérarchisés (un seul h1, pas de saut de niveau), des landmarks (header, nav, main, footer). Un lecteur d’écran navigue par structure — une soupe de <div> cliquables est illisible.
  2. Les formulaires. Chaque champ a un <label> associé, les erreurs sont annoncées (pas seulement colorées en rouge), les groupes ont des fieldset/legend. Drupal fait bien les bases via la Form API — à condition de ne pas les détruire dans le thème.
  3. Le clavier. Tout ce qui se fait à la souris doit se faire au clavier : focus visible, ordre de tabulation logique, pas de piège de focus dans les modales. Testez votre site cinq minutes sans souris — c’est l’audit le moins cher du monde.
  4. ARIA en dernier recours. La première règle d’ARIA : ne pas utiliser ARIA quand le HTML natif suffit. Un aria-label incohérent est pire que rien.
  5. Les médias et contrastes. Textes alternatifs signifiants (et vides pour le décoratif), contrastes AA (4,5:1 pour le texte courant), pas d’information portée par la couleur seule.

Côté Drupal, spécifiquement

Drupal core est l’un des CMS les plus sérieux sur le sujet — le travail de l’initiative accessibilité se voit dans Claro, Olivero et la Form API. Les régressions viennent presque toujours de nous :

  • Le thème custom qui remplace des composants natifs par des <div> maison sans reprendre la sémantique.
  • Les composants JavaScript (carrousels, accordéons, autocomplétions) intégrés sans gestion du focus ni des annonces (aria-live, Drupal.announce() existe pour ça).
  • Le contenu éditorial : le meilleur thème du monde ne rattrape pas des images sans alternative et des « cliquez ici ». L’accessibilité se forme aussi côté contributeurs — les modules comme Editoria11y aident à vérifier au moment de la saisie.
  • Le back-office lui-même : vos éditeurs aussi ont droit à un outil accessible. C’est un critère de choix des modules d’administration que j’applique en tant que mainteneur.

Comment on teste, en pratique

Ma pile minimale : audit automatique (axe, Lighthouse) pour attraper ~30 % des problèmes, navigation clavier systématique, vérification des contrastes à la conception, et un passage lecteur d’écran (VoiceOver/NVDA) sur les parcours critiques. L’automatique ne suffit jamais — un formulaire peut passer axe et être inutilisable.

L’accessibilité n’est pas une couche de finition : c’est une exigence d’ingénierie, comme la sécurité ou la performance. Et comme elles, elle coûte dix fois moins cher quand elle est prise au départ.

Besoin d’un état des lieux RGAA/WCAG sur votre site Drupal, ou de former vos équipes ? Parlons-en.

Un projet Drupal ou un besoin SEO technique ?

Parlons-en. Réponse sous 24 h ouvrées, sans engagement.

Me contacter