web-dev-qa-db-fra.com

Comment résoudre le problème d'accessibilité UX vs lecteur d'écran?

J'apprends le développement web et le balisage html sémantique. Récemment, un didacticiel a suggéré que, parce que les textes d'ancrage "Cliquez ici" ou "En savoir plus" ne sont pas si descriptifs pour les utilisateurs malvoyants en fonction des lecteurs d'écran, il convient d'envelopper la partie descriptive du texte avec des balises d'ancrage plutôt que le CTA.

Par exemple, <a href="">Click here</a> to know more information about the trips. n'est pas bon selon le tutoriel et devrait être Click here to know more <a href="">information about the trips</a>. Cela crée un certain problème où l'utilisateur visuel peut vouloir cliquer sur Click here texte mais rien ne se passera.

Comment résoudre ce problème au niveau UX où les personnes malvoyantes et les personnes visuellement capables peuvent accéder à la page sans effort?

1
Bluebug

Vous évitez de "cliquer ici" parce que tous les utilisateurs n'utiliseront pas une souris (en particulier maintenant beaucoup de gens utilisent des écrans tactiles et "tapent") et utilisent simplement l'ancre avec un texte sensible qui peut être autonome lorsqu'il est présenté hors contexte.

<a href="">More information about the trips</a>.
1
Owain

Ce n'est pas vraiment un problème UX vs lecteur d'écran. Les phrases de lien ambiguës ne sont pas seulement un obstacle à l'accessibilité, mais aussi des problèmes de base d'utilisation et de lisibilité. Les liens descriptifs profitent à tous.

Il n'est généralement pas nécessaire d'inclure des expressions verbales comme "cliquez ici" dans un lien. Le style doit rendre les liens distinctifs et faciles à reconnaître de leur propre chef, sans instruction écrite explicite de cliquer. Il ajoute simplement du bruit et des répétitions supplémentaires, et force les utilisateurs à lire le contenu environnant afin de comprendre le but d'un lien.

Pour illustrer l'un des problèmes que les expressions de liens génériques causent spécifiquement aux utilisateurs de lecteurs d'écran, voici un exemple de page avec de nombreux liens non descriptifs. L'utilisateur n'a aucun moyen de savoir où vont ces liens.

Example of generic "click here" links in a screen reader Links List

Il est de loin préférable que chaque lien soit auto-descriptif, de sorte qu'il ait toujours un sens en soi lorsqu'il est retiré du contexte d'origine. Cela permet aux utilisateurs de lecteurs d'écran de naviguer, mais rend également le contenu plus lisible et les pages plus lisibles par les utilisateurs voyants.

0
Matt Obee

Les boutons "Cliquez ici" sont généralement situés dans un bloc du dessin; il est courant d'avoir une liste d'articles avec CTA "Cliquez ici" sur chacun. Dans ce cas, l'élément entier doit être un lien et pas seulement "Cliquez ici"

Dans un corps de texte, le texte "Cliquez ici" ne doit pas être utilisé. Imaginez cet exemple de texte:

L'étude a montré que les résultats de foo étaient cohérents avec la barre. <a>Click here for a link to the study</a>.

ou

Le <a>study on foo</a> affiche des résultats cohérents avec la barre.

Le deuxième exemple n'est pas seulement meilleur pour l'accessibilité et le référencement mais il est également beaucoup plus lisible car il n'appelle pas un lecteur à l'action. Si l'utilisateur veut en savoir plus, il sait où cliquer car il s'agit d'un lien.

Enfin, si vous devez absolument avoir des liens CTA "Cliquez ici", vous devez apprendre à utiliser correctement attributs ARIA .

Si vous souhaitez utiliser un texte de lien ambigu, vous devez utiliser le aria-label attribut pour donner un contexte au lien. Dans un exemple sur texte de lien significatif de UoW, ils suggèrent:

<a href="post.php?post=632" aria-label="More on Using Meaningful Link Text">More...</a>

0

Comme indiqué dans http://ux.stackexchange.com/a/127688/32746 , craignez de montrer le mot "click" aux personnes qui tapent:

<a href="">Know more information about the trips</a>

Les malvoyants seront informés qu'il s'agit d'un lien.

Tant que votre code HTML est correct au démarrage de votre page et que l'exactitude est détenue par les codes de script en direct potentiels, il ne devrait pas y avoir de problème.

0
32746