Catégories
Astuces et Design

Penser de manière équivalente – Smashing Magazine

A propos de l'auteur

Eric est un designer basé à Boston qui aide à créer des solutions simples qui répondent aux besoins pratiques, physiques, cognitifs et émotionnels d'une personne.
Plus à propos
Eric
Bailey

Construire une expérience équivalente peut signifier changer votre façon de penser le développement et la conception, et potentiellement réévaluer votre travail existant. Dans cet article, nous aborderons les problèmes d'accessibilité courants et la meilleure façon de les améliorer pour que tout le monde puisse accéder sans effort à votre contenu.

Il s'agit du deuxième de deux articles sur le thème de l'accessibilité numérique à l'équivalence. Auparavant, nous avons découvert les biais sous-jacents qui informent la création de produits numériques, ce qui n'est pas une expérience équivalente, les effets cumulatifs d'une conception et d'un code inaccessibles et les puissantes forces de motivation pour faire mieux.

Dans cet article, je vais discuter d'apprendre à adopter un état d'esprit équivalent et inclusif. Je fournirai également des moyens pratiques et robustes d'améliorer vos sites Web et applications Web en fournissant des solutions aux obstacles courants et quotidiens cités par les personnes que j'ai interrogées.

Établir une norme

Les directives pour l'accessibilité du contenu Web (WCAG) expliquent en détail et minutieusement comment créer des expériences numériques accessibles. Bien qu'il s'agisse d'un document long et dense, il est incroyablement complet – au point où il a été codifié en tant que norme internationale. Depuis plus de 10 ans, nous avons une définition canonique mondialement acceptée de ce qui constitue utilisable.

Comment le ferais-je?

Si vous avez besoin d'un peu d'aide pour construire le cadre mental initial auquel les WCAG parviennent, une question que je me pose toujours quand je fais quelque chose est: "Comment pourrais-je l'utiliser si …" C'est une question qui vous amène à vérifier tous les biais qui pourraient être vous affectant dans le moment.

Des exemples pourraient être:

  • Comment pourrais-je l'utiliser si …
    • … je ne vois pas l'écran?
    • … Je ne peux pas bouger mes bras?
    • … je suis sensible aux animations clignotantes et stroboscopiques?
    • … L'anglais n'est pas ma langue principale?
    • … J'ai un budget limité pour la bande passante?
    • … J'ai défini une grande taille de texte par défaut?
    • …etc.

Une introduction douce

Si vous cherchez une ressource plus accessible sur la façon de creuser dans ce que les WCAG couvrent, les principes de conception inclusive seraient un excellent point de départ. Les sept principes qu'il décrit correspondent tous au critère de succès des WCAG.

Capture d'écran de la partie supérieure du site Web des principes de conception inclusive. Il comprend une illustration simple de trois ballons à air chaud flottant devant un nuage et le soleil. Il contient également le paragraphe d'introduction, «Ces principes de conception inclusive visent à faire passer les gens en premier. Il s'agit de concevoir pour les besoins des personnes souffrant de handicaps permanents, temporaires, situationnels ou changeants - nous tous vraiment. " Les contributeurs sont répertoriés comme Henny Swan, Ian Pouncey, Heydon Pickering et Léonie Watson
(Grand aperçu)

Apprenez des personnes qui l'utilisent réellement

Vous n'avez pas à me croire sur parole. Voici quelques problèmes courants cités par les personnes que j'ai interviewées et comment les résoudre:

Orientation

Rubriques

Les éléments d'en-tête sont extrêmement importants pour maintenir une expérience équivalente et accessible.

Lorsqu'ils sont construits avec compétence et soin, les éléments de titre permettent aux utilisateurs de lecteurs d'écran de déterminer rapidement le contenu d'une page ou de consulter et d'accéder à un contenu correspondant à leurs intérêts. Cela équivaut à la façon dont quelqu'un peut rapidement voltiger, défiler jusqu'à ce que quelque chose qui semble pertinent apparaisse.

Un graphique montrant comment les éléments de titre imbriqués correspondent à la mise en page d'une conception pour un site appelé SkyList. Le titre de premier niveau est "Types de nuages", qui correspond à l'élément h1 de la page. Les trois éléments d'en-tête h2 se lisent, «High», «Mid-level» et «Low». Chacune de ces rubriques est représentée dans le dessin sous forme de zone ombrée. Dans chaque zone se trouvent des conceptions de cartes, y compris un espace réservé d'image, un titre et un espace réservé de paragraphe. Les éléments d'en-tête h3 pour les cartes de section haute sont «Cirrus», «Cirrostratus» et «Cirrocumulus». Les éléments d'en-tête h3 pour les cartes de section de niveau intermédiaire sont «Altocumulus», «Altostratus» et «Nimbostratus». Les éléments d'en-tête h3 pour les cartes de section basse sont «Cumulus», «Stratus», «Cumulonimbus» et «Stratocumulus».
L'extension de navigateur HeadingsMap vous permet d'afficher la hiérarchie des en-têtes d'une page. (Grand aperçu)

Justin Yarbrough exprime des éléments de titre mal écrits comme une préoccupation, et il n'est pas seul.

L'enquête sur les lecteurs d'écran de WebAIM cite les titres comme le moyen le plus important de trouver des informations. Il convient de prêter attention à cette enquête, car elle fournit des informations précieuses sur la façon dont les personnes handicapées utilisent réellement la technologie d'assistance.

Repères

En plus des éléments de titre, une autre façon de déterminer la structure et la mise en page globales sont les repères. Les repères sont des rôles implicitement décrits par des éléments de sectionnement HTML, utilisés pour décrire la composition globale de la page principale ou des zones d'affichage.

Une disposition "Saint-Graal" montrant une ligne d'élément d'en-tête s'étendant sur trois colonnes. En dessous se trouve une autre ligne avec trois colonnes, utilisant les éléments nav, main et apart. En dessous se trouve une troisième et dernière ligne d'étirement de colonne utilisant l'élément de pied de page. Chaque élément est également étiqueté avec son repère correspondant.
Il s'agit de cinq des huit éléments HTML historiques et des rôles qui les utilisent. (Grand aperçu)

Voici ce que Justin a à dire:

"Si j'essaie simplement de trouver le contenu principal, je vais d'abord essayer le Q Touche de raccourci JAWS pour voir si un main de la région. Sinon, je suis juste plus ou moins coincé à essayer de numériser la page pour la trouver en flèches à travers la page. "

Tout comme la façon dont nous pourrions utiliser un nom de groupe de couches de «navigation principale» dans notre fichier de conception, ou un nom de classe de c-nav-primary dans notre CSS, il est important d’utiliser également un nav élément de sectionnement pour décrire notre navigation principale sur le site (ainsi que toute autre navigation contenue dans la page ou la vue).

Cela garantit que l'intention est maintenue tout au long de la conception, à la mise en œuvre et à l'utilisation. La même notion s'applique aux autres éléments de sectionnement HTML qui créent des repères pour la technologie d'assistance.

Contrôles étiquetés

Brian Moore nous parle de «champs de formulaire sans étiquette ou au moins un qui n'est pas associé par programme, donc il ne lit rien».

C’est un autre problème frustrant et commun.

Fournir un valide for/id l'appariement d'attributs crée une association programmatique entre les entrées de formulaire et l'étiquette qui décrit ce qu'il fait. Et quand je dis label, Je veux dire le label élément. Pas cliquable div, un espace réservé, aria-label, ou une autre solution fragile et / ou surmenée. label Les éléments sont une solution éprouvée qui bénéficie d'une prise en charge large et approfondie de l'accessibilité.

De plus label L'élément ne doit pas être utilisé seul, par exemple pour une étiquette sur un diagramme. Cela peut sembler contre-intuitif au premier abord, mais soyez indulgent avec moi.











Un diagramme de l'œil humain.

Les mêmes types de technologies d'assistance qui permettent à une personne d'accéder aux titres et aux repères lui permettent également de passer aux étiquettes d'entrée. Pour cette raison, on s'attend à ce que lorsqu'un label est présent, il y a aussi une entrée correspondante à laquelle il est associé.

Descriptions alternatives

Si vous avez une vision faible ou inexistante et / ou avez des difficultés à comprendre une image, l'attribut alt de HTML (et non l'attribut title) fournit un mécanisme pour comprendre à quoi sert l'image. Le même principe s'applique pour fournir des sous-titres pour le contenu vidéo et audio comme les podcasts.

Kenny Hitt mentionne que lorsque:

"… Quelqu'un publie quelque chose sur Twitter, s'il ne s'agit que d'une image sans étiquette, je ne prends même pas le temps de participer à la conversation. Lorsque vous commencez chaque conversation en demandant ce qu'il y a dans l'image, cela fait vraiment dérailler les choses. "

Jusqu'à la semaine dernière, la seule façon pour Twitter de fournir des descriptions alternatives pour ses images était d'activer une option enfouie dans la sous-section d'un menu de préférences. Comparez cela à une plate-forme comme Mastodon, où la fonctionnalité est activée par défaut.

Soren Hamby, mentionne Stitcher, une application de podcast populaire. «L’intégration était constituée de nombreux graphiques à thème, mais le texte de remplacement pour chacun d’entre eux était« non sélectionné »et pour la même image avec une vérification, il était sélectionné. Je pense qu'il serait raisonnable pour eux de dire «genre de science-fiction sélectionné» (…) c'est une si petite chose mais cela fait toute la différence. »

Veiller à ce que le contenu de description alternative soit concis et descriptif est tout aussi important que d'inclure la possibilité de l'ajouter. Daniel Göransson, développeur pour Axess Lab, a un excellent article sur la façon de les écrire efficacement.

Des fonctionnalités robustes et accessibles peuvent également faire partie des critères d'évaluation, ainsi qu'une excellente méthode pour fidéliser la clientèle. Soren mentionne qu'ils sont «souvent le facteur décisif, surtout entre les services». En particulier, ils citent les descriptions audio de Netflix.

ARIA

L’un des sujets de l’article de Daniel Göransson sur les descriptions alternatives est de ne pas trop décrire les choses. Cela inclut des informations telles que c'est une image, qui est le photographe et le bourrage de mots clés.

Le même principe s'applique aux applications Internet riches accessibles (ARIA). ARIA est un ensemble d'attributs conçus pour étendre le HTML afin de combler les lacunes entre le contenu interactif et la technologie d'assistance. Lorsque ARIA est utilisé pour remplacer complètement HTML, cela conduit souvent à une expérience sur-décrite.

Brian explique: «Il semble y avoir une perception selon laquelle plus d'ARIA corrige l'accessibilité et cela peut aider, mais trop lit soit de mauvaises choses ou parle tout simplement trop. Si le texte à l'écran d'un ou deux mots convient à tout le monde, il convient également aux utilisateurs de lecteurs d'écran. Nous n'avons pas besoin d'une phrase entière ou de deux descriptions de boutons ou de liens, c'est-à-dire que la «politique de confidentialité des liens» est bien meilleure que quelque chose comme «ce lien ouvrira notre politique de confidentialité, ce lien s'ouvrira dans une nouvelle fenêtre» lorsque le texte du lien à l'écran est une «politique de confidentialité». »

La première règle d'utilisation d'ARIA nous conseille de ne l'utiliser que lorsqu'un élément natif ne suffit pas. Vous n'avez pas besoin de décrire ce qu'est votre composant interactif ni comment il fonctionne, de la même manière que vous n'avez pas besoin d'inclure le mot «image» dans votre description alternative.

Si vous utilisez l'élément HTML natif approprié, la technologie d'assistance gérera tout cela pour vous. Faire plus, plus solidement, avec moins d'effort? Ça me semble génial!

Un exemple de code d'un élément d'ancrage enveloppant une image, avec une description alternative qui se lit comme suit: "Un chat portant un chapeau de fête." Les flèches des éléments et attributs HTML indiquent comment tout se combine pour créer une phrase prononcée à haute voix par un lecteur d'écran. La phrase se lit comme suit: «Lien. Image. Un chat portant un chapeau de fête.
(Grand aperçu)

Contrairement à la plupart de HTML, CSS et JS, le succès de ARIA implémenté est contextuel, variable et largement invisible. En dépit de cela, nous semblons étouffer ARIA sur tout sans prendre la peine de vérifier non seulement si cela fonctionne réellement, mais aussi ce qu'en pensent les personnes qui l'utilisent réellement.

La prise en charge d'ARIA est fragmentée entre les systèmes d'exploitation, les navigateurs et les offres de technologies d'assistance, toutes leurs versions respectives et toutes les permutations possibles des trois. Autrement dit, écrire ARIA et avoir confiance qu'il fonctionnera comme prévu ne suffit pas.

S'il est mal configuré et / ou sur-appliqué, ARIA peut casser. Il peut ne pas signaler une fonctionnalité réelle, annoncer la mauvaise fonctionnalité et (avec précision ou inexactitude) décrire de manière excessive une fonctionnalité. De toute évidence, ces expériences ne sont pas équivalentes.

La représentation est importante. Pour mieux comprendre le fonctionnement du code ARIA que vous avez écrit, je vous recommande d'embaucher des personnes pour vous le dire. Voici quatre de ces services qui font exactement cela:

Contraste

Contraste des couleurs

Le contraste des couleurs est un autre problème courant, dont la gravité semble souvent être minimisée. Si je peux parier une supposition, c'est parce qu'il est facile d'oublier que la vision des autres peut être différente de la vôtre. Quoi qu'il en soit, c'est une préoccupation qui affecte une large partie de la population mondiale, et nous devons traiter la question avec le sérieux qu'elle mérite.

L'enquête Click-Away Pound nous indique que parmi les principaux problèmes rencontrés par les utilisateurs ayant des besoins d'accès, le contraste et la lisibilité constituent le cinquième problème le plus important. En plus de cela, il a augmenté préoccupante, passant de 44% des répondants en 2016 à 55% en 2019.

Nous vivons à une époque où il y a plus de ressources de vérification du contraste des couleurs que je ne peux en compter. Des produits comme Stark peuvent aider les concepteurs à auditer leurs conceptions avant leur traduction en code. Des outils tels que la grille de contraste d'Eightshape et le générateur de palette de couleurs accessibles d'Atul Varma vous permettent de créer vos systèmes de conception avec des combinaisons de couleurs robustes et accessibles dès le départ.

Une comparaison côte à côte démontrant des rapports de contraste de couleur acceptables et mauvais. Le premier exemple montre du texte noir sur un fond jaune foncé, avec un rapport de contraste de 9,89: 1. Le deuxième exemple montre du texte gris clair sur un fond bleu clair, avec un rapport de contraste défaillant de 2,13: 1. Le texte des deux exemples se lit comme suit: «La collection d'éclairage va des classiques intemporels aux designs contemporains qui font des ajouts parfaits à n'importe quelle maison et espace.»
(Grand aperçu)

La chose quelque peu ironique sur le contraste des couleurs est de savoir comment, ah, il est visible. Alors que certains des problèmes d'accessibilité précédents sont invisibles – cachés comme le code sous-jacent – le contraste est un problème assez simple.

Généralement, le contraste est un scénario binaire, dans la mesure où vous pouvez ou ne pouvez pas voir le contenu. Donc, la prochaine fois que vous vérifierez votre site Web ou votre application Web avec un vérificateur d'accessibilité automatisé tel que la hache Deque, ne soyez pas si rapide pour minimiser les erreurs de contraste de couleur qu'il signale.

Contraste élevé

Il existe des solutions technologiques pour les situations où même des rapports de contraste des couleurs satisfaisants ne suffisent pas, à savoir le mode couleurs inversées et le mode contraste élevé. De nombreux participants que j'ai interviewés ont mentionné utiliser ces modes d'affichage lors de leur utilisation quotidienne de l'ordinateur.

À condition d'utiliser du HTML sémantique, ces deux modes n'ont pas besoin de beaucoup d'efforts pour que le développement fonctionne correctement. L'important est de vérifier ce que vous construisez dans ces deux modes pour vous assurer que tout fonctionne comme prévu.

Viser la perfection

Pour citer Léonie Watson,

"L’accessibilité n’a pas à être parfaite, elle doit juste être un peu meilleure qu’hier."

En comprenant à la fois pourquoi et comment améliorer vos expériences d'accessibilité numérique de manière à éliminer directement les obstacles communs, vous êtes en mesure de proposer à tous des expériences significatives et agréables.

Lectures complémentaires

Merci à Brian Moore, Damien Senger, Jim Kiely, Justin Yarbrough, Kenny Hitt et Soren Hamby pour avoir partagé leurs idées et leurs expériences.

Smashing Editorial(rail)

Laisser un commentaire

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