L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Traduire des wireframes de conception en HTML / CSS accessible
Trop souvent, l'accessibilité ne traverse pas l'esprit d'un concepteur lorsque créer des 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 «déplacer vers la gauche» peut avoir un impact extrêmement positif sur le contenu que vous créez.
Shifting Left
De nombreuses études montrent que les changements dans le 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 à 6x lors de la mise en œuvre, 15x lors des tests après validation du code, et aussi élevées que 100x si attrapé après que le défaut est entré 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 certaine: détecter les défauts lors de la phase de conception et de développement est beaucoup moins coûteux que plus tard dans le processus.
Deque a rassemblé des données issues 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.
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 le réalisateur 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 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:
- Une commande pour aller à la piste précédente (le cas échéant)
- Une commande pour lire et mettre en pause la piste audio en cours de lecture
- Une commande pour passer à la piste suivante (le cas échéant)
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 à l'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 supposé 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 déterminent comment un contrôle apparaît lorsqu'il est survolé, ils doivent être 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.
Interaction pour l'ensemble du composant
Sur la première piste: désactiver le bouton «Piste précédente»
Sur la dernière piste: désactiver le bouton «Piste suivante»
Lors de la lecture, afficher la «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 », mettez le focus sur le bouton« pause »
Après en cliquant sur «pause», placez le focus sur le bouton «play»
Test d'utilisabilité
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 dans 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 ce test 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 utilisent 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 blocage ne rendra non seulement vos participants heureux, mais vous permettra également de passer plus de tests en moins de temps.
Bibliothèques de modèles
Les bibliothèques de modèles sont des collections de composants d'interface utilisateur et sont extrêmement bénéfiques dans les phases de conception et de développement. Avoir un ensemble suffisant de composants d'interface utilisateur à portée de main facilite 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 de nombreuses fois dans votre ou vos applications.
Travail Avec les développeurs
Parler avec d'autres développeurs et concepteurs à des conférences et des 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 révision 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 le sont. connaître les détails de mise en œuvre qui peuvent aider à façonner les 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 une conception, 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 étonnantes annotations spécifiques à l'accessibilité si le développeur les ignore?
La phase de développement
Automatiser les tests d'accessibilité
Nous, les développeurs, aimons l'idée que certaines choses de nos flux de travail peuvent être complètement automatisé. Heureusement, il existe de nombreuses bibliothèques d'automatisation d'accessibilité incroyables, 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 une rétroaction immédiate aux développeurs pour les avertir de 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 saisissent le code, 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 peut 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 un minimum de défauts d’accessibilité, même atteindre nos serveurs de développement, et nous ne parviendrons certainement pas à le mettre en production.
Gérer 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 Cool ax Beta
Nous avons parlé de l'automatisation de l'accessibilité, ce qui est un excellent point de départ des 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 hache Beta vous aide à réaliser ce test manuel sans avoir à être un expert en accessibilité. Il dispose d'une grande suite 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 d'automatiser tout, on pourrait réagir avec scepticisme à l'affirmation que les tests d'accessibilité ne peuvent pas être entièrement automatisé et nécessite un cerveau humain pour couvrir toutes les bases. Cependant, prenons les 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 d'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 qui est dans cette image, il ne sait pas ce que cette image véhicule dans le contexte de la page. L'information qu'une image donnée transmet, ou si cette image est utilisée uniquement comme décoration, dépend entièrement de l'auteur du contenu.
Tying It All Together
Garder l'accessibilité à l'esprit dès le début du développement rend la création accessible contenu 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 de l'accessibilité et en les intégrant dans vos serveurs d'intégration continue. Notre équipe a travaillé dur pour combler le fossé entre les tests automatisés et manuels, nous serions ravis que vous essayez 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 aussi 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 de traduction de wireframes de conception qui sera divisé en deux sessions de 3 heures.
(ra, il)
Source link