Vendredi est la fin de la journée. Les mauvaises nouvelles arrivent toujours vendredi en fin de journée.
Vous êtes sur le point de quitter le bureau, "dzin" une nouvelle lettre sur la prochaine réorganisation vient d'arriver par la poste.
Merci xxxx, aaaa à partir d'aujourd'hui, vous ferez rapport à zzzz
...
Et l'équipe Hugh rendra nos produits accessibles aux personnes handicapées.
Oh non! Pourquoi l'ai-je mérité? Veulent-ils que je parte? Branchez-vous sur un dur travail ingrat et essayez de corriger les erreurs des autres. C'est probablement un échec ...
C'était l'accessibilité il y a quelques années. Certaines personnes pauvres ont eu la tâche de «nettoyer» l'interface utilisateur pour essayer de la rendre accessible aux personnes handicapées.
Ce que cela signifiait vraiment était plutôt vague - probablement si vous pouviez voir l'indicateur de focus et vous déplacer dans les champs à l'aide d'onglets, avoir un texte alternatif et quelques descriptions pour les champs, il serait considéré que votre application est disponible ...
Mais soudain, les «bugs» ont commencé à se multiplier à la vitesse d'une avalanche.
Différents lecteurs d'écran et navigateurs se sont comportés de manière complètement différente.
Les utilisateurs se sont plaints que l'application ne convient pas.
Dès que l'erreur a été corrigée à un endroit, un autre est apparu à un autre.
Et, simplement changer et corriger les erreurs d'interface utilisateur a nécessité un effort titanesque.
J'étais là. J'ai survécu, mais nous n'avons pas «réussi» - techniquement, nous avons beaucoup effacé, ajouté beaucoup de descriptions aux champs, aux rôles et atteint un certain niveau de conformité, mais personne n'était content. Les utilisateurs se plaignaient toujours de ne pas pouvoir naviguer dans l'application. Le directeur se plaignait toujours d'un flux constant d'erreurs. Les ingénieurs se sont plaints de la formulation incorrecte du problème, sans une «bonne» solution clairement définie qui fonctionnerait dans tous les cas.
Sur ma façon de comprendre l'accessibilité, des moments franchement francs se sont produits.
Le premier était peut-être la compréhension qu'il était difficile d'ajouter des fonctionnalités d'accessibilité au-dessus du produit fini. Et c’est encore plus difficile de convaincre les managers que c’est incroyablement difficile! Non, ce n'est pas seulement "ajouter des balises" et l'interface utilisateur fonctionnera très bien. Non, il est impossible de terminer en trois semaines, même trois mois ne suffiront pas.
Mon prochain moment de vérité est venu quand j'ai vu de première main comment les utilisateurs aveugles utilisent réellement notre application. C'est tellement différent de l'affichage des messages d'erreur.
J'y reviendrai encore et encore, mais presque toutes nos «hypothèses» sur la façon dont les gens ont utilisé notre application étaient erronées.
Naviguer à travers une interface utilisateur complexe en utilisant les
Tab/Shift+Tab nul! Besoin de quelque chose de mieux. Raccourcis clavier, en-têtes.
La perte de concentration lors du changement de l'interface utilisateur n'est-ce pas un gros problème? Détrompez-vous - c'est incroyablement déroutant.
J'ai continué, travaillé sur divers projets pendant un certain temps, puis nous avons commencé un nouveau projet, avec une interface utilisateur complexe et une installation claire, pour enfin obtenir la bonne accessibilité cette fois.
Donc, nous avons pris du recul et regardé comment nous pouvons l'implémenter différemment et réussir, et pour que le processus de travail lui-même ne soit pas ennuyeux!
Assez rapidement, nous sommes arrivés à quelques conclusions:
- Nous ne voulions pas que les personnes développant l'interface utilisateur s'embarrassent des étiquettes / rôles aria et, naturellement, de la structure HTML des composants. Nous devions leur fournir les bons composants, dans lesquels l'accessibilité est mise en œuvre dès le départ.
- Disponibilité == Facilité d'utilisation - c.-à-d. ce n'est pas seulement une tâche technique. Nous devions modifier l'ensemble du processus de conception et nous assurer que l'accessibilité est prise en compte et discutée avant de concevoir l'interface utilisateur. Il est nécessaire de réfléchir dans un premier temps à la manière dont les utilisateurs peuvent trouver une fonctionnalité, comment ils se déplaceront et comment le «clic droit» de la souris fonctionnera à partir du clavier. L'accessibilité devrait faire partie intégrante du processus de conception - pour certains utilisateurs, c'est bien plus que l'apparence de l'application.
- Dès le début, nous voulions recevoir les commentaires des aveugles et autres utilisateurs handicapés sur la facilité d'utilisation de l'application.
- Nous avions besoin de très bons moyens pour détecter la régression de l'accessibilité.
Eh bien, d'un point de vue technique, la première partie semblait assez amusante - le développement de l'architecture et la mise en œuvre d'une bibliothèque de composants. Et en effet ça l'était.
En prenant du recul, en examinant les
exemples ARIA et en le considérant comme un problème de conception, plutôt que comme un problème «d'adaptation», nous avons introduit quelques abstractions. Le composant a une «structure» (composée d'éléments HTML) et un «comportement» (comment il interagit avec l'utilisateur). Par exemple, dans les extraits ci-dessous, nous avons une liste simple non ordonnée. Lors de l'ajout de «comportement» à la liste, les rôles appropriés sont ajoutés afin qu'il agisse comme une liste. De même, nous le faisons pour le menu.
En fait, non seulement les rôles sont ajoutés ici, mais également les gestionnaires d'événements pour la navigation au clavier.
Ça a déjà l'air plus soigné. Si nous pouvions obtenir une séparation nette entre eux, peu importe la façon dont la structure a été créée, nous pourrions lui appliquer des comportements et obtenir la bonne accessibilité.
En action, cela peut être vu sur
https://stardust-ui.imtqy.com/react/ - la bibliothèque
React UX, qui est conçue et implémentée en tenant compte de l'accessibilité dès le début.
La deuxième partie - le changement d'approche et de processus autour de la conception m'a d'abord effrayé: des ingénieurs modestes essayant de pousser les changements organisationnels ne se sont pas toujours bien terminés, mais cela s'est avéré être l'un des domaines les plus intéressants où nous avons apporté une contribution significative au processus. En bref, nous avons eu le processus suivant: la nouvelle fonctionnalité a été développée par une équipe, après quoi notre groupe de managers a analysé / itéré cette proposition, puis, après approbation, en règle générale, la conception a été transférée à l'équipe d'ingénieurs. Dans ce cas, l'équipe d'ingénierie a en fait «possédé» la fonctionnalité de disponibilité, car elle devrait éliminer tous les problèmes qui lui sont associés.
Au début, c'était un travail assez difficile - expliquer que l'accessibilité et la convivialité sont inextricablement liées et que cela doit être fait au stade de la conception, sinon cela entraînerait de grands changements et des redéfinitions de certains rôles. Cependant, avec le soutien de la direction et des principaux acteurs, nous avons avancé cette idée et l'avons mise en œuvre afin que les conceptions passent le test d'accessibilité et de convivialité avant d'être présentées à la direction.
Et ces examens ont été extrêmement précieux pour tout le monde - c'était fantastique, comme un exercice de partage de connaissances / transmission d'informations sur la façon dont les utilisateurs interagissent avec les applications Web, nous avons identifié de nombreux problèmes de l'interface utilisateur avant leur construction, l'équipe de développement de ont actuellement de bien meilleures spécifications non seulement visuelles, mais aussi des aspects comportementaux de la conception. Les vraies discussions sont des discussions amusantes, énergiques et passionnées sur les aspects techniques et les interactions.
Nous pourrions rendre ce travail encore meilleur si lors de ces réunions (ou suivantes) avec nous il y avait des utilisateurs aveugles et des utilisateurs handicapés - c'était difficile à organiser, mais maintenant nous travaillons vraiment avec les organisations locales d'aveugles et avec les entreprises qui fournissent des tests externes pour vérifier le flux de travail dans les premiers stades de développement - à la fois au niveau des composants et au niveau du flux de travail.
Les ingénieurs ont maintenant des spécifications assez détaillées, des composants disponibles qu'ils peuvent utiliser pour l'implémentation et un moyen de vérifier le flux d'exécution. L'expérience nous a en partie appris ce que nous manquions constamment - comment pouvons-nous arrêter la régression. De même, les gens peuvent utiliser des tests d'intégration ou de bout en bout pour tester les fonctionnalités dont nous avons besoin pour détecter les changements dans les interactions et les threads - visuels et comportementaux.
La définition de la régression visuelle est une tâche assez précise; très peu de choses peuvent être ajoutées à ce processus, sauf peut-être pour vérifier si le focus est visible lors de la navigation à l'aide du clavier. Plus intéressantes sont deux technologies relativement nouvelles pour travailler avec l'accessibilité.
- Accessibility Insights est un ensemble d'outils qui peuvent être exécutés à la fois dans le navigateur et dans le cycle de génération / test pour identifier les problèmes.
- Vérifier le bon fonctionnement des lecteurs d'écran était une tâche particulièrement difficile. Avec l'introduction de l'accessibilité au DOM d'accessibilité , nous avons finalement eu l'occasion de prendre des instantanés de l'application en termes d'accessibilité, très similaires à la façon dont nous les faisons pour les tests visuels, et de les vérifier pour la régression.
Ainsi, dans la deuxième partie de l'histoire - nous sommes passés de l'édition de code HTML à un niveau d'abstraction plus élevé, avons changé le processus de développement de la conception et introduit des tests rigoureux. De nouveaux processus, de nouvelles technologies et de nouveaux niveaux d'abstraction ont complètement changé l'idée d'accessibilité et ce que cela signifie de travailler dans ce domaine.
Mais ce n'est que le début.
La prochaine «compréhension» est que les utilisateurs aveugles font la promotion des technologies de pointe - ce sont eux qui tirent le plus grand profit non seulement des changements que nous avons décrits plus haut, mais aussi du fait que de nouvelles approches et idées sont rendues possibles grâce à ML / AI. Par exemple, la technologie Immersive Reader permet aux utilisateurs de présenter plus facilement et plus facilement du texte. Il peut être lu à haute voix, la structure de la phrase est séparée grammaticalement, et même la signification des mots est affichée graphiquement. Cela ne correspond absolument pas à l'ancienne conception de «rendre disponible» - c'est une fonctionnalité d'utilisation qui aidera tout le monde.
Avec ML / AI, de nouvelles façons d'interagir et de travailler font leur apparition, et nous sommes heureux de faire partie des prochaines étapes de ce chemin avancé. L'innovation est entraînée par un changement de pensée - l'humanité existe depuis des millénaires, les voitures depuis des centaines d'années, les sites Web depuis plusieurs décennies et les smartphones sont encore plus petits, la technologie doit s'adapter aux gens, et non l'inverse.
PS L'article a été traduit avec quelques écarts par rapport à l'original. En tant que co-auteur de cet article, j'ai convenu de ces digressions avec Hugh.