Concevoir Glean pour l'accessibilité – design system et conformité

Au cours des deux dernières années, nous avons expliqué comment Glean aborde la gestion du focus et les raccourcis clavier, ainsi que les lecteurs d'écran, la couleur et le design responsive. Ces articles traitaient de la philosophie et des fondements techniques de notre travail sur l'accessibilité, du point de vue de l'ingénierie.

Nous souhaitions à présent y donner suite avec une perspective design — en montrant comment ces changements marquent une évolution dans notre façon de concevoir les produits. Plutôt que de traiter l'accessibilité comme une série de corrections ponctuelles, nous l'intégrons directement dans nos tokens, composants et patterns. Ainsi, l'accessibilité devient la norme par défaut pour chaque nouvelle fonctionnalité.

Dans cette optique, nous sommes ravis de partager deux grandes étapes de notre parcours :

• Nous avons repensé notre design system pour en faire une fondation plus accessible, propulsée par Base UI, qui offre d'emblée une meilleure accessibilité pour les lecteurs d'écran et le clavier. Un grand merci à l'équipe de Base UI et félicitations pour le lancement de la version 1.0 ! 🎉
• Nous avons finalisé notre VPAT (Voluntary Product Accessibility Template), améliorant ainsi la transparence lors des évaluations. Les clients peuvent désormais examiner de manière formelle comment Glean s'aligne sur leurs standards d'accessibilité.
  

Un design system plus accessible et standardisé

Dans nos articles précédents, nous avons évoqué l'intégration de l'accessibilité au design produit, notamment la bonne gestion du focus clavier, l'utilisation d'un HTML sémantique, la prise en charge des lecteurs d'écran et la standardisation des couleurs et de la typographie. Au cœur de tout cela se trouve un élément d'infrastructure essentiel : notre design system.

Depuis lors, nous avons considérablement amélioré cette fondation. L'objectif était simple : rendre les briques les plus courantes de Glean, comme les contrôles, boutons et champs de saisie, accessibles par défaut, afin que chaque nouvelle fonctionnalité hérite d'un meilleur comportement sans travail supplémentaire.

Standardiser les composants, pas seulement les pages

Dans le cadre de la migration, nous avons audité chaque composant de notre bibliothèque, notamment les boutons, champs de saisie, listes déroulantes, info-bulles, popovers, et plus encore. Au fil du temps, nous avions été un peu trop permissifs avec la personnalisation des composants. Il était facile de surcharger les styles ou comportements au point d'appel, ce qui a conduit à de nombreuses variations ponctuelles.

Nous avons profité de la migration pour réinitialiser la base de référence :

• Chaque composant dispose désormais d'une API réduite et affirmée : un ensemble ciblé de props qui capturent les différences significatives et sémantiques (par exemple, la variante, la taille, ou le caractère destructeur d'une action), plutôt que chaque réglage de style possible.
• Les appelants peuvent toujours transmettre un style, mais celui-ci est limité à des ajustements axés sur la mise en page (comme les marges), plutôt qu'à du style visuel comme les couleurs ou la typographie. Cela permet de garder chaque écran flexible sans qu'il ne s'écarte du système.
• Dans Figma, ces mêmes composants sont représentés avec un ensemble correspondant de variantes et d'états, de sorte que designers et ingénieurs travaillent réellement à partir du même composant, et non simplement de composants similaires.

En pratique, cela signifie qu'un composant comme Input se comporte de la même manière partout — même pattern de label, même état d'erreur, même traitement du focus — quelle que soit l'équipe qui l'utilise. Cette cohérence réduit la charge cognitive pour les utilisateurs, prévient les régressions subtiles d'accessibilité et évite que les équipes ne réimplémentent des patterns légèrement différents qui finissent par diverger au fil du temps.

Standardiser les tokens, pas du CSS ad hoc

Nous avons également standardisé les tokens de design qui sous-tendent ces composants.

Historiquement, il était facile d'insérer du CSS ad hoc comme margin : {number}px ou une couleur hexadécimale directement dans un composant. Sur des centaines de composants, ces petites exceptions s'accumulent. Les mises en page sont plus difficiles à modifier, la cohérence visuelle se dégrade et la vérification des problèmes de contraste ou d'espacement devient plus manuelle.

Aujourd'hui, l'espacement, la couleur et la typographie passent tous par un système tokenisé. Comme nous utilisons déjà vanilla‑extract, nous avons ajouté sprinkles par-dessus pour semi‑imposer ces tokens dans le code — dans un esprit proche de la manière dont Tailwind encourage un style orienté utilitaires et piloté par les tokens.

• Besoin d'espacement ? Vous utilisez un token d'espacement, pas une valeur brute en pixels.
• Besoin d'une couleur de texte ou d'arrière-plan ? Vous choisissez parmi les tokens de couleur sémantiques déjà validés pour le contraste.
• Besoin d'ajuster la mise en page ? Vous recourez à des utilitaires prévisibles au lieu d'inventer un nouveau pattern.

Cet alignement entre composants + tokens apporte deux bénéfices pour l'accessibilité :

• Il devient beaucoup plus difficile de livrer accidentellement quelque chose avec un contraste médiocre ou des zones de clic minuscules, car les valeurs par défaut sont déjà conformes et cohérentes.
• Il devient plus facile de modifier les choses de manière centralisée — par exemple, en améliorant un anneau de focus ou le contraste du texte à un seul endroit pour que cela se propage à travers tout le produit.

À titre d'exemple, nous avions auparavant plusieurs versions ad hoc du composant Input :

‍
Après la migration, cela est devenu :

Une meilleure prise en charge des lecteurs d'écran intégrée nativement

Auparavant, rendre un composant « parfaitement adapté » aux lecteurs d'écran pouvait nécessiter beaucoup de travail personnalisé : choisir les bons éléments HTML, câbler les attributs ARIA et tester avec plusieurs technologies d'assistance.

La migration vers Base UI nous a offert une fondation plus solide sur ce point, et elle a également débloqué une série d'avantages pour les lecteurs d'écran qui viennent désormais « gratuitement » avec nos composants :

• Les composants interactifs de bas niveau exposent le bon état et les bons rôles. Les contrôles comme les interrupteurs, cases à cocher et boutons radio exposent désormais automatiquement le rôle approprié ainsi que des attributs d'état comme aria-label et aria-checked, afin que les technologies d'assistance puissent annoncer correctement la nature du contrôle et s'il est activé ou non. Côté design, nous avons standardisé ces contrôles avec des patterns clairs de label, de texte d'aide et d'erreur, de sorte que les équipes n'aient pas à inventer de nouveaux traitements visuels ou formulations pour chaque cas d'usage.
• Les composants basés sur des popups annoncent correctement leur relation. Les composants qui ouvrent un popup — comme les menus de sélection et l'autocomplétion — gèrent désormais des attributs tels que aria-haspopup et aria-expanded sur le déclencheur, et connectent aria-controls afin que les lecteurs d'écran puissent identifier quel popup est ouvert.
• Les widgets de type listbox maintiennent les lecteurs d'écran synchronisés avec la navigation au clavier. Pour les composants basés sur des listes (comme les menus et les sélecteurs), le focus clavier et la sélection sont reflétés via les rôles et attributs de sélection appropriés, afin que les lecteurs d'écran puissent annoncer quelle option est actuellement mise en évidence ou sélectionnée au fur et à mesure que vous parcourez la liste.
• Les superpositions se décrivent comme des boîtes de dialogue. Les fenêtres modales, les popovers et les tiroirs exposent le rôle approprié role="dialog" (ou des rôles connexes le cas échéant) et portent une étiquette décrivant leur objectif, ce qui permet de mieux comprendre lorsqu'une nouvelle « couche » est apparue et à quoi elle sert.
• Les messages importants sont annoncés via des toasts, et non via des bricolages maison. Nous acheminons désormais les mises à jour de statut importantes via un système de toasts qui utilise aria-live en arrière-plan, plutôt que des schémas improvisés. Cela rend beaucoup plus fiable l'annonce des confirmations, des erreurs et d'autres événements clés pour les utilisateurs de lecteurs d'écran.
• Moins d'éléments interactifs imbriqués. Nos composants rendent désormais un seul élément interactif correctement typé (par exemple, un bouton ou un lien), au lieu d'imbriquer une ancre dans un bouton (ou vice versa) juste pour obtenir le bon style. C'est à la fois plus propre pour les lecteurs d'écran et moins déroutant à naviguer.
• Les info-bulles se comportent mieux avec les technologies d'assistance. Les info-bulles sont notoirement délicates en matière d'accessibilité, car elles reposent souvent sur un comportement limité au survol, sont difficiles à exposer de manière fiable aux lecteurs d'écran et nécessitent une gestion attentive du focus clavier. Dans Glean, elles s'affichent désormais non seulement au survol de la souris, mais aussi lorsqu'un élément reçoit le focus clavier — de sorte que les utilisateurs du clavier et des lecteurs d'écran obtiennent les mêmes indications que les utilisateurs de la souris. Nous veillons également à ce que le texte à l'intérieur de chaque info-bulle soit concis et utile pour les lecteurs d'écran, et nous évitons de répéter des informations déjà annoncées (par exemple, lorsqu'un élément possède déjà sa propre étiquette accessible).

En pratique, cela signifie que lorsque vous utilisez Glean avec un lecteur d'écran, une plus grande partie de l'interface « fonctionne tout simplement » dès le départ : les bons rôles sont exposés, les bonnes relations sont établies et les changements d'état importants sont annoncés sans que chaque équipe produit n'ait à réinventer les mêmes schémas.

[Exemple : info-bulle et menu avec prise en charge des lecteurs d'écran dès le départ]

Une meilleure prise en charge du clavier et de la gestion du focus

Dans la première partie de cette série, nous avons souligné à quel point la navigation au clavier et le focus sont importants — non seulement pour les utilisateurs de lecteurs d'écran, mais pour toute personne qui préfère le clavier ou en dépend.

Notre nouveau design system prolonge ce travail et rend ces comportements encore plus fiables :

• Chaque élément interactif est compatible avec le clavier par défaut. Les boutons, liens, champs de saisie, menus, onglets et autres widgets sont tous accessibles via Tab/Maj+Tab et utilisables au clavier. Cela réduit considérablement le risque qu'une fonctionnalité soit livrée avec un élément que vous pouvez voir, mais que vous ne pouvez pas atteindre sans souris.
• Les boîtes de dialogue gèrent le focus à votre place. Les boîtes de dialogue, tiroirs et superpositions similaires de Base UI piègent le focus tant qu'ils sont ouverts, de sorte que Tab reste à l'intérieur de la surface active au lieu de s'égarer sur la page en arrière-plan. Nous pouvons également configurer un initialFocus (l'endroit où le focus se place à l'ouverture de la boîte de dialogue) et nous appuyer sur le comportement finalFocus pour restaurer le focus vers le déclencheur d'origine lorsque la boîte de dialogue se ferme. Cela rend les parcours en plusieurs étapes beaucoup plus faciles à suivre du point de vue d'une utilisation au clavier uniquement.
• Moins de « pièges invisibles ». Comme tout ce comportement est centralisé dans nos composants, les équipes n'ont pas à se souvenir de configurer la gestion du clavier et du focus à chaque fois. Cela réduit le risque d'éléments isolés sur lesquels vous pouvez naviguer avec Tab sans pouvoir en sortir, ou de surfaces qui s'ouvrent sans moyen clair de les fermer au clavier.

En clair ? Naviguer dans Glean au clavier devrait désormais sembler encore plus naturel et fiable, car la prise en charge du clavier et la gestion du focus sont intégrées dans les composants sous-jacents, et non ajoutées fonctionnalité par fonctionnalité.

Conformité

De nombreux clients, en particulier les grandes entreprises, ont besoin d'avoir l'assurance que les outils sur lesquels ils s'appuient répondent aux attentes en matière d'accessibilité. Pour les logiciels, cela nécessite souvent de fournir un VPAT — un document standardisé décrivant comment un produit prend en charge des critères d'accessibilité spécifiques (comme WCAG 2.2 A et AA).

Nous sommes heureux d'annoncer que Glean dispose désormais d'un rapport de conformité à l'accessibilité (ACR) à jour, basé sur le dernier format VPAT® 2.5, couvrant WCAG 2.0, 2.1 et 2.2 aux niveaux A et AA.

Si votre équipe a besoin d'examiner en profondeur l'accessibilité de Glean dans le cadre de votre évaluation ou de votre due diligence, vous pouvez le trouver sur notre page de ressources.

Pourquoi cela compte pour l'avenir

L'accessibilité n'est jamais « terminée », mais la refonte de notre design system nous offre une base bien plus solide :

• Chaque nouvelle fonctionnalité que nous livrons est plus susceptible d'être accessible dès le premier jour, car elle repose sur des composants qui prennent déjà en charge une grande partie du travail.
• Notre design system offre aux équipes un point de départ commun et affirmé — des couleurs et de la typographie aux composants complexes — de sorte que les choix accessibles deviennent la norme, et non une liste de contrôle séparée.
• À mesure que nous continuons à faire évoluer l'apparence et le ressenti de Glean, nous traitons l'accessibilité comme un principe de conception fondamental, au même titre que la clarté, la cohérence et la marque.
• Les clients peuvent évaluer formellement la manière dont Glean répond à leurs exigences en matière d'accessibilité.

Nous continuerons à itérer sur ce travail, en ajoutant de nouvelles améliorations et en affinant celles que nous avons déjà. Si vous dépendez des technologies d'assistance, de la navigation au clavier ou de fonctionnalités d'accessibilité spécifiques et avez des retours à nous faire, nous serions ravis de vous entendre. N'hésitez pas à nous contacter à l'adresse a11y@glean.com, ou à échanger avec votre représentant Glean pour entamer la conversation.