Skip to content

Vous souhaitez recevoir de l'aide sur ce sujet ? rejoignez la communauté Angular.fr sur Discord.

Angular Aria, la réponse à Radix

Si vous venez de l'écosystème Angular, le nom Radix ne vous dit peut-être rien. Dans l'écosystème React, Radix UI est une bibliothèque de composants "headless" : elle fournit le comportement accessible de composants complexes, comme les menus, les listes de sélection, les onglets ou les dialogues, mais elle ne fournit pas le design final.

Autrement dit, Radix ne vous donne pas un bouton violet ou un menu déjà stylé. Il vous donne la logique difficile : clavier, focus, attributs ARIA, états ouverts ou fermés, interactions attendues par les lecteurs d'écran. Ensuite, vous appliquez votre propre CSS, votre design system, votre charte graphique.

C'est exactement le terrain sur lequel Angular Aria arrive.

Pour les équipes qui construisent un design system ou des composants métier, c'est une évolution importante : Angular propose désormais une base officielle pour créer des composants interactifs accessibles, sans imposer de style.

Angular Aria ajoute le comportement accessible aux composants personnalisés

Au 25 mai 2026, le package @angular/aria est disponible en Angular 21 et la version 22.0.0-rc.1 existe déjà sur npm. La roadmap officielle indique que l'équipe Angular prévoit de promouvoir les patterns Angular Aria vers un statut stable et d'en ajouter d'autres si nécessaire. Angular 22.0 est prévu pour la semaine du 1er juin 2026, donc il faut rester précis : la stabilisation est attendue avec Angular 22, mais elle sera définitivement actée par la publication finale de la version.

Cette précision est importante : Angular Aria n'est pas encore une promesse magique qui remplace tout l'écosystème UI Angular. C'est une brique officielle, très attendue, qui répond à un manque réel.

Le vrai problème : l'accessibilité interactive est difficile

Un bouton HTML simple est déjà accessible par défaut :

html
<button type="button">Enregistrer</button>

Le navigateur sait comment le gérer au clavier. Les lecteurs d'écran savent l'annoncer. Le focus fonctionne naturellement.

Mais dès que l'on construit un composant plus riche, les choses se compliquent :

  • un menu déroulant avec sous-menus ;
  • une liste sélectionnable au clavier ;
  • des onglets ;
  • une grille navigable cellule par cellule ;
  • un combobox avec suggestions ;
  • une toolbar d'éditeur de texte.

Ces composants ne demandent pas seulement du HTML et du CSS. Ils demandent aussi :

  • une navigation clavier cohérente ;
  • une gestion correcte du focus ;
  • des rôles ARIA adaptés ;
  • des états comme aria-expanded, aria-selected, aria-checked ou aria-disabled ;
  • un comportement compréhensible pour les technologies d'assistance.

C'est précisément le type de logique que l'on sous-estime facilement. Le composant peut "marcher" à la souris tout en étant pénible, voire inutilisable, au clavier ou avec un lecteur d'écran.

Angular Aria, c'est quoi ?

Angular Aria est une collection de directives headless pour des patterns WAI-ARIA courants.

"Headless" veut dire : Angular fournit le comportement, mais pas l'apparence. Vous gardez votre HTML, votre CSS, votre design system et vos règles métier. La bibliothèque se concentre sur les interactions difficiles à réécrire correctement :

  • interactions clavier ;
  • attributs ARIA ;
  • gestion du focus ;
  • support des lecteurs d'écran ;
  • états internes exposés sous forme utilisable dans vos templates.

Installation :

bash
npm install @angular/aria

L'idée n'est donc pas de remplacer Angular Material. Angular Material reste une bibliothèque de composants déjà stylés. Angular Aria vise plutôt les équipes qui veulent construire leurs propres composants visuels, mais qui ne veulent pas repartir de zéro sur les comportements d'accessibilité.

La comparaison avec Radix est donc utile, mais elle a une limite : Angular Aria parle le langage d'Angular. Les exemples s'appuient sur les directives, les templates Angular, les Signals, les imports standalone, et l'intégration progressive avec les nouveaux formulaires orientés Signals.

Ce qui est disponible

Avec Angular 21, Angular Aria est arrivé en Developer Preview. L'annonce officielle mentionne huit patterns de départ, couvrant treize composants :

  • Accordion ;
  • Combobox ;
  • Grid ;
  • Listbox ;
  • Menu ;
  • Tabs ;
  • Toolbar ;
  • Tree.

La documentation officielle liste aussi des composants plus spécialisés autour de la recherche et de la sélection, comme Autocomplete, Select et Multiselect.

On peut voir Angular Aria comme une couche située entre plusieurs options :

  • HTML natif : idéal dès qu'un élément standard suffit, par exemple button, input, select ou details.
  • Angular CDK : utile pour des primitives de comportement plus générales, comme l'overlay, le drag and drop ou certains outils d'infrastructure.
  • Angular Material : adapté quand on veut des composants complets, déjà stylés, avec l'approche Material Design.
  • Angular Aria : pertinent quand on veut un composant sur mesure, mais avec une base officielle pour l'accessibilité interactive.

Pourquoi Angular avait besoin de ça

Pendant longtemps, Angular avait deux réponses principales pour les composants :

  • Angular Material, très utile si l'on accepte son approche visuelle ;
  • Angular CDK, très utile pour des primitives comme l'overlay, le drag and drop ou certaines briques d'accessibilité.

Mais il manquait une réponse officielle proche de ce que Radix représente côté React : des composants sans style imposé, pensés pour construire un design system moderne.

C'est d'ailleurs un reproche récurrent dans les discussions communautaires : React dispose de Radix, Headless UI, Shadcn UI et d'un écosystème très visible autour des composants composables. Angular, lui, a longtemps donné l'impression d'avoir soit Material, soit des bibliothèques tierces complètes, mais moins de primitives officielles pour composer librement.

Angular Aria ne règle pas tout d'un coup. Mais il donne enfin un socle officiel pour cette catégorie de besoin.

Un exemple avec une toolbar

Prenons une toolbar d'éditeur. Visuellement, cela peut ressembler à une simple ligne de boutons. En pratique, une toolbar accessible doit avoir un nom, une navigation clavier logique, des groupes d'options, et des états lisibles par les technologies d'assistance.

Avec Angular Aria, on importe les directives du pattern toolbar :

ts
import { Component } from '@angular/core';
import {
  Toolbar,
  ToolbarWidget,
  ToolbarWidgetGroup,
} from '@angular/aria/toolbar';

@Component({
  selector: 'app-editor-toolbar',
  imports: [Toolbar, ToolbarWidget, ToolbarWidgetGroup],
  template: `
    <div ngToolbar aria-label="Outils de mise en forme">
      <button ngToolbarWidget type="button" value="undo" aria-label="Annuler">
        Annuler
      </button>

      <div ngToolbarWidgetGroup role="radiogroup" aria-label="Alignement du texte">
        <button
          ngToolbarWidget
          role="radio"
          type="button"
          value="left"
          aria-label="Aligner à gauche"
          #left="ngToolbarWidget"
          [aria-checked]="left.selected()"
        >
          Gauche
        </button>
      </div>
    </div>
  `,
})
export class EditorToolbar {}

Le point important : le CSS reste à votre charge. Angular Aria ne décide pas si le bouton est bleu, carré, arrondi, dense ou large. En revanche, il donne une structure de comportement pour que le composant ne soit pas seulement joli, mais aussi utilisable.

Ce que la stabilisation change

Un statut Developer Preview veut dire que l'API est déjà destinée aux développeurs, documentée, et suffisamment avancée pour être testée sérieusement. Mais cela laisse encore une marge d'ajustement avant stabilité.

Le passage en stable avec Angular 22 est important pour trois raisons :

  1. Les équipes auront plus de confiance pour intégrer Angular Aria dans un design system durable.
  2. Les API devraient devenir moins susceptibles de changer brutalement.
  3. Angular clarifie son offre officielle pour les composants : Material pour les composants stylés, CDK pour les primitives, Aria pour les patterns accessibles headless.

Cela ne veut pas dire qu'Angular Aria rend automatiquement une application conforme à toutes les exigences d'accessibilité. La bibliothèque aide sur une partie difficile, mais l'équipe produit garde la responsabilité du HTML final, des libellés, des contrastes, des tests clavier, des tests lecteur d'écran et du contexte d'usage.

Le ressenti de la communauté

Les premiers retours GitHub donnent une image assez claire : l'idée est bien accueillie, mais les développeurs attendent encore du polissage pour les cas réels.

Dans une discussion sur le manque de solutions de type Radix ou Shadcn côté Angular, un membre de l'équipe Angular répond que ce besoin doit être adressé par Angular Aria en v21. Cela confirme l'intention : Angular Aria n'est pas seulement une bibliothèque d'accessibilité isolée, c'est aussi une réponse au besoin de composants headless officiels.

Les retours terrain sont cependant plus nuancés. Un développeur explique avoir essayé d'intégrer un combobox Angular Aria dans une vraie application, avec Angular Material, MatFormField et Signal Forms. Son bilan est positif sur la direction, mais il dit avoir rencontré assez de friction pour abandonner cette intégration à ce moment-là.

Les points qui reviennent le plus :

  • l'intégration avec Angular Material n'est pas encore aussi fluide qu'espéré ;
  • MatFormFieldControl n'est pas encore naturellement aligné avec les Signals ;
  • les exemples de documentation doivent mieux couvrir Signal Forms ;
  • les tests de composants Angular Aria ont besoin d'exemples concrets ;
  • les patterns combobox et listbox concentrent plusieurs bugs et cas limites.

La réponse de l'équipe Angular est intéressante : les directives Aria ont déjà été mises à jour pour mieux fonctionner avec Signal Forms, des test harnesses ont été ajoutés, et une PR de documentation Angular Aria pour v22 est en cours afin de couvrir les changements d'API, les harnesses de test et l'intégration Signal Forms.

On peut donc résumer le ressenti ainsi : enthousiasme prudent.

La communauté voit bien l'intérêt stratégique. Mais elle teste maintenant Angular Aria contre des contraintes de production : composants partagés, design system, wrappers internes, overlays, formulaires, tests, comportements clavier avancés. C'est exactement là que la maturité d'une bibliothèque headless se juge.

Quand l'utiliser ?

Angular Aria est un bon choix dès maintenant si :

  • vous construisez une bibliothèque de composants interne ;
  • votre UI doit suivre une charte graphique précise ;
  • vous avez besoin de patterns interactifs complexes ;
  • vous voulez éviter de réimplémenter vous-même le comportement clavier et ARIA ;
  • vous acceptez de gérer le style et la composition HTML.

Il est moins adapté si :

  • un élément HTML natif suffit ;
  • vous voulez prototyper très vite avec des composants déjà stylés ;
  • votre équipe n'a pas prévu de tester l'accessibilité du rendu final ;
  • vous cherchez une bibliothèque visuelle complète prête à l'emploi ;
  • vous avez besoin d'un combobox très avancé et vous ne voulez pas suivre les changements d'API autour d'Angular 22.

La bonne manière de le lire

Angular Aria n'est pas une décoration autour d'ARIA. C'est la réponse d'Angular à un problème que Radix a rendu très visible côté React : beaucoup d'équipes veulent des composants sur mesure, mais peu ont envie de maintenir à la main toute la logique d'interaction attendue par les patterns WAI-ARIA.

Avec Angular 22, la trajectoire de stabilisation rend cette option beaucoup plus intéressante pour les design systems Angular. Le bon réflexe reste le même : commencer par le HTML natif quand il suffit, utiliser Angular Material quand son style convient, et choisir Angular Aria quand vous avez besoin d'un composant personnalisé, mais pas d'une accessibilité improvisée.

Il faut seulement garder une nuance : Angular Aria est prometteur, officiel, et déjà utilisable, mais les composants les plus complexes, en particulier autour du combobox, sont encore en phase de consolidation. C'est normal pour une brique aussi structurante. C'est aussi pour cela qu'il faut suivre de près les guides Angular 22.

Sources