rgaa

RGAA : pourquoi l'accessibilité est devenue un enjeu majeur pour les applications d'entreprise

CARBON-IT (Admin)

— 10 min de lecture
Partager
RGAA : pourquoi l'accessibilité est devenue un enjeu majeur pour les applications d'entreprise

Auteur : Etienne PERIANAYAGASSAMY

En tant que développeurs et tech leads, nous avons souvent la tête dans le guidon. Entre la livraison des nouvelles fonctionnalités, l'optimisation de nos pipelines d'intégration continue et la gestion de la dette technique, certains sujets ont tendance à glisser inexorablement vers le bas du backlog. L'accessibilité numérique (a11y) en fait trop souvent partie.

Pourtant, dans le contexte des applications d'entreprise, concevoir des interfaces accessibles n'est plus un « nice-to-have » que l'on garde pour une hypothétique V2. C'est une nécessité légale, éthique et technique. Aujourd'hui, nous allons parler du RGAA (Référentiel Général d'Amélioration de l'Accessibilité) et de la raison pour laquelle la maîtrise de ces standards doit faire partie du bagage fondamental de tout bon développeur front-end.

Qu'est ce que le RGAA ?

Pour faire simple, le RGAA est la déclinaison française des normes internationales d'accessibilité (les fameuses WCAG - Web Content Accessibility Guidelines). Il fournit un cadre technique et méthodologique précis pour vérifier qu'un service numérique est utilisable par tous, y compris par les personnes en situation de handicap (visuel, auditif, moteur ou cognitif).

Plutôt que de vagues recommandations, le RGAA propose des critères testables. Il ne s'agit pas de rendre une application « parfaite » du jour au lendemain, mais de s'inscrire dans une démarche mesurable et continue d'amélioration.

RGAA ou WCAG : que faut-il apprendre ?

La question revient souvent. En pratique, le RGAA (dans sa version 4) s'appuie directement sur les WCAG 2.1, niveau AA : il n'invente pas de critères techniques, il fournit une méthodologie de contrôle et un cadre réglementaire français pour les vérifier. Concrètement, un développeur qui maîtrise les principes des WCAG retrouvera la quasi-totalité des concepts dans le RGAA. La différence se situe surtout au niveau de la méthode d'audit et de l'obligation légale. Autrement dit : apprendre les WCAG, c'est déjà faire l'essentiel du chemin.

Pourquoi c'est aujourd'hui un impératif en entreprise ?

Le cadre légal se durcit

Ignorer l'accessibilité représente un risque juridique et financier majeur. En France, la législation impose le respect du RGAA non seulement au secteur public, mais aussi aux grandes entreprises privées (dont le chiffre d'affaires dépasse 250 millions d'euros). En cas de manquement constaté, les organismes concernés s'exposent à une sanction administrative pouvant atteindre 50 000 € par service numérique, renouvelable tous les six mois si la non-conformité persiste, sans parler du risque d'image.

Surtout, le cadre vient de se durcir nettement : l'European Accessibility Act (EAA), transposé en droit français, est applicable depuis le 28 juin 2025. Il étend l'obligation d'accessibilité à de nombreux acteurs privés du B2C (e-commerce, banque, transport, télécommunications…), indépendamment du seuil des 250 millions d'euros. Autrement dit, l'accessibilité n'est plus l'apanage du secteur public. Sur des projets d'envergure, nos clients exigent d'ailleurs désormais cette conformité.

L'opportunité marché et l'inclusion

Statistiquement, près de 20 % de la population vit avec une forme de handicap (source : INSEE, en retenant une définition large du handicap, qu'il soit permanent ou temporaire). Penser qu'une application d'entreprise (comme un outil de gestion interne, un portail B2B ou un service public) peut se priver d'un cinquième de ses utilisateurs est une aberration opérationnelle. Concevoir accessible, c'est s'assurer que l'outil de travail ne devient pas lui-même un facteur d'exclusion professionnelle.

Et il faut sortir du cliché qui réduit l'accessibilité aux personnes aveugles. Les situations concernées sont bien plus larges : un utilisateur souffrant d'un trouble moteur qui navigue uniquement au clavier, une personne malvoyante qui pousse fortement le zoom de son navigateur, ou encore un collègue qui a temporairement un bras immobilisé. Une interface accessible sert tous ces usages d'un même geste.

Le coût : mieux vaut prévenir que corriger

Au-delà du risque, il y a une logique de pur retour sur investissement. C'est le principe du « shift-left » : plus un défaut d'accessibilité est détecté tard, plus il coûte cher à corriger. Bien utiliser un <button> dès la phase de développement ne coûte rien ; reprendre des dizaines de composants après un audit de conformité, en fin de cycle, mobilise des jours de travail, des refontes et parfois des arbitrages produit. Investir tôt dans la formation et l'outillage de la CI revient bien moins cher que de payer la dette d'accessibilité plus tard.

Un retour aux fondamentaux techniques

Construire une application accessible nous oblige à revoir nos fondamentaux. C'est l'occasion de se détacher de la surutilisation des frameworks utilitaires pour revenir à ce qui fait le cœur de notre métier :

  • Le HTML sémantique : Utiliser un <button> plutôt qu'une <div> avec un événement (click) n'est pas qu'un détail, cela change tout pour un lecteur d'écran.
  • Le CSS natif : Penser le contraste, le focus visible et le design responsive dès la conception.
  • L'architecture de l'information : Structurer logiquement ses titres (<h1>, <h2>…) pour faciliter la navigation clavier.

Comment intégrer le RGAA dans un écosystème Angular ?

Si vous travaillez avec Angular, le framework offre d'excellents outils pour vous accompagner dans cette démarche. Voici par où commencer.

Revenir au HTML sémantique

Avant tout outil, le réflexe de base : utiliser le bon élément. Un <div> cliquable n'est ni focusable au clavier, ni annoncé comme un bouton par un lecteur d'écran.

<!-- À éviter : invisible pour le clavier et les lecteurs d'écran -->
<div (click)="valider()">Valider</div>

<!-- À privilégier : focusable, activable au clavier, sémantique native -->
<button type="button" (click)="valider()">Valider</button>

Le package Angular CDK (Component Dev Kit) — a11y

Ce module est une mine d'or. Il propose des utilitaires comme le LiveAnnouncer (pour dicter dynamiquement des messages aux lecteurs d'écran), le FocusTrap (essentiel pour garder le focus dans une modale) et un gestionnaire de focus clavier (FocusMonitor).

import { LiveAnnouncer } from '@angular/cdk/a11y';

@Component({ /* ... */ })
export class PanierComponent {
    private announcer = inject(LiveAnnouncer);

    ajouterAuPanier(): void {
        // ...logique métier...
        this.announcer.announce('Article ajouté au panier', 'polite');
    }
}

Et pour piéger le focus dans une modale, il suffit d'une directive sur le conteneur :

<div class="modale" cdkTrapFocus cdkTrapFocusAutoCapture>
    <!-- contenu de la modale -->
</div>

Gérer le focus au changement de route

C'est le piège n°1 des SPA Angular : par défaut, une navigation ne déplace pas le focus et n'annonce pas le changement de page. L'utilisateur au lecteur d'écran reste « perdu » sur l'ancien contexte. À chaque navigation, déplacez le focus sur le titre principal et/ou annoncez la nouvelle page.

Attention : un <h1> n'est pas focusable par défaut. Pour que .focus() ait un effet, il doit porter un tabindex="-1" (focusable par script, mais hors de l'ordre de tabulation naturel).

<h1 #mainTitle tabindex="-1">Titre de la page</h1>

À ne pas généraliser pour autant : le tabindex="-1" sert ici uniquement à autoriser un déplacement programmatique du focus après une navigation. Il ne doit pas être ajouté systématiquement à tous les titres de l'application, au risque de polluer la sémantique et l'ordre de tabulation.

Quelques cas particuliers à garder en tête :

  • Listes déroulantes (<select>) : nativement focusables, elles n'ont besoin d'aucun attribut tabindex. L'essentiel est de les associer à un <label> via for/id ou de les imbriquer dedans.
  • Champs disabled : l'attribut disabled retire l'élément de l'ordre de tabulation et le rend invisible aux lecteurs d'écran. Si l'information doit rester perceptible (ex. : un montant calculé non éditable), préférez readonly ou aria-disabled="true" combiné à une logique de prévention de la saisie — le champ reste alors annoncé par les technologies d'assistance.
  • Tableaux : un tableau de données volumineux avec défilement horizontal doit recevoir tabindex="0" pour être scrollable au clavier. Pensez également à la structure sémantique (<caption>, scope sur les <th>) pour que les lecteurs d'écran puissent en restituer le contenu cellule par cellule.
import { Component, OnInit, ViewChild, ElementRef, inject, DestroyRef } from '@angular/core';
import { Router, NavigationEnd } from '@angular/router';
import { Title } from '@angular/platform-browser';
import { filter } from 'rxjs';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { LiveAnnouncer } from '@angular/cdk/a11y';

@Component({ /* ... */ })
export class AppComponent implements OnInit {
  @ViewChild('mainTitle') mainTitle!: ElementRef<HTMLHeadingElement>;

  private destroyRef = inject(DestroyRef);
  private announcer = inject(LiveAnnouncer);
  private titleService = inject(Title);
  private router = inject(Router);

  ngOnInit(): void {
    this.router.events
      .pipe(
        filter((e) => e instanceof NavigationEnd),
        takeUntilDestroyed(this.destroyRef),
      )
      .subscribe(() => {
        this.announcer.announce(`Navigation vers ${this.titleService.getTitle()}`);
        this.mainTitle.nativeElement.focus();
      });
  }
}

takeUntilDestroyed se charge du désabonnement automatique à la destruction du composant — sans quoi l'abonnement resterait actif et provoquerait une fuite mémoire silencieuse.

La règle d'or d'ARIA

Les attributs ARIA (Accessible Rich Internet Applications) permettent d'enrichir la sémantique quand le HTML natif ne suffit pas. Mais attention, la première règle d'ARIA est : ne pas utiliser ARIA si un élément HTML natif peut faire le travail. Un mauvais ARIA est souvent pire que pas d'ARIA du tout.

<!-- ❌ ARIA superflu : un <div> bricolé en bouton (Enter ET Space à gérer manuellement…) -->
<div role="button" tabindex="0" aria-label="Supprimer"
     (click)="delete()"
     (keydown.enter)="delete()"
     (keydown.space)="delete()">
  Supprimer
</div>

<!-- ✅ HTML natif : focus, clavier et sémantique inclus d'office -->
<button type="button" (click)="delete()">Supprimer</button>

En revanche, ARIA devient indispensable pour des composants qui n'ont pas d'équivalent natif, comme une modale, un accordéon ou un combobox personnalisé. Dans ces cas, des attributs tels que role="dialog", aria-expanded ou aria-haspopup comblent ce que le HTML seul ne peut pas exprimer.

Détecter au plus tôt : ESLint et CI

Tout comme nous testons notre logique métier avec Jest ou Vitest, l'accessibilité doit être outillée à plusieurs niveaux :

  • Dans l'éditeur : activez les règles d'accessibilité de @angular-eslint sur vos templates (@angular-eslint/template/alt-text, @angular-eslint/template/label-has-associated-control, @angular-eslint/template/click-events-have-key-events…). Les erreurs remontent dès l'écriture du code.
  • Dans la CI : intégrez des outils comme axe-core (via jest-axe, cypress-axe ou @axe-core/playwright) ou pa11y dans vos pipelines pour bloquer les régressions flagrantes (absence de labels, contrastes insuffisants) avant même la revue de code.

Une mise en garde s'impose toutefois : les tests automatisés ne détectent qu'environ 30 % des problèmes d'accessibilité. Une CI verte ne signifie donc pas qu'une application est accessible — c'est le syndrome de la « pastille verte ». L'outillage ne dispense pas des tests manuels : navigation au clavier, vérification avec un lecteur d'écran (NVDA, VoiceOver, JAWS) et, idéalement, retours d'utilisateurs en situation de handicap.

Passer à l'échelle avec le Design System

Dans une grande organisation, le levier le plus puissant n'est pas le composant isolé, mais le Design System. Un Button, une Modal ou un Tooltip conçus, audités et testés une seule fois diffusent les bonnes pratiques d'accessibilité à toutes les équipes produit qui les consomment. À l'inverse, un composant défaillant propage le même bug partout. Investir dans l'accessibilité des composants mutualisés, c'est obtenir le meilleur retour sur investissement possible : la conformité par défaut, sans que chaque équipe ait à réinventer la roue.

Par où commencer concrètement ?

Inutile de viser la conformité totale en une fois. Une première marche réaliste, dans l'ordre :

  1. Sémantique : passer en revue les templates et remplacer chaque <div (click)="…"> ou <span (click)="…"> par l'élément natif adapté (<button type="button">, <a href="…">, <input>, <select>…). Vérifier que chaque <input> est relié à un <label> via for/id.
  2. Navigation clavier : ouvrir l'application et naviguer uniquement à la touche Tab / Shift+Tab. Tout élément interactif doit être atteignable, activable avec Enter ou Space, et afficher un contour de focus visible (ne pas écrire outline: none sans alternative).
  3. Focus de route : injecter LiveAnnouncer du CDK Angular dans le composant racine, s'abonner à NavigationEnd, appeler announcer.announce(…) et déplacer le focus sur le <h1> via un ViewChild à chaque navigation (voir l'exemple de la section précédente).
  4. Outillage (lint + CI) : activer les règles @angular-eslint/template dans l'éditeur, puis brancher jest-axe ou @axe-core/playwright dans la pipeline — les détails et mises en garde sont dans la section Détecter au plus tôt ci-dessus.

Ce qu'un audit RGAA détecte en premier

Si vous lancez un audit aujourd'hui, voici les non-conformités qui ressortent presque systématiquement. Il y a fort à parier que vous en reconnaîtrez au moins une dans vos propres projets :

  • des boutons construits avec des <div> (ni focusables, ni activables au clavier) ;
  • des champs de formulaire sans <label> associé ;
  • des contrastes de couleur insuffisants ;
  • des modales qui piègent mal le focus (ou pas du tout) ;
  • une structure de titres incohérente (<h1> multiples, niveaux sautés) ;
  • des liens sans intitulé explicite (« cliquez ici », icône seule sans alternative) ;
  • des composants « maison » impossibles à utiliser au clavier.

La bonne nouvelle, c'est que la quasi-totalité de ces problèmes sont triviaux à éviter… à condition de les traiter dès le développement plutôt que de les découvrir en fin de cycle. C'est tout l'enjeu de la culture d'équipe.

Notre responsabilité de développeur

L'accessibilité ne s'improvise pas en fin de cycle, juste avant une livraison. C'est une culture qui se construit.

En tant que garants techniques, il est de notre devoir de porter ce sujet, de démystifier les normes ARIA et RGAA, et surtout, d'intégrer ces notions directement dans nos feuilles de route et nos parcours de formation internes. Un développeur formé à l'accessibilité produira un code plus propre, plus robuste et universellement utilisable.

Et l'IA dans tout ça ?

L'IA apporte des avancées concrètes, mais sans remplacer le jugement humain.

Côté assistants de code, GitHub Copilot peut déjà suggérer des attributs ARIA, des alternatives textuelles pour les images et recommander des éléments natifs plutôt que des <div> bricolés — à condition de lui fournir des instructions adaptées (GitHub maintient d'ailleurs un fichier d'instructions accessibilité WCAG 2.2 AA prêt à l'emploi). Ces suggestions restent un point de départ : elles doivent être vérifiées, pas prises pour argent comptant.

Côté outillage de test, Deque a franchi un cap significatif avec ses Automated Intelligent Guided Tests (IGT, janvier 2026) : l'IA prend en charge des tests complexes comme la navigation clavier et l'inspection des éléments interactifs, jusqu'à 60× plus vite qu'un test manuel. Deque revendique ainsi une couverture de 57 % des problèmes d'accessibilité avec ses outils automatisés, et jusqu'à 80 % avec les IGTs.

Ces chiffres sont encourageants, mais les experts de l'accessibilité restent plus prudents dans leurs estimations terrain : 20 à 40 % de détection pour les scanners classiques. La raison est structurelle : environ 50 % des critères WCAG 2.1 exigent un jugement humain que l'IA ne peut pas encore répliquer — pertinence d'un intitulé de lien hors contexte, cohérence de l'ordre de lecture restitué par un lecteur d'écran, fluidité du parcours pour un utilisateur en situation de handicap.

L'IA est donc un accélérateur utile pour attraper les oublis mécaniques au plus tôt. Elle ne remplace pas un audit humain.

Ne considérez plus le RGAA comme une contrainte administrative, mais comme un standard de qualité de l'ingénierie front-end. Il est temps de monter en compétence sur le sujet.

Lire la suite