Vendredi – la fin de la journée de travail. Les mauvaises nouvelles arrivent toujours le vendredi en fin de journée.
Vous vous apprêtez à quitter le bureau, « ding » un nouvel e-mail concernant une nouvelle réorganisation vient d'arriver dans votre boîte.
Merci xxxx, yyy à partir d'aujourd'hui vous rendrez des comptes à zzzz.
…
Et l'équipe de Hugh veillera à ce que nos produits soient accessibles aux personnes handicapées.
Oh non ! Qu'ai-je fait pour mériter cela ? Ils veulent que je parte ? Se préparer à un travail ingrat et difficile et tenter de réparer les erreurs des autres. Ce sera sûrement un échec...
C'était la situation il y a quelques années. Certains malheureux recevaient le travail de « nettoyage » de l'interface utilisateur pour essayer de la rendre accessible aux personnes handicapées.
Ce que cela signifiait réellement était plutôt flou – probablement que si vous pouviez voir l'indicateur de focus et naviguer dans les champs avec la touche tabulation, avoir un texte alternatif et quelques descriptions de champs, cela serait considéré comme un accessibilité de votre application...
Mais soudain, les « bugs » ont commencé à se multiplier à une vitesse fulgurante.
Différents lecteurs d'écran (en. Screen Readers) et navigateurs se comportaient de manière complètement différente.
Les utilisateurs se plaignaient que l'application n'était pas utilisable.
Une fois qu'une erreur était corrigée à un endroit, une autre apparaissait ailleurs.
Et simplement changer et corriger les erreurs de l'interface utilisateur nécessitait des efforts titanesques.
J'y étais. J'ai survécu, mais nous n'avons pas « réussi » – techniquement nous avons nettoyé beaucoup de choses, ajouté beaucoup de descriptions aux champs, des rôles et atteint un certain niveau de conformité aux normes, mais personne n'était satisfait. Les utilisateurs se plaignaient encore de ne pas pouvoir naviguer dans l'application. Le manager se plaignait toujours d'un flux constant d'erreurs. Les ingénieurs se plaignaient d'une mauvaise définition des tâches, sans solution « correcte » clairement définie qui fonctionnerait dans tous les cas.
Sur mon chemin pour comprendre l'accessibilité, j'ai rencontré quelques moments clairement révélateurs.
Il a peut-être d'abord été compris que l'ajout de fonctionnalités d'accessibilité à un produit existant est compliqué. Et il est encore plus difficile de convaincre les gestionnaires que c'est incroyablement complexe ! Non, ce n'est pas juste "ajouter quelques balises" et l'interface utilisateur fonctionnera parfaitement. Non, ce n'est pas possible de terminer cela en trois semaines, même trois mois seront insuffisants.
Mon prochain moment de vérité est survenu lorsque j'ai vu de mes propres yeux comment les utilisateurs aveugles utilisent réellement notre application. C'est TELLEMENT différent de la simple consultation des messages d'erreur.
Je reviendrai encore et encore sur ce point, mais presque toutes nos « hypothèses » sur la manière dont les gens utilisaient notre application étaient erronées.
Naviguer dans une interface utilisateur complexe à l'aide des touches Tab/Shift+Tab – c'est nul ! Nous avons besoin de quelque chose de mieux. Raccourcis clavier, titres.
Perdre le focus lors de la modification de l'interface utilisateur n'est pas un gros problème ? Réfléchissons encore une fois – c'est incroyablement déroutant.
J'ai continué, travaillé un certain temps sur divers projets, puis nous avons commencé un nouveau projet, avec une interface utilisateur complexe et une directive claire pour enfin obtenir cette fois-ci une accessibilité correcte.
Nous avons donc fait un pas en arrière et examiné comment nous pourrions le mettre en œuvre différemment et réussir, tout en veillant à ce que le processus de travail soit agréable !
Assez rapidement, nous avons abouti à certaines conclusions :
- Nous ne voulions pas que les personnes développant l'interface utilisateur s'embrouillent avec les annotations/roles aria et, bien sûr, avec la structure HTML des composants. Nous devions leur fournir des composants appropriés, dans lesquels l'accessibilité est intégrée dès le départ.
- Accessibilité == Utilisabilité – c'est-à-dire que ce n'est pas seulement une question technique. Nous devions changer tout le processus de conception et nous assurer que l'accessibilité soit prise en compte et discutée avant même le début de la conception de l'interface utilisateur. Il était nécessaire de réfléchir d'emblée à la manière dont les utilisateurs pourraient découvrir une fonctionnalité, comment ils navigueraient et comment le "clic droit" de la souris fonctionnerait depuis le clavier. L'accessibilité doit être une partie intégrante du processus de conception – pour certains utilisateurs, elle représente bien plus que l'apparence de l'application.
- Dès le début, nous voulions obtenir des retours d'utilisateurs aveugles et d'autres utilisateurs ayant des limitations sur la facilité d'utilisation de l'application.
- Nous avions besoin de moyens vraiment efficaces pour détecter les régressions d'accessibilité.
Eh bien, d'un point de vue technique, la première partie était assez amusante - concevoir l'architecture et mettre en œuvre la bibliothèque de composants. Et c'est vraiment ce qu'il en était.
En prenant du recul et en regardant et en considérant cela comme un problème de conception plutôt que comme un problème d'« adaptation », nous avons introduit certaines abstractions. Un 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 simple liste non ordonnée. En ajoutant le « comportement » à la liste, des rôles appropriés sont ajoutés pour qu'elle agisse comme une liste. Nous faisons de même pour les menus.
En fait, ici, non seulement des rôles sont ajoutés, mais aussi des gestionnaires d'événements pour la navigation au clavier.
Cela semble déjà plus soigné. Si nous pouvions obtenir une séparation nette entre eux, peu importe comment la structure a été créée, nous pourrions appliquer à celle-ci des comportements (Behaviours) et obtenir la bonne accessibilité.
On peut le voir en action à l'adresse – la bibliothèque UX , qui est conçue et mise en œuvre avec l'accessibilité prise en compte dès le départ.
La deuxième partie – le changement d'approche et de processus autour du design m'a initialement effrayé : de modestes ingénieurs essayant de pousser des changements organisationnels ne se terminent pas toujours bien, mais cela s'est avéré être l'un des domaines les plus intéressants où nous avons fait une contribution significative au processus. En résumé, nous avions le processus suivant : la nouvelle fonctionnalité était développée par une équipe, après quoi notre groupe de dirigeants analysait / itérait cette proposition, puis, après approbation, le design était généralement transmis à l'équipe d'ingénieurs. Dans ce cas, l'équipe d'ingénieurs « possédait » en fait la fonctionnalité d'accessibilité, car elle devait résoudre tous les problèmes qui y étaient liés.
Au départ, il s'agissait d'un travail assez difficile – expliquer que l'accessibilité et l'expérience utilisateur sont inextricablement liées et qu'il est essentiel de s'en occuper dès la phase de conception, sinon cela entraîne de grands changements et une redéfinition de certains rôles. Cependant, avec le soutien de la direction et des acteurs clés, nous avons fait passer ce message et l'avons mis en œuvre, afin que les conceptions soient vérifiées pour leur accessibilité et leur convivialité avant d'être présentées à la direction.
Et ces retours ont été extrêmement précieux pour tous – c'était fantastique, comme un exercice d'échange de connaissances / de transfert d'informations sur la manière dont les utilisateurs interagissent avec les applications web, nous identifions de nombreuses zones problématiques de l'interface utilisateur avant même qu'elles ne soient construites, les équipes de développement ont désormais des spécifications bien meilleures non seulement pour les aspects visuels mais aussi comportementaux du design. Les discussions réelles sont des débats amusants, dynamiques et passionnés sur les aspects techniques et les interactions.
Nous aurions pu améliorer ce travail encore davantage si des utilisateurs aveugles et des personnes handicapées avaient été présents lors de ces (ou des futures) réunions – cela a été difficile à organiser, mais nous collaborons désormais vraiment avec des organisations locales pour les aveugles ainsi qu'avec des entreprises qui fournissent des tests externes pour vérifier le flux d'exécution à des étapes précoces de développement – tant au niveau des composants qu'au niveau du flux d'exécution.
Maintenant, les ingénieurs disposent de spécifications assez détaillées, des composants accessibles qu'ils peuvent utiliser pour l'intégration, et d'un moyen de vérifier les flux d'exécution. En partie, l'expérience nous a appris ce que nous omettions constamment – comment pouvons-nous prévenir les régressions. De même, les gens peuvent utiliser des tests d'intégration ou de bout en bout pour vérifier les fonctionnalités dont nous avons besoin pour détecter les changements dans les interactions et les flux d'exécution – tant visuels que comportementaux.
La définition de la régression visuelle est une tâche assez précise, il y a très peu à ajouter à ce processus, sauf peut-être de vérifier si le focus est visible lors de la navigation au clavier. Deux technologies relativement nouvelles pour travailler sur l'accessibilité sont plus intéressantes.
- est un ensemble d'outils pouvant être exécutés à la fois dans le navigateur et dans le cadre du cycle de construction/test, pour identifier des problèmes.
- Vérifier le bon fonctionnement des lecteurs d'écran a été une tâche particulièrement difficile. Avec l'introduction de l'accès à Accessibility DOM, nous avons enfin eu la possibilité de faire des captures de l'application du point de vue de l'accessibilité, très similaires à ce que nous faisons pour les tests visuels, et de les vérifier pour des régressions.
Ainsi, dans la deuxième partie de l'histoire – nous sommes passés de l'édition du code HTML à un travail à un niveau d'abstraction plus élevé, avons modifié le processus de conception et mis en place des tests rigoureux. De nouveaux processus, de nouvelles technologies et de nouveaux niveaux d'abstraction ont complètement changé la perception de l'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 poussent les technologies de pointe – c'est eux qui tirent le plus grand bénéfice non seulement des changements que nous avons décrits précédemment, mais aussi du fait que de nouvelles approches et idées deviennent possibles grâce à ML/AI. Par exemple, la technologie Immersive Reader permet aux utilisateurs de mieux et plus facilement appréhender le texte. Il peut être lu à voix haute, la structure des phrases est divisée grammaticalement et même les significations des mots sont affichées graphiquement. Cela ne correspond absolument pas à l'ancienne compréhension de « le rendre accessible » – c'est une fonction d'utilisabilité qui aidera tout le monde.
Avec ML/AI, de tout nouveaux modes d'interaction et de travail apparaissent, et nous sommes ravis de faire partie des prochaines étapes de ce chemin avant-gardiste. L'innovation est conditionnée par un changement de mentalité – l'humanité existe depuis des milliers d'années, les machines depuis des centaines d'années, les sites Web depuis quelques dizaines d'années, et les smartphones encore moins, la technologie doit s'adapter aux gens, et non l'inverse.
P.S. 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 écarts avec Hugh.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Accordez-vous de l'importance à l'accessibilité de vos applications ?
Oui
Non
C'est la première fois que j'entends parler de l'accessibilité des applications.
17 utilisateurs ont voté. 5 utilisateurs se sont abstenus.
Source : habr.com
