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, les couleurs et le responsive design. Ces articles couvraient la philosophie et les fondements techniques de notre travail sur l'accessibilité d'un point de vue technique.

Nous voulions maintenant faire un suivi avec une perspective de design — pour montrer comment ces changements marquent une évolution dans la manière dont nous construisons nos produits. Au lieu de traiter l'accessibilité comme un ensemble de correctifs ponctuels, nous l'intégrons directement dans nos tokens, nos composants et nos patterns. Ainsi, l'accessibilité devient la norme pour chaque nouvelle fonctionnalité.

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

• Nous avons refondu notre design system en une base plus accessible, propulsée par Base UI, qui offre dès le départ une meilleure prise en charge des lecteurs d'écran et du clavier. Un grand merci à l'équipe 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 officiellement comment Glean s'aligne sur leurs normes d'accessibilité.
  

Un design system plus accessible et plus standardisé

Dans nos précédents articles, nous avons parlé de l'ajout de l'accessibilité dans la conception produit, notamment en soignant le focus clavier, en utilisant un HTML sémantique, en prenant en charge les lecteurs d'écran, et en standardisant les couleurs et la typographie. Au cœur de tout cela se trouve une pièce essentielle de l'infrastructure : notre design system.

Depuis, nous avons fortement amélioré cette base. L'objectif était simple : rendre les blocs de construction les plus courants de Glean, comme les contrôles, les boutons et les Input, accessibles par défaut, afin que chaque nouvelle fonctionnalité hérite d'un meilleur comportement sans effort supplémentaire.

Standardiser les composants, pas seulement les pages

Dans le cadre de la migration, nous avons audité chaque composant de notre bibliothèque, y compris les boutons, Input, selects, tooltips, popovers, et plus encore. Au fil du temps, nous avions été un peu trop souples sur la personnalisation des composants. Il était facile de remplacer les styles ou les comportements au niveau de l'appel, ce qui a conduit à de nombreuses variantes ponctuelles.

Nous avons utilisé la migration comme une occasion de repartir d'une base claire :

• Chaque composant dispose désormais d'une API petite et opinionated : un ensemble ciblé de props qui capture les différences sémantiques significatives (par exemple, variant, size, ou le caractère destructif), plutôt que tous les réglages de style possibles.
• Les appelants peuvent toujours passer un style, mais celui-ci est limité à des ajustements centrés sur la mise en page (comme margin) plutôt qu'au style visuel, comme les couleurs ou la typographie. Cela garde les écrans individuels flexibles sans les laisser s'éloigner 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 les designers et les ingénieurs travaillent réellement à partir du même composant, et non de simples équivalents.

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

Standardiser les tokens, pas du CSS ad hoc

Nous avons aussi standardisé les design tokens qui se trouvent sous 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 petits cas particuliers s'accumulent. Les mises en page deviennent plus difficiles à faire évoluer, la cohérence visuelle se dégrade, et la vérification du contraste ou des espacements 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 faire respecter partiellement ces tokens dans le code — un peu dans l'esprit de Tailwind, qui encourage un style utility-first piloté par des tokens.

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

Cette cohérence entre composants + tokens apporte deux bénéfices à l'accessibilité :

• Elle rend beaucoup plus difficile la mise en production accidentelle d'un élément au contraste insuffisant ou aux zones de clic trop petites, car les valeurs par défaut sont déjà conformes et cohérentes.
• Elle facilite les modifications centralisées — par exemple, améliorer un contour de focus ou le contraste du texte à un endroit, puis propager ce changement dans 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

Auparavant, obtenir un composant « parfaitement réglé » pour les lecteurs d'écran pouvait nécessiter beaucoup de travail personnalisé : choisir les bons éléments HTML, configurer les attributs ARIA, et tester dans plusieurs technologies d'assistance.

La migration vers Base UI nous a donné une base plus solide à ce niveau, et a aussi débloqué un ensemble d'améliorations pour les lecteurs d'écran qui sont désormais « gratuites » avec nos composants :

• Les composants interactifs de bas niveau exposent le bon état et les bons rôles. Des contrôles comme les switches, les checkboxes et les radios affichent 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 ce qu'est le contrôle et s'il est activé ou non. Du côté du design, nous avons standardisé ces contrôles avec des patterns clairs de label, de texte d'aide et d'erreur, afin que les équipes n'aient pas à inventer de nouveaux traitements visuels ou de nouvelles formulations pour chaque cas d'usage.
• Les composants basés sur des popups annoncent correctement leur relation. Les composants qui ouvrent une popup — comme les menus select et l'autocomplete — gèrent désormais des attributs tels que aria-haspopup et aria-expanded sur le déclencheur, et relient aria-controls pour que les lecteurs d'écran puissent identifier quelle popup est ouverte.
• Les widgets de type listbox gardent les lecteurs d'écran synchronisés avec la navigation clavier. Pour les composants basés sur des listes (comme les menus et les selects), 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 surlignée ou sélectionnée au fur et à mesure de la navigation.
• Les overlays se présentent comme des dialogs. Les modals, popovers et drawers exposent le rôle approprié role="dialog" (ou des rôles associés lorsque cela est pertinent) et portent un label qui décrit leur objectif, ce qui rend plus clair lorsqu'une nouvelle « couche » apparaît et à quoi elle sert.
• Les messages importants sont annoncés via des toasts, pas par des bidouilles artisanales. Nous faisons désormais passer les mises à jour d'état importantes par un système de toast qui utilise aria-live en interne, plutôt que des patterns ad hoc. Cela rend beaucoup plus fiable la diffusion des confirmations, erreurs et autres événements clés aux 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 button ou un link), au lieu d'imbriquer un anchor dans un button (ou l'inverse) simplement pour obtenir le bon style. C'est à la fois plus propre pour les lecteurs d'écran et moins déroutant à naviguer.
• Les tooltips se comportent mieux avec les technologies d'assistance. Les tooltips sont notoirement délicats pour l'accessibilité, car ils dépendent souvent du survol, sont difficiles à exposer de manière fiable aux lecteurs d'écran, et exigent une gestion précise du focus clavier. Dans Glean, ils apparaissent désormais non seulement au survol de la souris, mais aussi lorsqu'un élément reçoit le focus clavier — ainsi, les utilisateurs de clavier et de lecteurs d'écran reçoivent les mêmes indications que les utilisateurs de souris. Nous veillons aussi à ce que le texte de chaque tooltip soit concis et utile pour les lecteurs d'écran, et à éviter de répéter des informations déjà annoncées (par exemple, lorsqu'un élément possède déjà son propre label 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 reliées, et les changements d'état importants sont annoncés sans que chaque équipe produit ait à réinventer les mêmes patterns.

[Exemple : tooltip et menu avec prise en charge du lecteur 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 — pas seulement pour les utilisateurs de lecteurs d'écran, mais pour toute personne qui préfère ou dépend du clavier.

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

• Chaque élément interactif est prêt pour le clavier par défaut. Les boutons, liens, Input, menus, onglets et autres widgets sont tous accessibles via Tab/Shift+Tab et utilisables au clavier. Cela réduit fortement le risque qu'une fonctionnalité soit livrée avec un élément visible, mais inaccessible sans souris.
• Les dialogs gèrent le focus pour vous. Les dialogs, drawers et overlays similaires de Base UI maintiennent le focus tant qu'ils sont ouverts, de sorte que Tab reste à l'intérieur de la surface active au lieu de dériver vers la page derrière. Nous pouvons également configurer un initialFocus (l'endroit où le focus arrive quand le dialog s'ouvre) et nous appuyer sur le comportement finalFocus pour renvoyer le focus au déclencheur d'origine lorsque le dialog se ferme. Cela rend les parcours en plusieurs étapes beaucoup plus simples à suivre au clavier.
• Moins de « pièges invisibles ». Comme tout ce comportement est centralisé dans nos composants, les équipes n'ont pas à penser à la gestion du clavier et du focus à chaque fois. Cela réduit le risque d'éléments dans lesquels on peut tabuler sans pouvoir en sortir, ou de surfaces qui s'ouvrent sans moyen clair de les fermer au clavier.

En résumé ? Naviguer dans Glean au clavier devrait désormais sembler encore plus naturel et fiable, parce que la prise en charge du clavier et la gestion du focus sont intégrées aux composants sous-jacents, et non ajoutées feature par feature.

Conformité

De nombreux clients, en particulier les grandes entreprises, doivent avoir l'assurance que les outils dont ils dépendent 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 Accessibility Conformance Report (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 doit 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 la suite

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

• Chaque nouvelle fonctionnalité que nous livrons a davantage de chances 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 lourd.
• Notre design system offre aux équipes un point de départ partagé et opinionated — des couleurs et de la typographie aux composants complexes — afin que les choix accessibles soient la norme, et non une checklist séparée.
• À mesure que nous faisons évoluer l'apparence et le ressenti de Glean, nous traitons l'accessibilité comme un principe de design central, au même niveau que la clarté, la cohérence et la marque.
• Les clients peuvent évaluer formellement la manière dont Glean répond à leurs exigences d'accessibilité.

Nous continuerons à faire évoluer ce travail, en ajoutant de nouvelles améliorations et en affinant celles que nous avons déjà. Si vous utilisez des technologies d'assistance, la navigation au clavier ou des fonctionnalités d'accessibilité spécifiques et que vous avez un retour, nous serions ravis de vous lire. N'hésitez pas à nous contacter à a11y@glean.com, ou à contacter votre représentant Glean pour lancer la conversation.