Comme nous l'avons vu précédemment , les utilisateurs de lecteurs d'écran peuvent naviguer sur des éléments de contenu spécifiques tels que des titres, des points de repère, des liens, etc. Ce faisant, les personnes qui s'appuient sur cette technologie sont capables de trouver un contenu assez rapidement.
Un problème peut toutefois survenir lorsque des liens, des étiquettes, des boutons, etc. ne suffisent pas à transmettre leur objectif ; leur raison d'être devrait être suffisamment bien expliquée dans leur nom accessible. Si le nom n'est pas clair ou si le même type d'élément est répété avec exactement le même nom, cela peut entraîner une confusion ou une frustration pour l'utilisateur.
Un autre problème peut apparaître lorsque les utilisateurs voyants au clavier naviguent uniquement dans le contenu et que l'indicateur de mise au point disparaît ! Cela est souvent dû au contenu qui est "hors écran" mais qui est accessible via le clavier. Encore une fois, cela peut aussi conduire à une certaine confusion.
Passons en revue quelques exemples et comment atténuer ces problèmes potentiels.
Contenu répété
Le contenu répété peut être considéré comme un contenu qui apparaît plusieurs fois sur une même page ou vue. Ce contenu existe généralement sous forme de liens de légende ou d'images qui existent dans les cellules de liste ou de tableau.
Comme indiqué précédemment, le problème ici est lorsqu'un utilisateur de lecteur d'écran navigue uniquement par un type de contenu spécifique : liens, contrôles de formulaire, en-têtes, etc. Lorsque l'utilisateur entend le contenu répété sans autre contexte, c'est à ce moment que nous pouvons rencontrer quelques problèmes d'utilisation.
Prenez, par exemple, le lien classique "En savoir plus". Ces liens apparaissent souvent sur des blogs ou des pages de listes d'actualités, encourageant l'utilisateur à cliquer pour révéler plus de détails.
Un exemple de lien peut être balisé comme suit :
<a href="article/how-to-make-pasta-sauce.html"> Read more </a>
Sur une page d'articles de blog avec des liens vers des articles, si quelqu'un naviguait uniquement par des liens, il entendrait quelque chose du genre,
« En savoir plus, lien – En savoir plus, lien – En savoir plus, lien »
Étant donné que chaque lien sonne exactement de la même manière en raison du partage de la même étiquette de texte, il n'y a aucun moyen de déterminer où un lien particulier peut mener.
Fournir du contexte sans perturber la conception
Il existe quelques méthodes disponibles afin d'aider à fournir plus de contexte pour des liens tels que ceux-ci sans perturber la conception prévue.
Bien sûr, l'ajout de texte visible supplémentaire serait idéal car cela profiterait aux personnes souffrant de troubles cognitifs avec un étiquetage clair ou à celles ayant une basse vision qui s'appuient sur un logiciel de zoom. Mais, si vous n'êtes pas en mesure d'influencer les choses dans cette direction, examinons quelques alternatives.
Texte masqué visuellement
L'utilisation de la définition de classe CSS .visuallyhidden est un moyen de masquer visuellement le contenu du texte aux utilisateurs voyants, tout en laissant le contenu disponible pour les utilisateurs de lecteurs d'écran. Ceci est aussi parfois appelé sr-only, accessibilité ou d'autres noms de classe associés.
<a href="article/how-to-make-pasta-sauce.html"> Read more <span class="visuallyhidden">about How to Make Pasta Sauce</span> </a>
Pour en revenir à l'exemple de lien "En savoir plus", nous voyons ici que le HTML a le même aspect qu'avant mais avec l'ajout d'un nouvel élément span . Cette span comprend la classe .visuallyhidden , ce qui fait que le contenu du texte sera caché aux utilisateurs voyants, préservant la conception d'origine, mais fournit également le contexte supplémentaire nécessaire aux utilisateurs de lecteurs d'écran.
Désormais, lorsqu'une personne utilisant un lecteur d'écran rencontre ce lien, elle entend :
"En savoir plus sur Comment faire de la sauce pour pâtes, lien"
L'approche du label aria
L'utilisation de l'attribut aria-label est une alternative à la méthode CSS .visuallyhidden . Cette approche définit directement le contenu caché prévu comme nom accessible pour l'élément.
En revisitant l'exemple de lien d'avant, ce code est un peu plus propre et plus facile à lire par rapport à l'exemple .visuallyhidden .
<a href="article/how-to-make-pasta-sauce.html" aria-label="Read more about How to Make Pasta Sauce" > Read more </a> Une chose que vous avez peut-être remarquée est le contenu répété de "En savoir plus" dans l'attribut aria-label . Ceci est nécessaire pour qu'un lecteur d'écran annonce le texte dans son intégralité suite à l'utilisation de l'attribut aria-label , la valeur de l'attribut a priorité sur tout ce qui est placé dans l'élément de lien. En d'autres termes, lorsque vous appliquez l'attribut aria-label , tout texte dans l'élément sera complètement ignoré par les lecteurs d'écran.
Critères de réussite WCAG
Cela revient à 2.4.4 Objectif du lien qui stipule :
"Le but de chaque lien peut être déterminé à partir du texte du lien seul ou du texte du lien avec son contexte de lien déterminé par programme, sauf lorsque le but du lien serait ambigu pour les utilisateurs en général."
Quelques exemples supplémentaires…
Passons en revue quelques situations plus courantes où le texte hors écran serait utile.
Un tableau de boutons
Imaginez une table des éléments de contenu, et chaque élément peut être supprimé de la table à l'aide d'un button de contrôle. Ces contrôles peuvent être balisés comme suit :
<button>Remove</button>
Étant donné que nous savons que les utilisateurs de lecteurs d'écran peuvent naviguer par contenu spécifique, il n'est pas très utile d'entendre "Supprimer" plusieurs fois (en supposant qu'il y a plusieurs éléments dans le table ). Enlever quoi, exactement ?
Utilisons un attribut aria-label pour donner un contexte à chacun des contrôles :
<button aria-label="Remove {item title}"> Remove </button>
Avec l' aria-label ajoutée à chaque instance du contrôle de button et le {item title} ajouté à sa sortie, nous pouvons fournir un contexte supplémentaire pour chaque contrôle.
Classement par étoiles
Il est courant de voir une représentation visuelle d'une note sur une page de produit. Souvent, cela est représenté par un ensemble d'icônes, généralement des icônes en forme d'étoile, représentant une plage de 0 à 5. La signification visuelle de l'image de l'étoile est généralement suffisamment compréhensible pour les utilisateurs voyants, mais comment fournir une alternative textuelle précise à quelqu'un qui utilise un lecteur d'écran ?
Voici un exemple typique d'un balisage d'étoiles produisant des icônes, utilisant un élément i pour produire un ensemble d'icônes :
<i class="icon icon-star star-4"></i>
En devinant par le nom de la classe, star-4 , cela pourrait produire une note visuelle "4 sur 5", mais si quelqu'un utilise un lecteur d'écran, il n'y a rien de disponible pour transmettre les mêmes informations.
Pour ce faire, nous pouvons ajouter du texte .visuallyhidden pour fournir une alternative textuelle (et également échanger l'élément i pour un span car i comporte une signification sémantique ):
<span class="icon icon-star star-4"> <span class="visuallyhidden">4 out of 5 stars</span> </span>
Désormais, lorsqu'un lecteur d'écran rencontre ce contenu, l'alternative textuelle .visuallyhidden sera annoncée, fournissant un contenu permettant à l'utilisateur de comprendre la note actuelle du produit :
"4 étoiles sur 5"
Navigation hors écran
Un modèle courant pour la conception Web de nos jours consiste à masquer la navigation principale dans un "tiroir hors écran", basculé par un contrôle de menu hamburger. Ce modèle est généralement mis en place pour un petit écran ou un contexte mobile, bien qu'il ait également été observé sur les sites de bureau.
Un problème d'accessibilité avec ce modèle survient lorsque le conteneur de contenu du tiroir est positionné hors écran via la propriété de position CSS uniquement. Le menu est dissimulé visuellement, cependant, lorsqu'une personne utilisant un clavier navigue dans le contenu de la page, ces liens visuellement "cachés" seront toujours focalisables, créant essentiellement des taquets de tabulation cachés. Il s'agit d'un problème car l' utilisateur du clavier uniquement n'est pas en mesure de déterminer la position actuelle de la mise au point sur l'écran et peut devenir confus ou frustré.
Masquer complètement le contenu
Afin de masquer complètement le contenu des utilisateurs voyants, des utilisateurs de clavier uniquement et des utilisateurs de lecteur d'écran, nous pouvons utiliser quelques méthodes :
- L'application de l'
display: noneau conteneur du tiroir produira l'effet souhaité en masquant le contenu des utilisateurs du clavier. Une note sur cette solution est que la propriétédisplayne peut pas être animée sans un JavaScript supplémentaire définissant la valeur de la propriété à un moment précis. - L'application de la propriété CSS
visibility: hiddenproduit essentiellement un résultat similaire à l'utilisation dedisplay: none. La différence ici est que la propriété de visibilité est plus facile à animer, en particulier lorsqu'elle est utilisée avec la propriété CSS opacity. - Enfin, l'application de l'attribut
hiddenHTML au conteneur du tiroir produirait le même résultat que l'display: nonepropriété ; cachant complètement le contenu aux utilisateurs visuels et non visuels.
S'il est visuellement masqué, masquez-le également des utilisateurs du clavier et des technologies d'assistance
Le but est d'assurer une expérience utilisateur égale. Si quelque chose est visuellement masqué, ce contenu doit également être masqué pour l'accès au clavier et au lecteur d'écran.
Critères de réussite WCAG
Cela revient à 2.4.3 : Focus Order qui stipule :
"Si une page Web peut être parcourue de manière séquentielle et que les séquences de navigation affectent le sens ou le fonctionnement, les composants focalisables reçoivent le focus dans un ordre qui préserve le sens et l'opérabilité."
Avertir l'utilisateur lorsqu'un lien ouvre une fenêtre
Lorsque nous utilisons ou voyons le modèle target="_blank" rel="noopener" dans un lien, il est de notre responsabilité en tant qu'auteurs Web d'inclure un avis indiquant que le lien ouvre une nouvelle fenêtre.
Pourquoi? Sans ce contexte, les utilisateurs pourraient croire qu'ils suivent un lien de site interne dans la même fenêtre de navigateur. L'ouverture d'un nouvel onglet au nom de l'utilisateur entraînerait un travail supplémentaire pour les utilisateurs voyants au clavier et les utilisateurs de lecteurs d'écran. S'ils ne sont pas prêts à quitter le site actuel, ils devront faire l'effort de revenir à l'onglet ou à la fenêtre précédente.
Donnez le pouvoir à l'utilisateur : laissez-le décider comment il souhaite procéder
L'idée est de donner du pouvoir à l'utilisateur ; informer l'utilisateur de ce qui pourrait se passer afin de lui permettre de décider comment et quand il souhaite procéder.
Comment accomplir cela
Une solution recommandée pour informer les gens qu'un lien ouvre une nouvelle fenêtre consiste à :
- Ajout d'un nouvel élément conteneur au DOM qui héberge les variantes requises du message d'avertissement
- Chaque élément de variante aura un
IDREFunique à référencer ailleurs dans l'application - Lorsqu'un lien comporte les
target="_blank" rel="noopener", ajoutez l'attributaria-describedbydedicatedby, en définissant sa valeur sur l'idapproprié du message à annoncer
Passons en revue un exemple réel pour mieux comprendre ce qui est impliqué.
Exemple de modèle
Tout d'abord, ajoutez le conteneur HTML (alias feuille de sprite de lecteur d'écran) qui contiendra les variantes du message d'avertissement :
<div hidden> <span id="new-window-0">Opens in a new window</span> <span id="new-window-1">Opens an external site</span> <span id="new-window-2">Opens an external site in a new window</span> </div> Vous remarquerez peut-être que ce conteneur div comporte l'attribut hidden . Cela permet de s'assurer que ce morceau de texte n'est pas visible et que les lecteurs d'écran ne peuvent pas trouver et lire le texte hors contexte.
Maintenant que nous avons ces messages d'avertissement disponibles, nous pouvons facilement les référencer si nécessaire.
Ensuite, y compris le message d'avertissement dans un lien.
<a href="https://mysite.com" target="_blank" rel="noopener" aria-describedby="new-window-0" > My site </a>
Avec l'attribut aria-describedby dedicatedby pointant vers le premier élément de message d'avertissement, le lien indique :
"Mon site — S'ouvre dans une nouvelle fenêtre"
(Remarque : le tiret long ici est juste pour souligner que aria-describedby génère une pause entre le texte du lien et le contenu du message d'avertissement.)
Avec cela en place, le texte du lien sera lu à haute voix, une pause, puis le message d'avertissement indiquant que le lien ouvre une nouvelle fenêtre.
Qu'en est-il d'une affordance visuelle ?
J'ai mentionné plus tôt les utilisateurs voyants du clavier uniquement. Comment informer visuellement un utilisateur voyant qu'une nouvelle fenêtre va s'ouvrir ?
Une approche consiste à utiliser une icône à côté du texte du lien. Avec une icône, un utilisateur voyant sera averti que quelque chose de différent pourrait se produire lorsque j'activerai ce lien.
Je ne pense pas qu'une icône soit requise dans tous les contextes, comme une liste de liens d'icônes de médias sociaux, ou peut-être des liens de style copyright dans une section de pied de page. En ce qui concerne les liens dans le corps du texte, cependant, c'est une bonne idée d'ajouter une sorte d'indicateur visuel, tout comme les personnes utilisant un lecteur d'écran reçoivent un avis sonore.
Un exemple d'indicateur visuel
Disons que vous avez une icône qui convient. Habituellement, une icône carrée avec une flèche pointant vers le haut, similaire à l'icône Shopify Polaris External Link .
Maintenant que nous avons notre icône, incluons-la dans le lien :
<a href="https://mysite.com" target="_blank" rel="noopener" aria-describedby="new-window-0" > My site <svg role="presentation" aria-hidden="true" focusable="false" ...> <path> <!-- ... --> </path> </svg> </a>
Avec l'attribut aria-describedby dedicatedby sur le lien ainsi que l'icône "nouvelle fenêtre" à côté du texte, tous les utilisateurs pourront prendre une décision éclairée si et quand activer le lien, maintenant ou plus tard lorsqu'ils seront prêts.
Critères de réussite WCAG
Cela revient à 3.2.2 On Input qui indique :
"La modification des paramètres d'un composant de l'interface utilisateur n'entraîne pas automatiquement un changement de contexte, sauf si l'utilisateur a été informé du comportement avant d'utiliser le composant."