Catégories
Plugin et site web

Traduire des wireframes de conception en HTML / CSS accessible – Smashing Magazine

A propos de l'auteur

Harris est un développeur Web passionné par l'égalité numérique. Il travaille chez Deque Systems en tant qu'ingénieur principal de l'interface utilisateur, créant de superbes applications Web. …
Plus à propos
Harris

Le moyen le plus efficace de créer des sites Web et des applications accessibles est de «passer à gauche» en intégrant des tests d'accessibilité aux premières étapes de votre processus de développement et de conception. Dans cet article, Harris vous guidera à travers le processus d'analyse d'un wireframe du point de vue de l'accessibilité et de prise de décisions de codage pour optimiser l'accessibilité dans les phases de conception et de développement.

Trop souvent, l’accessibilité ne traverse pas l’esprit des concepteurs lors de la création d’interfaces utilisateur. Le fait de négliger les considérations d'accessibilité lors de la phase de conception peut se répercuter sur votre site Web ou votre application et avoir un impact important sur vos utilisateurs. Qu'il s'agisse de tests d'utilisabilité, de création de prototypes, d'adoption d'une bibliothèque de modèles accessible ou même simplement d'annotation de wireframes, les concepteurs doivent intégrer l'accessibilité dans leur flux de travail. Au lieu de surcharger les ingénieurs d'assurance qualité pour trouver des défauts d'accessibilité, penser à l'accessibilité dès le départ ou «passer à gauche» peut avoir un impact extrêmement positif sur le contenu que vous créez.

Déplacement vers la gauche

Il existe de nombreuses études qui montrent l'évolution du coût de la correction des défauts à différentes étapes du processus de développement. Sur la base du coût de la correction d'un défaut au stade de la conception comme ayant un facteur de 1x, ces études montrent des différences de coût qui augmentent jusqu'à 6x pendant la mise en œuvre, 15x pendant les tests après la validation du code, et aussi élevées que 100x si elles sont détectées après le défaut. en production. Une recherche du NIST estime que les coûts de correction des défauts sont 10x pendant les tests d'intégration et 15x pendant les tests système, mais seulement 30x en production. (^ 2) Quels que soient les coûts réels de votre organisation, une chose est sûre: détecter les défauts de conception et la phase de développement est d'un ordre de grandeur moins coûteuse que plus tard dans le processus.

Deque a rassemblé les données de 20 ans de tests d'accessibilité. Sur la base de nos données, une tendance que nous avons observée au cours des cinq dernières années, alors que les applications Web ont gagné en complexité, est que le nombre de défauts par page augmente régulièrement pour atteindre entre 30 et 50 défauts par page. Ces nombres de défauts éclipsent souvent les taux de défauts fonctionnels et amplifient la valeur du décalage des tests d'accessibilité et de la correction aussi loin que possible du processus.

Environ 70% des défauts d'accessibilité peuvent être évités grâce à la combinaison appropriée de tests automatisés et guidés pendant le processus de conception et de développement.

Cet article vise à vous donner un aperçu de la façon dont cela peut être réalisé.

La phase de conception

Annotations

Les annotations sont des explications textuelles ou graphiques ajoutées à une conception pour informer l'implémenteur de l'intention. Semblable à un concepteur annotant des éléments tels que la couleur et la taille de la police, les informations d'accessibilité doivent également être transmises dans les conceptions. Plongeons-nous dans un simple widget de lecteur audio et évaluons les types d'annotations dont nous aurons besoin.

Notre lecteur audio sera composé de trois commandes:

  1. Un contrôle pour aller à la piste précédente (le cas échéant)
  2. Un contrôle pour lire et mettre en pause la piste audio en cours de lecture
  3. Un contrôle pour passer à la piste suivante (le cas échéant)
Le lecteur audio contrôle la conception avec des annotations de nom et de rôle
(Grand aperçu)

Nom, rôle et état

Le nom accessible d'un composant dictera de quoi un utilisateur de technologie d'assistance sera informé lorsqu'il interagira avec lui. Il est très important d'annoter chacune de nos commandes de lecteur audio car, visuellement, elles sont représentées avec une iconographie seule et sans contenu textuel. Cela signifie que nous annoterons les 3 commandes avec les noms accessibles de «Piste précédente», «Pause» et «Piste suivante».

Ensuite, nous voulons réfléchir à la objectif de chacun de ces 3 contrôles. Puisqu'il s'agit d'éléments cliquables qui exécutent des actions de lecteur audio, le choix évident du rôle ici est «bouton». Ce n'est pas quelque chose qui devrait être assumé lors de la conception, mais plutôt quelque chose que les concepteurs doivent annoter pour s'assurer que les implémenteurs ajoutent ces informations sémantiques aux contrôles. Le fait d'avoir les rôles mappés dès le début vous évitera d'avoir à revenir en arrière et à les ajouter aux contrôles une fois que l'implémentation a déjà eu lieu.

Enfin, tout comme les concepteurs cartographient l'apparence d'un contrôle lorsqu'il est survolé, ils doivent penser aux différents états de leur widget en termes d'accessibilité. Dans le cas de notre lecteur audio, nous avons en fait pas mal d'états à annoter pour l'implémenteur. En commençant par le bouton «Piste précédente», nous savons qu'il doit être désactivé lorsqu'il n'y a pas de piste précédente à lire. Le bouton lecture / pause doit faire basculer le lecteur audio entre les états de lecture et de pause. Cela signifie que nous devons annoter que le nom accessible doit correspondre à cet état. Le nom accessible du bouton doit être "Pause" lorsque l'audio est en cours de lecture et "Lecture" lorsque l'audio est en pause. Pour le bouton «Piste suivante», nous devons annoter le fait qu'il doit être désactivé lorsqu'il n'y a pas de piste suivante. Enfin, les états de survol et de mise au point de chacun des boutons doivent être annotés afin que les utilisateurs du clavier aient une indication visuelle de la commande actuellement focalisée dans le lecteur audio.

Bouton Pause avec annotations sur l'état du focus
(Grand aperçu)

Interaction pour l'ensemble du composant

Lorsque vous êtes sur la première piste: désactivez le bouton "Piste précédente"

Quand vous êtes sur la dernière piste: désactivez le bouton "Piste suivante"

Lors de la lecture, affichez le bouton «pause» et masquez le bouton «lecture»

Lorsque vous ne jouez pas: affichez le bouton «lecture» et masquez le bouton «pause»

Après avoir cliqué sur "lecture", placez le focus sur le bouton "pause"

Après avoir cliqué sur «Pause», mettez le focus sur le bouton «Lecture»

Tests d'utilisation

Les tests d'utilisabilité, une méthodologie de recherche UX dans laquelle un chercheur demande à un utilisateur d'effectuer une série de tâches et d'analyser son comportement, est une étape très importante de la phase de conception. Les informations recueillies à partir des tests d'utilisabilité sont essentielles pour façonner les expériences des utilisateurs numériques. Effectuer ces tests avec des utilisateurs handicapés est extrêmement important car cela permet à votre équipe d'avoir une idée de la facilité avec laquelle ces utilisateurs pourront interagir avec le contenu qu'ils créent. Si vous effectuez des tests d'utilisabilité sur un système existant, vous pourrez mettre en place un scénario très réaliste pour le participant, ce qui est excellent pour les utilisateurs qui s'appuient sur diverses technologies d'assistance.

Si vous effectuez des tests d'utilisabilité sur un système inexistant, soyez prêt à faire face aux défis d'accessibilité liés à la sortie du logiciel de conception. Les prototypes interactifs issus de ces outils sont souvent extrêmement différents de ce que sera le produit final dans un navigateur ou sur une plate-forme OS. De plus, ces «prototypes fonctionnels» sont généralement extrêmement inaccessibles. Si possible, trouvez une alternative proche dans la nature que vous pouvez utiliser à la place de votre prototype, ce qui peut vous donner une bonne idée de la façon dont vos participants vont interagir avec votre système. Par exemple, si vous créez un nouveau composant de navigation mobile, recherchez-en un existant sur Internet et effectuez des tests d'utilisabilité avec. Déterminez ce qui a fonctionné dans cette alternative et apprenez ce qui doit être amélioré. Quoi qu'il en soit, soyez toujours prêt à faire des adaptations pour vos participants aux tests d'utilisabilité en fonction de leurs handicaps. Veiller à ce que les tests se déroulent sans aucun obstacle ne rendra non seulement vos participants heureux, mais vous permettra également de passer plus de tests en moins de temps.

Bibliothèques de motifs

Les bibliothèques de modèles sont des collections de composants d'interface utilisateur et sont extrêmement utiles dans les phases de conception et de développement. Le fait d'avoir un ensemble suffisant de composants d'interface utilisateur à portée de main facilite grandement la création d'applications entièrement fonctionnelles. Pour le concepteur, ces composants aident à conserver une belle cohérence dans votre application, ce qui améliore l'expérience globale de vos utilisateurs. Pour le développeur, disposer de composants entièrement testés, accessibles et réutilisables permet de produire rapidement un contenu de haute qualité. Ces composants doivent être traités avec un soin particulier en termes d'accessibilité car ils seront vraisemblablement utilisés plusieurs fois dans votre ou vos applications.

Travail Avec les développeurs

Parlant avec d'autres développeurs et designers lors de conférences et de rencontres, j'entends souvent parler d'équipes divisées dans lesquelles les concepteurs et les développeurs travaillent de manière totalement isolée les uns des autres. Non seulement les développeurs devraient être inclus dans la phase de conception dans des choses comme les réunions de revue de conception, mais les concepteurs devraient également être inclus dans la phase de développement.

La collaboration est essentielle pour créer un contenu accessible impressionnant.

Souvent, les développeurs sont au courant des détails d'implémentation qui peuvent aider à façonner des compositions de conception ou même à faire pivoter une approche pour résoudre un problème de conception. De même, les concepteurs peuvent aider à garder les développeurs sous contrôle lorsqu'il s'agit de mettre en œuvre leurs conceptions de manière accessible, car les aspects axés sur les détails tels que l'espacement et l'utilisation de couleurs spécifiques peuvent avoir un impact énorme sur l'accessibilité. Pendant que les développeurs mettent en œuvre un design, les concepteurs doivent porter une attention particulière à des éléments tels que l'indication de la mise au point, l'ordre des tabulations, l'ordre de lecture, les polices, les couleurs et même les noms accessibles et les textes alternatifs des images. Parce qu'après tout, à quoi servent toutes ces incroyables annotations spécifiques à l'accessibilité si le développeur les ignore?

La phase de développement

Automatisez les tests d'accessibilité

Nous, les développeurs, aimons l'idée que certains éléments de nos flux de travail peuvent être complètement automatisés. Heureusement, il existe de nombreuses bibliothèques d'automatisation d'accessibilité étonnantes, que votre équipe devrait exploiter pour aider à créer des interfaces accessibles durables. Les outils d'analyse statique tels que eslint-plugin-jsx-a11y peuvent fournir un retour immédiat aux développeurs pour les avertir des problèmes d'accessibilité potentiels pendant le codage. Les développeurs peuvent même configurer leur éditeur de texte pour afficher ces avertissements au fur et à mesure qu'ils tapent le code, en détectant ces défauts en direct lorsqu'ils apparaissent.

Les moteurs de règles d'accessibilité, tels que ax-core, peuvent être intégrés dans presque n'importe quel cadre ou environnement et peuvent aider à résoudre de nombreux problèmes d'accessibilité extrêmement courants. Un excellent moyen de vous assurer que toute votre équipe crée du contenu accessible est d'intégrer ces types d'outils dans vos pipelines CI (intégration continue) et CD (livraison continue). L'écriture de cas de test spécifiques à l'accessibilité (unitaires ou de bout en bout) est une autre excellente forme d'automatisation. Dans mon équipe, nous avons tous les éléments ci-dessus configurés afin qu'aucune demande d'extraction ne puisse même être fusionnée jusqu'à ce que tous nos tests d'automatisation d'accessibilité aient réussi. Cela signifie que nous pouvons garantir des défauts d'accessibilité minimes, même arriver à nos serveurs de développement et ne pas réussir à entrer en production.

Gérez systématiquement les défauts d'accessibilité

Les problèmes d'accessibilité ne doivent pas être traités différemment des défauts de sécurité ou de fonctionnalité. Ils devraient être triés et hiérarchisés régulièrement avec le reste de la charge de travail «normale». La mesure des progrès et la collecte de mesures spécifiques aux défauts d'accessibilité peuvent également être utiles, en particulier si votre équipe commence tout juste à accélérer l'accessibilité. Cela peut également aider à identifier les points faibles ou les goulots d'étranglement de votre système. Si votre équipe participe à des rétrospectives de sprint (ou quelque chose de similaire), l'accessibilité devrait être un sujet de discussion. Réfléchir à ce qui fonctionne et à ce qui ne fonctionne pas est un exercice sain et peut conduire à des améliorations dans l’approche globale de votre équipe en matière d’accessibilité durable.

Cet outil Beta Cool Axe

Nous avons parlé de l'automatisation de l'accessibilité, qui est un excellent point de départ pour les tests. Cependant, inévitablement, un humain doit reprendre là où les robots s'arrêtent pour obtenir une couverture complète des tests d'accessibilité. Les tests manuels nécessitent une compréhension approfondie de l'accessibilité ainsi que des directives d'accessibilité du contenu Web du W3C, ou «WCAG». L'application ax Beta vous aide à réaliser ces tests manuels sans avoir à être un expert en accessibilité. Il dispose d'une large gamme de tests guidés intelligents, qui posent des questions extrêmement simples et font tous les gros travaux pour vous!

Étant donné que nous nous efforçons toujours de tout automatiser, on pourrait réagir avec scepticisme à l'affirmation selon laquelle les tests d'accessibilité ne peuvent pas être entièrement automatisés et nécessitent un cerveau humain pour couvrir toutes les bases. Cependant, prenons des images à titre d'exemple et quelles informations, le cas échéant, elles fournissent dans le contexte d'une page Web. Une bibliothèque d'automatisation de l'accessibilité ne peut pas dériver d'intention d'information en numérisant ou en traitant une image. Même si nous alimentons une image d'un algorithme d'apprentissage automatique et qu'il peut cracher une description parfaite de ce qu'il y a dans cette image, il ne sait pas ce que cette image transmet dans le contexte de la page. Les informations véhiculées par une image donnée, ou si cette image est utilisée uniquement comme décoration, dépendent entièrement de l'auteur du contenu.

Lier tout ensemble

Avoir l'accessibilité à l'esprit dès le début du développement rend la création de contenu accessible beaucoup plus facile que de prendre ces considérations à la fin du cycle de vie du développement logiciel. L'intégration de l'accessibilité dans l'idéation, la conception et la mise en œuvre de votre logiciel crée un produit plus durable.

Préparez votre équipe au succès en utilisant des ressources telles que WCAG, ARIA, ARIA Authoring Practices et Stack Overflow. Empêchez les défauts d'accessibilité de se retrouver dans votre logiciel en tirant parti des bibliothèques d'automatisation d'accessibilité et en les intégrant dans vos serveurs d'intégration continue. Notre équipe a travaillé dur pour combler l'écart entre les tests automatisés et manuels, nous serions ravis que vous essayiez ax Beta! Si les défauts d'accessibilité sont traités systématiquement, non seulement vous pouvez débarrasser vos applications de ces problèmes, mais vous pouvez également les empêcher de retrouver leur chemin à l'avenir.


Voulez-vous me rejoindre dans un atelier gratuit sur ce sujet précis? Inscrivez-vous à notre prochain atelier virtuel sur la traduction de wireframes de conception qui sera divisé en deux sessions de 3 heures.

Éditorial fracassant(rail)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *