Auparavant, dans la première partie de notre série sur l’accessibilité, nous avons abordé l’importance de concevoir des produits en pensant à l’accessibilité dès le départ, nos principes directeurs en matière d’accessibilité, ainsi que nos efforts pour améliorer les systèmes de focus et de raccourcis dans Glean. ;
Dans cet article, nous allons explorer d’autres améliorations et fonctionnalités d’accessibilité — en particulier notre expérience avec les lecteurs d’écran, notre approche des palettes de couleurs et le responsive design.
Améliorer l’expérience avec les lecteurs d’écran
Les lecteurs d’écran peuvent aider les utilisateurs malvoyants à naviguer sur le web. Cela ressemble à une navigation au clavier via des raccourcis, avec en plus une voix off qui indique aux utilisateurs avec quoi ils interagissent. Ce qui rend un lecteur d’écran particulièrement utile, c’est qu’il prend déjà en charge de nombreux raccourcis clavier nativement, à condition que le développeur utilise la sémantique/le balisage approprié pour son UI.
Prenons VoiceOver (le lecteur d’écran par défaut de macOS) et ses raccourcis comme exemple :
< ;ul type='disc'> ;
; ;< ;li> ; Toutes les touches fléchées mentionnées ci-dessus devraient fonctionner immédiatement avec VoiceOver. < ;ul type='disc'> ;
; ; ; ;< ;li> ; Par ex., en utilisant correctement un élément < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;ul< ; ;/span> ; (ou < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;role="list"< ; ;/span> ; ;) pour présenter une liste, un utilisateur de lecteur d’écran peut utiliser [VO] + [Option] + [Gauche/Droite] pour naviguer entre les éléments de la liste < ; ;/li> ;
; ; ; ;< ;li> ; De même, il peut utiliser [VO] + [Gauche/Droite/Haut/Bas] pour naviguer dans un tableau, de façon similaire à ce que nous avons mis en place < ; ;/li> ;
; ; < ; ;/ul> ;
; ;< ; ;/li> ;
< ; ;/ul> ;
Lors de l’optimisation du fonctionnement des lecteurs d’écran, il nous a semblé utile de prendre en compte les facteurs suivants :
1) Choisir le bon élément pour la bonne tâche
- Utilisez toujours l’élément sémantiquement le plus approprié pour votre UI. Par exemple, utilisez un < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;button& ;gt ; ;< ; ;/span> ; HTML natif plutôt qu’un < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;div& ;gt ; ;< ; ;/span> ; personnalisé. Utilisez < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;table< ; ;/span> ; (avec < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;tr< ; ;/span> ; ;, < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;th< ; ;/span> ; ;, etc.) plutôt que des < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;div< ; ;/span> ; imbriqués.
- Choisir le bon élément, comme montré plus haut, aide grandement le lecteur d’écran en lui permettant de comprendre automatiquement la fonctionnalité de l’UI. Il peut alors ; fournir des descriptions vocales correctes et les raccourcis appropriés.
2) En cas de doute, expliquez
< ;ul type='disc'> ;
; ;< ;li> ; Plus le contenu est visuellement chargé, plus il faut lui associer d’informations afin de le rendre accessible aux utilisateurs malvoyants. Même pour les utilisateurs non concernés, nous ne pouvons pas supposer qu’ils déduiront exactement la même information que l’auteur. < ; ;/li> ;
; ;< ;li> ; Un exemple canonique est la fameuse illusion du canard et du lapin. Dans un exemple similaire mais plus concret, des utilisateurs différents peuvent interpréter différemment la fonction d’un bouton (par ex., une icône d’exclamation peut avoir plusieurs significations). Avoir un texte associé à l’image/au visuel aidera à guider l’utilisateur vers l’usage prévu. < ; ;/li> ;
; ;< ;li> ; Une autre option consiste à utiliser des info-bulles (tooltips) pour fournir des indices utiles. Toutefois, il est généralement non trivial de rendre des info-bulles accessibles à un lecteur d’écran. L’alternative consiste à utiliser : < ;ul type='disc'> ;
; ; ; ;< ;li> ; l’attribut < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;alt< ; ;/span> ; pour < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;img& ;gt ; ;< ; ;/span> ;
; ; ; ;< ; ;/li> ;
; ; ; ;< ;li> ; < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;aria-label< ; ;/span> ; ;, ou < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;aria-describedby< ; ;/span> ; / < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;aria-description< ; ;/span> ; pour d’autres éléments interactifs comme < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;button& ;gt ; ;< ; ;/span> ; ou < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;a& ;gt ; ;< ; ;/span> ;
; ; ; ;< ; ;/li> ;
; ; < ; ;/ul> ;
; ;< ; ;/li> ;
; ;< ;li> ; Les attributs ci-dessus permettent aux lecteurs d’écran de traiter et de restituer aux utilisateurs des informations visuelles. < ; ;/li> ;
; ;< ;li> ; Une autre excellente option est de permettre aux utilisateurs d’ajouter du texte alternatif supplémentaire / des légendes pour les images. < ; ;/li> ;
< ; ;/ul> ;
3) Autres conseils pour améliorer l’expérience avec les lecteurs d’écran
< ;ul type='disc'> ;
; ;< ;li> ; Côté développement, il existe un plugin React < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;eslint< ; ;/span> ; populaire qui aide à détecter les problèmes de sémantique (tout en proposant des solutions et des recommandations) < ; ;/li> ;
; ;< ;li> ; Un écueil fréquent consiste à fournir trop d’informations au lecteur d’écran, ce qui surcharge involontairement l’utilisateur et dégrade l’expérience. Il est important de ne fournir que les attributs nécessaires — décrits de manière concise. < ;ul type='disc'> ;
; ; ; ;< ;li> ; Ex. : pour < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;img& ;gt ; ;< ; ;/span> ; ;, n’incluez pas « photos » ou « images » dans le texte alternatif, car c’est redondant (l’information est déjà déduite du nom de la balise) < ; ;/li> ;
; ; ;< ; ;/ul> ;
; ;< ; ;/li> ;
; ;< ;li> ; Plus votre UI est complexe, plus elle doit recourir à une sémantique et à un balisage appropriés < ; ;/li> ;
< ; ;/ul> ;
Adopter un thème de couleurs standardisé ;
Par ailleurs, nous avons aussi relevé quelques autres défis qui ont contribué à l’effort global d’accessibilité. L’un d’eux consistait à standardiser nos thèmes de couleurs sur l’ensemble du produit. ;
L’an dernier, nous avons introduit le mode sombre dans Glean (à la demande générale !). Un changement majeur : disposer désormais d’un « thème » (ou « palette de couleurs ») standardisé et partagé dans tout le produit. Au lieu d’écrire des couleurs hexadécimales dans le code, nous utilisons une couleur sémantique prédéfinie, comme < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;primaryText< ; ;/span> ; ;, < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;primaryBackground< ; ;/span> ; ;, < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;secondaryText< ; ;/span> ; ;, < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;secondaryBackground< ; ;/span> ; ;, etc. Cette couche sémantique permet aux développeurs de basculer facilement entre les thèmes clair et sombre (et instantanément grâce aux variables CSS, comme présenté dans cet article de blog de Slack). ;
Du point de vue de l’accessibilité, nous veillons à ce que notre thème de couleurs soit conforme au niveau AA (ce qui signifie un ratio de luminance minimal de 4,5:1 entre le premier plan et l’arrière-plan). Une piste à explorer davantage serait d’introduire un mode à contraste élevé que les utilisateurs pourraient activer afin de rendre la couleur de premier plan (comme le texte et la couleur des bordures) plus visible sur son arrière-plan.
Adopter largement le design responsive
Pour les clients qui souhaitent utiliser Glean sur leurs appareils mobiles, nous proposons également l’application mobile Glean sur iOS et Android. Nous utilisons Capacitor pour afficher la web view, qui reflète le site web dans une fenêtre d’affichage réduite et étroite (du moins pour la plupart des appareils). Nous veillons à créer un menu et une navigation adaptés au mobile, pour une utilisation simple et réactive. ;
Sous un autre angle, utiliser un produit avec une fenêtre d’affichage plus petite revient à l’utiliser avec un niveau de zoom plus élevé (c.-à-d. en utilisant CMD + / - pour ajuster le zoom dans votre navigateur). C’est important pour l’accessibilité, car de nombreux utilisateurs (sans une vision parfaite) peuvent avoir besoin de zoomer afin de rendre le contenu, comme les petits textes, plus perceptible.
Par conséquent, nous adoptons le design responsive et nous efforçons de faire en sorte que toute nouvelle fonctionnalité fonctionne bien dans de petites fenêtres et avec des niveaux de zoom élevés. Cela garantit une perte minimale de fonctionnalités, quel que soit le zoom (la norme AA exige que les produits fonctionnent correctement jusqu’à 400 % de zoom).
Rendre la taille de police flexible
Comme mentionné ci-dessus, les clients qui n’ont pas une vision parfaite peuvent devoir zoomer ou utiliser un outil de grossissement pour consulter le web plus facilement, et ce, plus souvent sur les sites dont le texte est petit. Pour respecter ce critère, une solution courante consiste à permettre à la police de votre site de respecter la préférence du navigateur en utilisant rem. ;
Rem représente la taille de police (racine) de la page, qui utilise la taille de police par défaut (selon les préférences du navigateur). Elle peut également être ajustée manuellement en définissant la valeur de la police sur l’élément racine (c.-à-d. l’élément < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;& ;lt ;html& ;gt ; ;< ; ;/span> ; ou en utilisant < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;:root< ; ;/span> ; en CSS). Un point à garder en tête lors de l’adoption de rem : s’assurer que les conteneurs de texte n’ont pas une hauteur fixe en px, ou qu’ils utilisent aussi rem. Ainsi, le texte ne déborde pas de sa zone de conteneur lorsqu’il est agrandi.
Pour revenir à notre système de design « sémantique », nous pouvons définir de manière abstraite ces usages de polices à un niveau supérieur et les partager entre les produits. Un exemple en LESS : au lieu d’utiliser < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;font-size:16px< ; ;/span> ; ;, nous utiliserions < ;span class="text-rich-text-code" style="font-family : monospace ;"> ;font-size:@mediumFont< ; ;/span> ; et définirions < ;span class="text-rich-text-code" style="font-family : monospace ;"> ; ;@mediumFont:1rem< ; ;/span> ; ;.
Poursuivre les améliorations ;
En matière d’accessibilité, en particulier pour les entreprises à un stade plus précoce, voici ce que nous souhaitons vous laisser : ;
- Des équipes plus restreintes facilitent la communication. Alignez les équipes au plus tôt sur un même système de design afin de garantir la scalabilité
- Concevoir en pensant à l’accessibilité dès le départ est plus simple que de bricoler pour que cela fonctionne plus tard
- Un produit soigné et accessible ne se contente pas d’être esthétique : il se démarque réellement lors des échanges avec des clients potentiels
Merci de nous avoir accompagnés ! Vous avez des questions ou des demandes concernant l’accessibilité ? Contactez-nous à a11y@glean.com — et consultez notre feuille de route publique sur l’accessibilité pour découvrir ce sur quoi nous travaillons activement afin d’offrir de meilleures capacités de recherche et de découverte des connaissances au plus grand nombre.
