Bon, meilleur, meilleur : démêler le monde complexe des modèles accessibles

Marc Benioff a déclaré de manière mémorable que la seule constante dans l'industrie technologique est le changement. Ayant travaillé dans la technologie pendant plus de 15 ans, je peux le confirmer. Les autres dinosaures de la technologie peuvent attester que le fonctionnement du Web à ses débuts est radicalement différent de ce que beaucoup d'entre nous auraient pu imaginer.

Alors que ce changement constant dans l'industrie technologique a conduit à l'innovation et aux progrès que nous voyons aujourd'hui, il a également introduit le concept de choix. Bien que le choix - à première vue - puisse sembler être une chose intrinsèquement positive, il n'est pas toujours synonyme d'arcs-en-ciel et de roses. L'afflux de changements technologiques apporte également l'éclatement des langages de codage et les saveurs sans fin de la programmation "hotness". Parfois, cette abondance de choix se transforme en choix excessif - une déficience cognitive bien étudiée dans laquelle les gens ont du mal à prendre une décision en raison d'un trop grand nombre d'options.

Dans cet article, nous tenterons de démêler le monde complexe des modèles accessibles, une étape à la fois. Nous commencerons par passer en revue les modèles et bibliothèques accessibles actuels, puis nous examinerons nos besoins généraux en matière de modèles et les restrictions potentielles, et enfin, nous passerons en revue une série d'exercices de réflexion critique pour apprendre à mieux évaluer les modèles pour l'accessibilité.

Quelle toile emmêlée nous tissons

Le choix excessif s'est glissé dans tous les aspects de la technologie, y compris les modèles et les bibliothèques que nous utilisons pour créer nos créations numériques - de la simple case à cocher au modal dynamique complexe et tout le reste. Mais comment savoir quel modèle ou quelle bibliothèque est le bon quand il y a tant de choix ? Est-il préférable d'utiliser des modèles/bibliothèques établis que les utilisateurs rencontrent tous les jours ? Ou est-il préférable de créer de nouveaux modèles pour une expérience utilisateur plus agréable ?

Avec la myriade d'options disponibles, nous pouvons rapidement devenir paralysés par la surabondance de choix. Mais si nous prenons du recul et considérons pourquoi nous construisons nos produits numériques en premier lieu (c'est-à-dire l'utilisateur final), cela n'a-t-il pas de sens de choisir le modèle ou la bibliothèque qui peut ajouter le plus de valeur pour le plus grand nombre de personnes ?

Si vous pensiez que choisir un motif ou une bibliothèque était un processus déjà assez intimidant, c'est peut-être le point où vous commencez à vous inquiéter. Mais pas besoin de s'inquiéter - choisir un modèle/une bibliothèque accessible n'est pas sorcier. Comme tout le reste de la technologie, ce voyage commence par un peu de connaissances, un tas d'essais et d'erreurs et la compréhension qu'il n'y a pas qu'un seul modèle/bibliothèque parfait qui convient à chaque utilisateur, situation ou cadre.

Comment puis-je le savoir ? Eh bien, j'ai passé les cinq dernières années à rechercher, créer et tester différents types de modèles accessibles tout en travaillant sur le guide de style A11y, la bibliothèque de modèles ARIA de Deque et en évaluant les modèles SVG populaires. Mais j'ai également passé en revue de nombreux modèles de clients et bibliothèques sur tous les frameworks/plates-formes imaginables. À ce stade, je peux dire sans scrupule qu'il existe une hiérarchie innée pour l'accessibilité des modèles qui commence à se développer lorsque vous regardez assez longtemps. Et bien qu'il y ait parfois des modèles à éviter à tout prix, ce n'est pas toujours aussi clair. En ce qui concerne l'accessibilité, je dirais que la plupart des modèles tombent dans des gradients de bon, meilleur, meilleur. La partie difficile est de savoir quel modèle appartient à quelle catégorie.

Penser de manière critique aux modèles

Alors, comment savons-nous quels modèles sont bons, meilleurs, meilleurs en matière d'accessibilité ? Ça dépend. Cette phrase souvent invoquée par la communauté de l'accessibilité numérique n'est pas une échappatoire, mais un raccourci pour "nous avons besoin de plus de contexte pour pouvoir vous donner la meilleure réponse". Cependant, le contexte n'est pas toujours clair, donc lors de la construction et de l'évaluation de l'accessibilité d'un modèle, certaines questions fondamentales que je pose incluent :

• Existe-t-il déjà un modèle accessible établi que nous pouvons utiliser ?
• Quels navigateurs et appareils de technologie d'assistance (AT) prenons-nous en charge ?
• Existe-t-il des limitations du framework ou d'autres intégrations/facteurs à prendre en compte ?

Bien sûr, vos questions spécifiques peuvent différer des miennes, mais le fait est que vous devez commencer à utiliser vos compétences de pensée critique lors de l'évaluation des modèles. Vous pouvez le faire en observant, en analysant, puis en classant chaque modèle pour l'accessibilité avant de passer à une décision finale. Mais avant d'en arriver là, approfondissons d'abord un peu plus les questions initiales.

Existe-t-il déjà un modèle d'accessibilité établi ?

Pourquoi semble-t-il qu'à chaque nouveau framework, nous obtenons un tout nouvel ensemble de modèles ? Cette réinvention constante de la roue avec de nouveaux choix de modèles peut dérouter et frustrer les développeurs, d'autant plus qu'il n'est généralement pas nécessaire de le faire.

Vous ne me croyez pas ? Eh bien, pensez-y de cette façon : si nous souscrivons au système de conception atomique, nous comprenons que plusieurs petits « atomes » de code se réunissent pour créer un produit numérique plus grand. Mais dans le monde scientifique, les atomes ne sont pas le plus petit composant de la vie. Chaque atome est composé de nombreuses particules subatomiques telles que des protons, des neutrons et des électrons.

Cette même logique peut être appliquée à nos modèles. Si nous examinons plus en profondeur tous les modèles disponibles dans les différents cadres existants, la structure subatomique de base est essentiellement la même, quel que soit le langage de codage utilisé. C'est pourquoi j'apprécie les bibliothèques de codage simplifiées avec des modèles accessibles sur lesquels nous pouvons nous appuyer en fonction des besoins technologiques et de conception.

Remarque : Certaines sources réputées incluent les composants inclusifs, les composants accessibles et le système de conception Gov.UK, en plus de la liste des modèles accessibles Smashing Magazine récemment publiée (plus une liste plus détaillée des modèles et des bibliothèques à la fin de l'article) .

Quels navigateurs et appareils de technologie d'assistance (AT) prenons-nous en charge ?

Après avoir recherché quelques modèles de base qui pourraient fonctionner, nous pouvons passer à la question de la prise en charge des navigateurs et des appareils de technologie d'assistance (AT). En soi, la prise en charge du navigateur n'est pas une blague. Lorsque vous ajoutez des appareils AT et des spécifications ARIA au mélange, les choses commencent à devenir délicates… pas impossibles, juste beaucoup plus de temps, d'efforts et de réflexion pour tout comprendre.

Mais ce ne sont pas toutes de mauvaises nouvelles. Il existe des ressources fabuleuses telles que l'accessibilité HTML5 et la prise en charge de l'accessibilité qui nous aident à mieux comprendre la prise en charge actuelle des navigateurs et des appareils AT. Ces sites Web décrivent les différents sous-éléments de modèles HTML et ARIA disponibles, incluent des tests communautaires open source et fournissent des exemples de modèles - pour les navigateurs de bureau et mobiles/appareils AT.

Existe-t-il des limitations du framework ou d'autres intégrations/facteurs à prendre en compte ?

Une fois que nous avons choisi quelques modèles de base accessibles et pris en compte la prise en charge du navigateur/de l'appareil AT, nous pouvons passer à des questions contextuelles plus fines autour du modèle et de son environnement. Par exemple, si nous utilisons un modèle dans un système de gestion de contenu (CMS) ou si nous avons des considérations de code hérité, il y aura certaines limitations de modèle. Dans ce cas, une poignée de choix de modèles peut rapidement être réduite à un ou deux. D'un autre côté, certains frameworks sont plus indulgents et ouverts à l'acceptation de n'importe quel modèle, nous pouvons donc moins nous soucier des restrictions du framework et nous concentrer davantage sur le choix de modèle le plus accessible que nous puissions faire.

Outre tout ce dont nous avons discuté jusqu'à présent, il existe de nombreuses considérations supplémentaires à prendre en compte lors du choix d'un modèle, telles que les performances, la sécurité, l'optimisation des moteurs de recherche, la traduction linguistique, l'intégration de tiers, etc. Ces facteurs joueront sans aucun doute dans votre choix de modèle accessible, mais vous devriez également penser aux personnes qui créent le contenu. Le modèle accessible que vous choisissez doit être construit de manière suffisamment robuste pour gérer toute limitation potentielle autour du contenu généré par l'éditeur et/ou généré par l'utilisateur.

Évaluation des modèles pour l'accessibilité

Le code parle souvent plus fort que les mots, mais avant de nous lancer dans tout cela, une note rapide que les exemples de modèles suivants ne sont pas les seuls modèles disponibles pour chaque situation, et que celui considéré comme "le meilleur" du groupe n'est pas la meilleure option dans le monde entier de motifs accessibles.

Pour les démonstrations de modèles ci-dessous, nous devrions imaginer une situation hypothétique dans laquelle nous comparons chaque groupe de modèles à eux-mêmes. Bien que ce ne soit pas une situation réaliste, parcourir ces exercices de réflexion critique et évaluer les modèles d'accessibilité devrait vous aider à être mieux préparé lorsque vous rencontrez des choix de modèle dans le monde réel.

Modèles de boutons accessibles

Le premier groupe de modèles que nous examinerons pour l'accessibilité est omniprésent sur presque tous les sites Web ou applications : les boutons. Le premier modèle de bouton utilise le rôle de bouton ARIA pour imiter un bouton, tandis que les deuxième et troisième modèles de bouton utilisent l'élément HTML <button> . Le troisième modèle ajoute également aria-describedby et CSS pour masquer les choses visuellement.

Bon : role="button"

 <a role="button" href="[link]">Sign up</a>

Mieux : <button>

 <button type="button">Sign up</button>

Meilleur : <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Bien que les premiers modèles semblent simples à première vue, ils évoquent certaines questions d'accessibilité. Par exemple, sur le premier motif de bouton, nous voyons qu'ARIA role="button" est utilisé sur le motif "good" au lieu d'un élément HTML <button> . En termes d'accessibilité, puisque nous savons que l'élément HTML <button> a été introduit dans HTML4, nous pouvons raisonnablement supposer qu'il est entièrement pris en charge par les dernières versions de tous les principaux navigateurs et fonctionnera bien avec la plupart des appareils AT. Mais si nous creusons plus profondément et examinons la prise en charge de l'accessibilité pour ARIA role="button", nous voyons un léger avantage du point de vue de la technologie d'assistance, tandis que l'élément HTML <button> manque certaines zones de couverture navigateur + AT, en particulier si l'on considère prise en charge de la commande vocale.

Alors pourquoi le modèle ARIA n'est-il pas dans la catégorie "meilleur" ? ARIA ne le rend-il pas plus accessible ? Nan. En fait, dans des cas comme celui-ci, les professionnels de l'accessibilité récitent souvent la première règle d'ARIA : ne pas utiliser ARIA. C'est une façon ironique de dire d'utiliser les éléments HTML autant que possible. ARIA est en effet puissant, mais entre de mauvaises mains, il peut faire plus de mal que de bien. En fait, le rapport WebAIM Million indique que "les pages avec ARIA présentent en moyenne 60 % d'erreurs en plus que celles qui n'en ont pas". En tant que tel, vous devez savoir ce que vous faites lorsque vous utilisez ARIA.

Une autre attaque contre l'utilisation d'ARIA dans cette situation est que la fonctionnalité de bouton dont nous avons besoin devrait être construite pour le modèle role="button" , alors que cette fonctionnalité est déjà pré-intégrée dans l'élément <button> . Considérant que l'élément <button> a également une prise en charge à 100% du navigateur et qu'il s'agit d'un modèle facile à implémenter, il se situe légèrement en tête dans la hiérarchie lors de l'évaluation des deux premiers modèles. Espérons que cette comparaison aide à briser le mythe selon lequel l'ajout d'ARIA rend un modèle plus accessible - souvent le contraire est vrai.

Le troisième modèle de bouton montre l'élément HTML <button> couplé avec aria-describedby lié à un élément ID qui est masqué visuellement avec CSS. Bien que ce modèle soit légèrement plus complexe, il ajoute beaucoup en termes de contexte en créant une relation entre le bouton et l'objectif. En cas de doute, chaque fois que nous pouvons ajouter plus de contexte à la situation, mieux c'est, donc nous pouvons supposer que s'il est codé correctement, c'est le meilleur modèle lorsque nous ne comparons que ces modèles de boutons spécifiques.

Modèles de liens contextuels accessibles

Le deuxième groupe de modèles que nous allons examiner sont les liens contextuels. Ces modèles aident à donner plus d'informations aux utilisateurs AT que ce qui est visible à l'écran. Le premier modèle de lien utilise CSS pour masquer visuellement les informations contextuelles supplémentaires. Alors que les deuxième et troisième modèles de lien ajoutent des attributs ARIA dans le mélange : aria-labelledby et aria-label , respectivement.

Bon : visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Mieux : visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Meilleur : aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Bien que les trois modèles de liens contextuels se ressemblent, lorsque nous inspectons le code ou les testons avec des appareils AT, il existe des différences évidentes. Le premier modèle utilise une technique CSS pour masquer visuellement le contenu pour les utilisateurs voyants, mais restitue toujours le contenu masqué aux utilisateurs AT non voyants. Et même si cette technique devrait fonctionner dans la plupart des cas, il n'y a pas de relation réelle formée entre le lien et les informations supplémentaires, de sorte que la connexion est au mieux provisoire. En tant que tel, le premier modèle de lien est un bon choix, mais pas le modèle de lien le plus robuste des trois.

Les deux modèles de liens suivants sont un peu plus difficiles à évaluer. Selon les spécifications ARIA du W3C « Le but d' aria-label est le même que celui d' aria-labelledby . Il fournit à l'utilisateur un nom reconnaissable de l'objet. » Donc, en théorie, les deux attributs devraient avoir la même fonctionnalité de base.

Cependant, les spécifications soulignent également que les agents utilisateurs donnent la priorité à aria-labelledby sur aria-label lors du choix du nom accessible à transmettre à l'utilisateur. La recherche a également montré des problèmes liés à la traduction automatique et aux attributs aria-label. Cela signifie donc que nous devrions utiliser aria-labelledby , n'est-ce pas ?

Eh bien, pas si vite. Les mêmes spécifications ARIA poursuivent en disant "Si l'interface est telle qu'il n'est pas possible d'avoir une étiquette visible à l'écran (ou si une étiquette visible n'est pas l'expérience utilisateur souhaitée), les auteurs doivent utiliser aria-label et ne doivent pas utilisez aria-labelledby .” Parlez de confusion - alors quel modèle devrions-nous choisir ?

Si nous avions des besoins de traduction à grande échelle, nous pourrions décider de changer l'aspect visuel et d'écrire les liens avec le contexte complet affiché (par exemple " En savoir plus sur cette chose géniale ") ou décider d'utiliser aria-labelledby . Cependant, supposons que nous n'avions pas de besoins de traduction à grande échelle ou que nous puissions répondre à ces besoins d'une manière raisonnable/accessible, et que nous ne voulions pas changer le visuel - et alors ?

Sur la base des recommandations actuelles d'ARIA 1.1 (avec la promesse de traduction d'aria-label dans ARIA 1.2) et du fait aria-label est un peu plus facile à mettre en œuvre pour les développeurs par rapport à aria-labelledby , nous pourrions décider de pondérer aria-label sur aria-labelledby dans notre évaluation de modèle. Ceci est un exemple clair de cas où le contexte pèse lourdement dans notre choix de modèle accessible.

Modèles <svg> accessibles

Enfin, mais non des moindres, examinons un groupe de modèles d'image SVG pour l'accessibilité. Les SVG sont une représentation visuelle du code, mais du code quand même. Cela signifie qu'un périphérique AT peut ignorer une image SVG non décorative à moins que le role="img" ne soit ajouté au modèle.

En supposant que les modèles SVG suivants sont de nature informative, un role="img" a été inclus dans chacun. Le premier modèle SVG utilise le <title> et le <text> en conjonction avec le CSS pour masquer visuellement le contenu aux utilisateurs voyants. Les deux modèles SVG suivants impliquent les éléments <title> et <desc> , mais avec un attribut aria-labelledby ajouté au dernier modèle.

Bon : role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Mieux : role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Meilleur : role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Regardons d'abord le premier modèle utilisant <title> et <text> et le CSS visuellement caché. Contrairement aux précédents textes visiblement masqués dans les modèles, il existe une relation inhérente entre les éléments <title> et <text> puisqu'ils sont regroupés sous le même parapluie d'éléments SVG. Cependant, cette relation n'est pas très forte. En fait, si vous regardez mes recherches sur les modèles SVG, nous constatons que seules 3 combinaisons navigateur/AT sur 8 ont entendu le message complet. (Remarque : le modèle de cochon n° 1 équivaut au modèle d'ampoule n° 7.)

Cela est vrai bien que les spécifications SVG du W3C définissent l'élément <text> comme « un élément graphique composé de texte… les caractères à dessiner sont exprimés sous forme de données de caractères. Par conséquent, les données textuelles du contenu SVG sont facilement accessibles aux malvoyants. » Ce premier schéma est OK, mais on peut faire mieux.

Le deuxième modèle supprime l'élément <text> et le remplace par un élément <desc> . Les spécifications SVG du W3C indiquent :

"L'élément enfant <title> représente une alternative textuelle courte pour l'élément... et l'élément <desc> représente des informations textuelles plus détaillées pour l'élément, telles qu'une description."

Cela signifie que les éléments <title> et <desc> dans les SVG peuvent être utilisés de la même manière que le texte alternatif d'image et les options de description longue que l'on trouve traditionnellement dans les éléments <img> . Après avoir ajouté l'élément <desc> au deuxième SVG, nous voyons un support navigateur/AT similaire avec 3 combinaisons sur 8 entendant le message complet. (Remarque : le modèle de cochon n° 2 équivaut au modèle d'ampoule n° 10.) Bien que ces résultats de test semblent refléter le premier modèle, la raison pour laquelle ce modèle se retrouve dans la catégorie « meilleur » est qu'il est légèrement plus facile d'implémenter le code. sage et cela a un impact sur plus d'utilisateurs AT, car cela fonctionnait sur JAWS, VoiceOver desktop et VoiceOver mobile, tandis que le premier modèle prenait en charge des combinaisons navigateur/AT moins populaires.

Le troisième modèle utilise à nouveau les éléments <title> et <desc> mais a maintenant un ID aria-labelledby plus ajouté au mélange. Selon les mêmes tests SVG, l'ajout de ce morceau de code supplémentaire signifie que nous pouvons entièrement prendre en charge 7 combinaisons navigateur/AT sur 8. (Remarque : le modèle de cochon n° 3 équivaut au modèle d'ampoule n° 11.) Parmi les trois modèles SVG, ce troisième est le « meilleur » car il prend en charge la plupart des appareils AT. Mais ce modèle présente un inconvénient dans l'utilisation de certaines combinaisons navigateur/AT ; vous entendrez le contenu du titre/description de l'image en double pour ce motif. Bien que potentiellement ennuyeux pour les utilisateurs, je dirais qu'il est généralement préférable d'entendre du contenu dupliqué que pas du tout.

Réflexions finales

Bien que nous apprécions tous le choix en matière de technologie, je me demande si nous sommes arrivés à un moment où la surabondance d'options nous a laissés paralysés et confus quant à ce qu'il faut faire ensuite ? En ce qui concerne la sélection de modèles accessibles, nous pouvons poser des questions simples sur les options de modèles/bibliothèques, la prise en charge des navigateurs/appareils AT, les limitations du cadre, etc.

Avec les bonnes données en main, il est assez facile de répondre à ces questions. Cependant, cela devient un peu plus compliqué lorsque nous allons au-delà des modèles et considérons vraiment les personnes qui les utilisent. C'est alors que nous nous rendons compte de l'impact de nos choix sur la capacité de réussite de nos utilisateurs. Comme le déclare avec éloquence le professeur George Dei :

"L'inclusion ne fait pas entrer les gens dans ce qui existe déjà - c'est créer un nouvel espace, un meilleur espace pour tout le monde."

En prenant un peu plus de temps pour réfléchir de manière critique aux modèles et choisir les plus accessibles, nous créerons sans aucun doute un espace plus inclusif pour atteindre plus d'utilisateurs - à leurs conditions.

Ressources associées

Outils

• Assistance à l'accessibilité, Michael Fairchild, a11ysupport.io
• Accessibilité HTML5, Steve Faulkner

Bibliothèques de motifs

• Projet d'accessibilité
• Guide de style d'accessibilité
• Composants accessibles, Scott O'Hara
• Plugin de réorganisation de liste drag-and-drop accessible, Harris Schneiderman
• Bibliothèque de modèles ARIA de Deque
• Bibliothèque React accessible de Deque
• Système de conception GOV.UK
• Composants inclusifs, Heydon Pickering
• Système de conception Web américain (USWDS)
• Tutoriels d'accessibilité Web