Bibliothèques de composants accessibles : comparatif

Une fenêtre modale s’ouvre. Au clavier, la touche Tab emmène l’utilisateur derrière elle, dans la page grisée qu’il ne voit plus. La touche Échap ne fait rien. Un lecteur d’écran annonce « bouton » sans dire lequel. Le composant venait pourtant d’une bibliothèque présentée comme accessible ; il avait simplement été restylé et modifié sans qu’on en mesure les effets. Les composants accessibles sont un vrai gain pour une équipe de développement. Encore faut-il savoir ce qu’ils garantissent, et ce qu’ils laissent à faire.

Ce comparatif examine six options répandues, sur les mêmes critères : React Aria, Radix Primitives, Headless UI, le Component Dev Kit d’Angular, le Système de design de l’État français (DSFR) et GOV.UK Frontend. Les descriptions s’appuient sur la documentation publique des projets ; les fonctions évoluent, il faut les vérifier au moment du choix.

Ce qu’une bibliothèque peut prendre en charge

Les composants simples (un bouton, un lien, une case à cocher) sont accessibles nativement si l’on utilise les bons éléments HTML. La difficulté commence avec les composants que HTML ne fournit pas, ou mal : fenêtres modales, menus, onglets, listes déroulantes avec recherche, accordéons, info-bulles, sélecteurs de date. Pour chacun, le W3C décrit dans le guide des pratiques de rédaction ARIA (ARIA Authoring Practices Guide) le comportement attendu : touches, gestion du focus, rôles et états à exposer.

C’est ce comportement qu’une bonne bibliothèque implémente et maintient, sur plusieurs navigateurs et lecteurs d’écran, ce qui représente un travail considérable. Ce qu’elle ne peut pas garantir : les contrastes de couleurs choisis par l’équipe, les libellés écrits par les développeurs, la structure de la page, les contenus. Les critères des WCAG et du RGAA portent sur la page assemblée, pas sur les briques.

Les six options sur les mêmes critères

Trois familles, trois partages des responsabilités

Les bibliothèques sans style

React Aria, Radix Primitives et Headless UI fournissent le comportement et laissent l’apparence à l’équipe. Elles conviennent à une organisation qui a sa propre identité visuelle et un système de design à construire ou à faire évoluer. React Aria se distingue par son étendue et par le soin apporté à l’internationalisation, utile pour une interface en plusieurs langues ou en écriture de droite à gauche. Radix est très utilisé, notamment comme base de collections de composants prêts à copier. Headless UI est plus réduit, et s’intègre naturellement à un projet qui utilise déjà Tailwind CSS.

Les outils d’un framework

Le Component Dev Kit d’Angular propose des briques de comportement : piège de focus pour les fenêtres, gestion du clavier dans les listes, annonces aux lecteurs d’écran, détection du mode de contraste élevé. Angular Material, construit dessus, ajoute des composants stylés. C’est le choix naturel pour une application déjà écrite en Angular, fréquente dans les systèmes d’information internes des administrations et des grandes entreprises.

Les systèmes de design publics

Le DSFR et GOV.UK Frontend livrent un ensemble complet : composants, styles, typographie, couleurs aux contrastes vérifiés, gabarits de pages et conseils de rédaction. Ils sont pensés pour des démarches en ligne utilisées par tous les publics, et documentent leurs choix d’accessibilité. Leur contrepartie est leur identité : le DSFR porte la marque de l’État et son usage est réservé aux sites de l’État ; GOV.UK Frontend est sous licence libre, mais l’identité GOV.UK est réservée aux services du gouvernement britannique. Pour d’autres organisations, ils restent d’excellentes références de documentation et de méthode.

Ce qui reste à l’équipe, quelle que soit l’option

Même avec la meilleure bibliothèque, une série de critères dépend entièrement de ceux qui assemblent les pages. Les libellés d’abord : un bouton d’icône sans nom accessible, un champ sans étiquette visible, un lien « cliquez ici » répété dix fois ne sont rattrapés par aucun composant. La structure ensuite : titres hiérarchisés, régions de page, langue déclarée, ordre de lecture cohérent avec l’ordre visuel. Les contenus enfin : textes alternatifs des images, sous-titres des vidéos, documents téléchargeables accessibles, langage clair.

Il faut aussi résister à la tentation de modifier un composant pour un besoin ponctuel. Remplacer un élément interactif par une simple boîte cliquable, supprimer le contour de focus parce qu’il « gêne le design », déplacer un menu hors de son conteneur : chacune de ces retouches peut annuler le travail de la bibliothèque. Une règle simple aide : toute modification d’un composant partagé passe par une revue d’accessibilité, comme une modification de sécurité passe par une revue de code.

Tester une bibliothèque en une demi-journée

Les déclarations des projets sont utiles, mais elles ne remplacent pas un test sur vos navigateurs et avec les technologies d’assistance de vos utilisateurs. Une demi-journée suffit à repérer l’essentiel.

1. Choisir cinq composants difficiles Fenêtre modale, menu déroulant, onglets, liste de choix avec recherche, sélecteur de date. Ce sont eux qui départagent.
2. Les utiliser au clavier seul Tab, Maj+Tab, flèches, Entrée, Espace, Échap. Le focus doit rester visible, ne jamais se perdre, revenir au bon endroit à la fermeture.
3. Les écouter avec un lecteur d’écran NVDA sous Windows, VoiceOver sur macOS et iOS, TalkBack sur Android selon votre public. Chaque élément doit annoncer son rôle, son nom et son état.
4. Agrandir et changer de mode Zoom à 200 % et 400 %, mode de contraste élevé de Windows, préférences de réduction des animations.
5. Lire l’historique du dépôt Fréquence des versions, délai de traitement des signalements d’accessibilité, nombre de mainteneurs actifs. Une bibliothèque peu maintenue devient un risque.

Notre lecture

Pour un site public de l’État français, le DSFR s’impose et fait gagner un temps considérable. Pour une organisation dotée de sa propre identité et d’une équipe React, React Aria offre la couverture la plus large, Radix un très bon compromis ; Headless UI suffit pour une interface simple déjà construite avec Tailwind CSS. Pour une application Angular, le Component Dev Kit est le socle logique. Dans tous les cas, le choix de la bibliothèque n’est que le premier tiers du travail : le deuxième est d’intégrer l’accessibilité dans le système de design (contrastes, focus, tailles, règles d’usage), le troisième de tester les pages assemblées.

Notre offre Accessibilité et inclusion et notre expertise web accessible aident les équipes à faire ce choix et à le vérifier sur leurs propres écrans. Pour le cadre réglementaire et la démarche d’ensemble, voir notre dossier sur l’accessibilité numérique.

1. W3C, ARIA Authoring Practices Guide (APG).
2. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, octobre 2023.
3. DINUM, Référentiel général d’amélioration de l’accessibilité (RGAA) 4.1.2.
4. Adobe, documentation de React Aria.
5. WorkOS, documentation de Radix Primitives.
6. Tailwind Labs, documentation de Headless UI.
7. Angular, documentation du Component Dev Kit, module d’accessibilité.
8. Service d’information du Gouvernement, Système de design de l’État (systeme-de-design.gouv.fr).
9. Government Digital Service, GOV.UK Design System et GOV.UK Frontend.

Questions fréquentes

Une bibliothèque de composants accessibles suffit-elle pour être conforme au RGAA ?

Non. Elle peut rendre conformes les comportements de ses composants, mais la conformité porte sur la page assemblée : contrastes, textes alternatifs, titres, langue, ordre de lecture, formulaires, contenus éditoriaux. Une partie importante des critères dépend de l'usage qui est fait des composants et du contenu.

Qu'est-ce qu'une bibliothèque « sans style » (headless) ?

C'est une bibliothèque qui fournit le comportement d'un composant (gestion du clavier, du focus, des attributs ARIA, de l'état ouvert ou fermé) sans imposer d'apparence. L'équipe applique son propre design. C'est souple, mais les contrastes, la visibilité du focus et les tailles de cible deviennent sa responsabilité.

Peut-on utiliser le DSFR pour un site qui n'est pas celui de l'État ?

Le Système de design de l'État est destiné aux sites et services de l'État, et son usage est encadré par des conditions publiées. Les autres organisations peuvent s'inspirer de sa documentation et de ses principes, mais doivent vérifier les conditions d'utilisation avant de reprendre ses composants et son identité.

Comment vérifier rapidement l'accessibilité d'une bibliothèque ?

En testant soi-même quatre ou cinq composants complexes (fenêtre modale, menu déroulant, onglets, liste de choix, sélecteur de date) au clavier seul, puis avec un lecteur d'écran, sur les navigateurs de vos utilisateurs. Une demi-journée suffit pour repérer les faiblesses principales.