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 :

Looking at the EN original, the first `

` block in the EN contains three bullet points (keyboard-friendly, dialogs manage focus, fewer invisible traps). However, the FR translation begins with a completely different `
` block (about interactive components exposing state/roles, popups, listbox widgets, overlays, toasts, nested interactive elements, tooltips) that does NOT appear in the EN part 2/2 provided. This is a mismatch at the very start. The EN part 2/2 starts with the three-bullet list. The FR has extra content that belongs to part 1 or was carried over. Let me compare carefully. The EN provided starts with `
• Every interactive element is keyboard-friendly...`. The FR provided starts with `
  • Les composants interactifs de bas niveau exposent...`. The FR contains a large extra section (the first `
    `, the paragraph, the figure, the "[Exemple...]" and the h2 "Une meilleure prise en charge du clavier...") that is NOT in the EN part 2/2. Then the FR continues with the content that matches the EN. Since the task is to check that the FR matches the EN original meaning, and the EN provided is only part 2/2, the matching portion of the FR is correct. The extra leading content appears to be the tail of part 1 bleeding in. But I must return a FR that matches the EN provided. The corrected FR should start at the content matching the EN first bullet:
    • 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.