Le vendredi est la fin de la journée de travail. Les mauvaises nouvelles arrivent toujours le vendredi en fin de journée de travail.
Vous êtes sur le point de quitter le bureau, une nouvelle lettre concernant une autre réorganisation vient d'arriver par la poste.
Merci xxxx, yyy à partir d'aujourd'hui vous signalerez zzzz
...
Et l'équipe de Hugh veillera à ce que nos produits soient accessibles aux personnes handicapées.
Oh non! Pourquoi est-ce que je méritais ça ? Veulent-ils que je parte ? Préparez-vous à un travail acharné et ingrat et essayez de corriger les erreurs des autres. C'est définitivement un échec...
C'était la disponibilité il y a quelques années. Quelques pauvres âmes se sont vu confier la tâche de « faire le ménage » dans l'assurance-chômage pour tenter de la rendre accessible aux personnes handicapées.
Ce que cela signifiait réellement était assez vague - probablement si vous pouviez voir un indicateur de focus et un onglet dans les champs, avoir du texte alternatif et quelques descriptions de champs, on considérerait que votre application est accessible...
Mais soudain, les « bugs » ont commencé à se multiplier à la vitesse d’une avalanche.
Divers lecteurs d'écran (Ing. Lecteurs d'écran) et les navigateurs se comportaient complètement différemment.
Les utilisateurs se sont plaints du fait que l'application était inutilisable.
Dès qu’une erreur était corrigée à un endroit, une autre apparaissait à un autre.
Et le simple fait de changer et de corriger les erreurs de l’interface utilisateur a nécessité des efforts herculéens.
J'étais là. J'ai survécu, mais nous n'avons pas "réussi" - techniquement, nous avons beaucoup nettoyé, ajouté beaucoup de descriptions de champs, de 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 manager se plaignait toujours du flux constant d'erreurs. Les ingénieurs se sont plaints du fait que le problème était mal posé, sans solution « correcte » clairement définie qui fonctionnerait dans tous les cas.
Il y a eu des moments résolument révélateurs tout au long de mon parcours vers la compréhension de l’accessibilité.
La première a peut-être été la prise de conscience de la difficulté d’ajouter des fonctionnalités d’accessibilité à un produit fini. Et il est encore plus difficile de convaincre les managers que c’est incroyablement difficile ! Non, il ne suffit pas d'"ajouter quelques balises" et l'interface utilisateur fonctionnera très bien. Non, cela ne peut pas être réalisé en trois semaines ; même trois mois ne suffiront pas.
Mon moment de vérité suivant est survenu lorsque j’ai pu constater par moi-même comment les utilisateurs aveugles utilisaient réellement notre application. C'est TELLEMENT différent de regarder les messages d'erreur.
J'y reviendrai encore et encore, mais presque toutes nos « hypothèses » sur la façon dont les gens utilisaient notre application étaient fausses.
Naviguer dans une interface utilisateur complexe à l'aide de touches Tab/Shift+Tab – c'est nul ! Nous avons besoin de quelque chose de mieux. Raccourcis clavier, en-têtes.
Perdre la concentration lors du changement de l'interface utilisateur n'est pas un gros problème, n'est-ce pas ? Réfléchissons-y à nouveau : c'est incroyablement déroutant.
J'ai continué, travaillé sur différents projets pendant un moment, puis nous avons démarré un nouveau projet, avec une interface utilisateur complexe et une installation claire, pour enfin obtenir une bonne accessibilité cette fois-ci.
Nous avons donc pris du recul et examiné comment nous pourrions mettre cela en œuvre différemment et réussir, et rendre le processus moins ennuyeux !
Assez rapidement, nous sommes arrivés à quelques conclusions :
- Nous ne voulions pas que les développeurs de l'interface utilisateur se mêlent des étiquettes/rôles d'Aria et, bien sûr, de la structure HTML des composants. Nous devions leur fournir les bons composants pour créer une accessibilité dès le départ.
- Accessibilité == Facilité d'utilisation – c'est-à-dire Il ne s’agit pas seulement d’un défi technique. Nous devions modifier l’ensemble du processus de conception et garantir que l’accessibilité était prise en compte et discutée avant le début de la conception de l’interface utilisateur. Vous devez réfléchir dès le début à la manière dont les utilisateurs découvriront les fonctionnalités, à la manière dont ils navigueront et à la manière dont fonctionnera le clic droit sur le clavier. L'accessibilité doit faire partie intégrante du processus de conception. Pour certains utilisateurs, elle représente bien plus que la simple apparence de l'application.
- Dès le début, nous avons souhaité recueillir les commentaires des utilisateurs aveugles et handicapés sur la facilité d'utilisation de l'application.
- Nous avions besoin de très bons moyens pour détecter les régressions en matière d'accessibilité.
Eh bien, d'un point de vue technique, la première partie semblait assez amusante : développer une architecture et implémenter une bibliothèque de composants. Et c’était effectivement le cas.
Prendre du recul, regarder et en considérant cela comme un problème de conception plutôt que comme un problème d'intégration, nous avons introduit quelques abstractions. Un composant a une « Structure » (constitué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 des « comportements », les rôles correspondants sont ajoutés à la liste pour la faire agir comme une liste. Nous faisons de même 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.
Cela a l'air plus soigné. Si nous pouvions obtenir une séparation nette entre eux, la manière dont la structure a été créée n'aurait pas d'importance, nous pourrions lui appliquer des comportements et obtenir une bonne accessibilité.
Vous pouvez voir cela en action sur – Bibliothèque UX , qui est conçu et mis en œuvre dès le départ en gardant à l’esprit l’accessibilité.
La deuxième partie - changer l'approche et les processus autour de la conception m'a d'abord fait peur : les ingénieurs modestes qui tentent de faire avancer le changement organisationnel ne se terminent pas toujours bien, mais cela s'est avéré être l'un des domaines les plus intéressants dans lequel nous avons apporté une contribution significative au processus. . En un mot, notre processus était le suivant : la nouvelle fonctionnalité serait développée par une équipe, puis notre équipe de direction examinerait/itérerait la proposition, puis, une fois approuvée, la conception serait généralement transmise à l'équipe d'ingénierie. Dans ce cas, l’équipe d’ingénierie « possédait » effectivement la fonctionnalité d’accessibilité, car il lui incombait de résoudre tous les problèmes qui y étaient associés.
Au début, il était assez difficile d’expliquer que l’accessibilité et la convivialité sont inextricablement liées et que cela devait être fait dès la phase de 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 acteurs clés, nous avons repris l'idée et l'avons mise en œuvre afin que les conceptions soient testées en termes d'accessibilité et d'utilisabilité avant d'être présentées à la direction.
Et ces commentaires ont été extrêmement précieux pour tout le monde : c'était fantastique en tant qu'exercice de partage de connaissances/de communication sur la façon dont les utilisateurs interagissent avec les applications Web, nous avons identifié de nombreux domaines problématiques de l'interface utilisateur avant leur création, les équipes de développement ont désormais de bien meilleures spécifications en matière de non-conformité. seulement les aspects visuels, mais aussi comportementaux du design. Les vraies discussions sont des discussions amusantes, énergiques et passionnées sur les aspects techniques et les interactions.
Nous pourrions faire cela encore mieux si nous avions des utilisateurs aveugles et handicapés à ces réunions (ou ultérieures) - cela était difficile à organiser, mais nous travaillons maintenant avec des organisations et des entreprises aveugles locales, qui fournissent des tests externes pour vérifier le flux d'exécution dès le début. développement, à la fois au niveau des composants et du flux d’exécution.
Les ingénieurs disposent désormais de spécifications assez détaillées, de composants disponibles qu'ils peuvent utiliser pour implémenter et d'un moyen de valider le flux d'exécution. Une partie de ce que l’expérience nous a appris concerne ce qui nous a manqué depuis le début : comment arrêter la régression. De même, les utilisateurs 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 flux d'exécution, à la fois visuels et comportementaux.
La détermination de la régression visuelle est une tâche assez définie, il y a très peu de choses à ajouter au processus autre que peut-être vérifier si le focus est visible lors de la navigation avec le clavier. Plus intéressantes sont deux technologies relativement nouvelles pour travailler avec l'accessibilité.
- est un ensemble d'outils qui peuvent être exécutés à la fois dans le navigateur et dans le cadre du cycle de construction/test pour identifier les problèmes.
- Vérifier que les lecteurs d'écran fonctionnent correctement a été une tâche particulièrement difficile. Avec l'introduction de l'accès à Accessibilité DOM, nous sommes enfin en mesure de prendre des instantanés d'accessibilité de l'application, un peu comme nous le faisons pour les tests visuels, et de les tester pour la régression.
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 développement de la conception et introduit des tests approfondis. Les nouveaux processus, les nouvelles technologies et les nouveaux niveaux d'abstraction ont complètement changé le paysage de l'accessibilité et ce que signifie travailler dans cet espace.
Mais ce n'est que le début.
La « compréhension » suivante est que les utilisateurs aveugles sont à l’origine d’une technologie de pointe : ce sont eux qui bénéficient le plus non seulement des changements que nous avons décrits précédemment, mais aussi du fait que de nouvelles approches et idées sont rendues possibles par le ML/IA. Par exemple, la technologie Immersive Reader permet aux utilisateurs de présenter le texte plus facilement et plus clairement. Il peut être lu à haute voix, la structure des phrases est décomposée grammaticalement et même la signification des mots est affichée graphiquement. Cela ne correspond pas du tout à l’ancienne mentalité du « rendre accessible » : c’est une fonctionnalité conviviale qui aidera tout le monde.
Le ML/AI ouvre la voie à de toutes nouvelles façons d’interagir et de travailler, et nous sommes ravis de participer aux prochaines étapes de ce voyage de pointe. L'innovation est motivée par un changement de mentalité : l'humanité existe depuis des millénaires, les machines depuis des centaines d'années, les sites Web depuis plusieurs décennies et les smartphones encore moins, la technologie doit s'adapter aux gens, et non l'inverse.
PS L'article a été traduit avec des écarts mineurs par rapport à l'original. En tant que co-auteur de cet article, je suis d'accord avec Hugh sur ces digressions.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Faites-vous attention à l’accessibilité de vos applications ?
-
Oui
-
Aucun
-
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