Démêler le monde complexe des modèles accessibles
Marc Benioff a déclaré de façon mémorable que la seule constante dans l'industrie de la technologie est le changement. Ayant travaillé dans la technologie pendant plus de 15 ans, je peux le confirmer. Les autres dinosaures technologiques peuvent attester que la façon dont le Web fonctionnait à ses débuts est radicalement différente de ce que beaucoup d’entre nous auraient même pu imaginer.
Bien que ce changement constant dans l’industrie de la technologie ait conduit à l’innovation et aux progrès que nous constatons aujourd'hui, a également introduit le concept de choix. Bien que le choix – en surface – puisse sembler une chose intrinsèquement positive, il n'égale pas toujours les arcs-en-ciel et les roses. L'afflux du changement technologique 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 surchoix – une déficience cognitive bien étudiée dans laquelle les gens ont du mal à prendre une décision en raison du trop grand nombre d'options.
Dans cet article, nous tenterons de démêler le complexe. monde de 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 marcherons à travers une série d'exercices de réflexion critique pour apprendre à mieux évaluer les modèles d'accessibilité. ] What A Tangled Web We Weave
Overchoice s'est frayé un chemin dans tous les aspects de la technologie, y compris les modèles et les bibliothèques que nous utilisons pour construire 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 alors qu'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 des 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 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 modèle ou une bibliothèque était déjà un processus déjà assez intimidant, c'est peut-être à ce moment-là que vous commencez à vous inquiéter. Mais pas besoin de vous 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 énorme tas d'essais et d'erreurs, et une compréhension qu'il n'y a pas qu'un modèle / bibliothèque parfait qui convient à chaque utilisateur, situation ou cadre.
Comment le sais-je? Eh bien, j'ai passé les cinq dernières années à rechercher, construire et tester différents types de motifs accessibles tout en travaillant sur le A11y Style Guide Deque's ARIA Pattern Library et en évaluant les populaires. ] Modèles SVG . 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 scrupules 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 s'il y a parfois des schémas à é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 bien, mieux, mieux. La partie difficile est de savoir quel modèle appartient à quelle catégorie.
Penser de manière critique aux modèles
Alors, comment savoir 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 être en mesure de 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 comprennent:
- Existe-t-il déjà un modèle accessible établi que nous pouvons utiliser?
- Quels navigateurs et technologies d'assistance ( AT) que nous prenons en charge?
- Y a-t-il des limitations du cadre 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à, examinons d'abord un peu plus les questions initiales.
Existe-t-il déjà un modèle accessible établi?
Pourquoi semble-t-il qu'avec chaque nouveau cadre, nous obtenons un tout nouvel ensemble de modèles ? Cette réinvention constante de la roue avec de nouveaux choix de motifs 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 la plus petite composante de la vie. Chaque atome est composé de nombreuses particules subatomiques comme les protons, les neutrons et les électrons.
Cette même logique peut être appliquée à nos modèles. Si nous examinons plus en détail 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 rationalisées avec des modèles accessibles sur lesquelles nous pouvons nous appuyer en fonction des besoins technologiques et de conception.
Note : Certaines sources réputées comprennent ] Composants inclusifs Composants accessibles et le Gov.UK Design System 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 dispositifs d'assistance technique (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 (TA). En soi, la prise en charge du navigateur n'est pas une blague. Lorsque vous ajoutez des dispositifs AT et des spécifications ARIA au mélange, les choses commencent à devenir délicates… pas impossibles, il faut 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 Accessibilité HTML5 et Assistance d'accessibilité qui nous aident à mieux comprendre le support actuel du navigateur et des périphériques AT. Ces sites Web décrivent les différents sous-éléments de modèle HTML et ARIA disponibles, incluent des tests de communauté open source et fournissent des exemples de modèle – pour les navigateurs / appareils AT de bureau et mobiles.
Existe-t-il des limitations de structure ou d'autres intégrations / facteurs à
Une fois que nous avons choisi quelques modèles de base accessibles et pris en compte le support du navigateur / périphérique 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 motifs peut être rapidement réduite à un ou deux. D'un autre côté, certains frameworks sont plus indulgents et ouverts à accepter n'importe quel modèle, donc nous pouvons moins nous soucier des restrictions de framework et nous concentrer davantage sur le choix de modèle le plus accessible que nous pouvons faire.
En plus de tout ce que nous avons discuté jusqu'à présent. , il y a de nombreuses considérations supplémentaires à prendre en compte lors du choix d'un modèle, comme les performances, la sécurité, l'optimisation des moteurs de recherche, la traduction linguistique, l'intégration tierce, 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 conçu de manière suffisamment robuste pour gérer toute limitation potentielle du contenu généré par l'éditeur et / ou par l'utilisateur.
Évaluation des modèles pour l'accessibilité
Le code parle souvent plus fort que les mots, mais avant nous sautez dans tout cela, notez rapidement que les exemples de modèles suivants ne sont pas les seuls modèles disponibles pour chaque situation, et que celui considéré comme «meilleur» dans le groupe n'est pas la meilleure option dans le monde entier des modèles accessibles.
For les modèles de démonstration ci-dessous, nous devrions imaginer une situation hypothétique dans laquelle nous comparons chaque groupe de modèles avec eux-mêmes. Bien que ce ne soit pas une situation réaliste, exécuter ces exercices de pensée critique et évaluer les modèles d'accessibilité devraient vous aider à être mieux préparé lorsque vous rencontrez des choix de modèles dans le monde réel.
Modèles de boutons accessibles
Le premier groupe de modèles nous examinerons l'accessibilité sont omniprésentes dans 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 . Le troisième modèle ajoute également
aria-describedby
et CSS pour cacher les choses visuellement .
See the Pen [Accessible Button Patterns] (https://codepen.io/smashingmag/pen/KKNEjKR ) par Carie Fisher .
Bon: role = "button" [19659039] Inscription
Mieux:
Meilleur:
+ visuellement masqué
+ aria-describedby
+ visuellement masqué
+ aria-describedby
Si 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 que ARIA role = "button"
est utilisé sur le "bon" motif au lieu d'un élément HTML . En pensant en termes d'accessibilité, puisque nous savons que l'élément HTML
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 qu'il fonctionnera bien avec la plupart des appareils AT. Mais si nous approfondissons 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
est absent certaines zones de couverture navigateur + AT, en particulier lorsque nous considérons la prise en charge de la commande vocale.
Alors pourquoi le modèle ARIA n'est-il pas dans la catégorie «meilleure»? ARIA ne le rend-il pas plus accessible? Non. En fait, dans des cas comme celui-ci, les professionnels de l’accessibilité récitent souvent la première règle de ARIA – ne pas utiliser ARIA . C'est une façon ironique de dire d'utiliser des éléments HTML chaque fois que cela est possible. ARIA est en effet puissante, mais entre de mauvaises mains, elle peut faire plus de mal que de bien. En fait, le rapport WebAIM Million indique que «les pages avec ARIA présent en moyenne 60% plus d'erreurs que celles sans. En tant que tel, vous devez savoir ce que vous faites lorsque vous utilisez ARIA.
Un autre inconvénient à utiliser ARIA dans cette situation est que la fonctionnalité de bouton dont nous avons besoin doit être créée pour le role = "button"
pattern, alors que cette fonctionnalité est déjà pré-cuite dans l'élément . Étant donné que l'élément
prend également en charge le navigateur à 100% et est un modèle facile à implémenter, il avance légèrement 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 couplé à
aria-describedby
lié à un élément ID 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 le but. En cas de doute, à tout moment 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 l'on compare uniquement ces modèles de boutons spécifiques.
Modèles de liens contextuels accessibles
Le second groupe de modèles que nous examinerons sont des 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 au mélange: aria-labelledby
et aria-label
respectivement.
See the Pen [Accessible Link Patterns] (https: // codepen.io/smashingmag/pen/VwmRJYv) de Carie Fisher .
Bon: visuellement caché
«Ma mère avait toujours l'habitude de dire: plus on vieillit, mieux on vieillit, à moins que l'on ne soit une banane.» - Rose (Betty White) Lire la suite Citations de Golden Girl
Mieux: visuellement caché
+ aria-labelledby
«Je vais soit obtenir de la glace crème ou commettre un crime ... je déciderai dans la voiture. - Blanche (Rue McClanahan) En savoir plus En savoir plus Citations de Golden Girl
Meilleur: aria-label
«Les gens perdent leur temps à se demander si un verre est à moitié vide ou à moitié plein. Moi, je bois juste ce qu’il y a dans le verre. » - Sophia (Estelle Getty) En savoir plus
Bien que les trois modèles de liens contextuels se ressemblent, lorsque nous inspectons le code ou les testons avec des périphériques 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 caché aux utilisateurs AT non voyants. Et bien que 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, donc la connexion est au mieux provisoire. En tant que tel, le premier modèle de lien est un choix correct mais pas le modèle de lien le plus robuste des trois.
Les deux modèles de lien suivants sont un peu plus difficiles à évaluer. Selon les spécifications ARIA du W3C «Le but de aria-label
est le même que celui de 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 indiquent également que les agents utilisateurs donnent la priorité à aria-labelledby
sur aria-label
lorsque décider du nom accessible à transmettre à l'utilisateur. La recherche a également montré des problèmes concernant la traduction automatique et les attributs aria-label . Cela signifie que nous devrions utiliser aria-labelledby
n'est-ce pas?
Eh bien, pas si vite. Les mêmes spécifications ARIA disent: «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 devraient utiliser aria-label
et ne doivent pas utiliser 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 this awesome thing ”) ou décidez d'utiliser aria-labelledby
. Cependant, supposons que nous n'avions pas de besoins de traduction à grande échelle ou que nous pourrions 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 ARIA 1.1 actuelles ( avec la promesse de traduction de aria-label dans ARIA 1.2 ) plus le fait que 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 quand le contexte pèse lourd dans notre choix de modèle accessible.
Accessible
Modèles
Dernier point, mais certainement pas le moindre, examinons un groupe de modèles d'images SVG pour l'accessibilité. Les SVG sont une représentation visuelle du code, mais néanmoins du code. Cela signifie qu'un périphérique AT peut sauter 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
et
en conjonction avec CSS pour masquer visuellement le contenu aux utilisateurs voyants. Les deux modèles SVG suivants impliquent les éléments
et
mais avec un attribut aria-labelledby
ajouté au dernier modèle.
See the Pen [Accessible SVG Patterns] (https: // codepen .io / smashingmag / pen / poNYXvK) de Carie Fisher .
Bon: role = "img"
+
+
Mieux: role = "img"
+
+
Meilleur: role = "img"
+
+
+ aria-labelledby = "[id]"
Examinons d'abord le premier modèle en utilisant
et
et du CSS visuellement caché. Contrairement au texte précédent visiblement caché dans les motifs, il existe une relation inhérente entre les éléments
et
puisqu'ils sont regroupés sous le même parapluie d'élément SVG. Cependant, cette relation n'est pas très forte. En fait, si vous regardez mes recherches sur les modèles SVG nous voyons que seulement 3 des 8 combinaisons navigateur / AT ont entendu le message complet. (Remarque: le motif cochon n ° 1 est équivalent au motif d'ampoule n ° 7.)
Ceci est vrai bien que les spécifications de travail W3C SVG définissent l'élément
comme «un élément graphique constitué 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 modèle est correct, mais nous pouvons faire mieux.
Le deuxième modèle supprime l'élément
et le remplace par un élément
. Les W3C SVG specs indiquent:
«L'élément enfant
représente une courte alternative textuelle pour l'élément … et l'élément
représente des informations textuelles plus détaillées pour l'élément, comme un description. ”
Ce qui signifie que les éléments
et
des SVG peuvent être utilisés de la même manière que les options de texte alternatif d'image et de description longue que l'on trouve traditionnellement dans les éléments
. Après avoir ajouté l'élément
au deuxième SVG, nous voyons un support similaire du navigateur / AT avec 3 des 8 combinaisons écoutant le message complet. (Remarque: le motif de cochon n ° 2 est équivalent au motif d'ampoule n ° 10.) Bien que ces résultats de test semblent refléter le premier motif, la raison pour laquelle ce motif obtient une bosse dans la catégorie «meilleure» est qu'il est légèrement plus facile à implémenter le code- sage et il affecte plus d'utilisateurs AT car il fonctionnait sur JAWS, VoiceOver desktop et VoiceOver mobile, tandis que le premier modèle supportait les combinaisons navigateur / AT moins populaires.
Le troisième modèle utilise à nouveau le
] et
mais a maintenant un aria-labelledby
plus ID ajouté dans le mélange. Selon les mêmes tests SVG, l'ajout de ce morceau de code supplémentaire signifie que nous pouvons pleinement prendre en charge 7 des 8 combinaisons navigateur / AT. (Remarque: le motif cochon n ° 3 est équivalent au motif d'ampoule n ° 11.) Parmi les trois motifs SVG, ce troisième est le «meilleur» car il prend en charge la plupart des dispositifs 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 le contenu dupliqué que rien du tout.
Pensées de clôture
Bien que nous apprécions tous certainement le choix en technologie, je me demande si nous sommes arrivés à un point à un moment où la surabondance d'options nous a laissés paralysés et confus sur ce qu'il faut faire ensuite? En termes de sélection de modèles accessibles, nous pouvons poser des questions simples sur les options de modèle / bibliothèque, la prise en charge du navigateur / périphérique AT, les limitations du framework, 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 que nous considérons vraiment les personnes qui les utilisent. C’est alors que nous réalisons l’impact de nos choix sur la capacité de nos utilisateurs à réussir. Comme le déclare avec éloquence le professeur George Dei:
«L'inclusion n'amène pas les gens dans ce qui existe déjà – elle crée 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 choisissez les plus accessibles, nous créerons sans aucun doute un espace plus inclusif pour atteindre plus d'utilisateurs – selon leurs conditions.
Ressources associées
Outils
Bibliothèques de modèles

Source link