Accueil > weblog
- Lire le billet précédent - Lire le billet suivant -
Par Laurent Denis, le 01 mars 2005.
Il est d'usage, selon les recommandations d'accessibilité, d'éviter ce que l'on appelle les liens adjacents, c'est à dire deux éléments a qui se succèdent dans le code (X)HTML sans être séparés par au moins un caractère imprimable ou une image doté d'un attribut alt. En effet, dans diverses configurations de lecteurs d'écran, il sera difficile pour l'utilisateur de distinguer deux liens adjacents, faute d'un séparateur audible. Que ces liens soient éventuellement contenus dans des éléments parents distincts ne change rien au problème, la seule exception étant lorsque ces liens sont contenus dans des items de liste li.
Le souci louable de respecter cette règle d'accessibilité se double souvent de préoccupations esthétiques tout aussi louables : plutôt que la traditionnelle barre verticale |, de nombreux sites utilisent une combinaison de signes de ponctuation ou d'autres caractères plus ou moins exotiques. Quelques exemples, rencontrés au fil de mes lectures :
Ces combinaisons de signes donnent effectivement un résultat agréable à l'oeil, tout en constituant d'indiscutables séparateurs à l'écoute... Le seul petit problème est qu'ils sont justement un peu trop indiscutables, en fait !
En effet, qu'entendons-nous avec les exemples ci-dessus ?
lien un deux points deux points deux points lien deux
lien un deux points barre deux points lien deux
lien un point deux points point lien deux
link one right double angle bracket right double angle bracket link two(j'emprunte cet exemple à un site anglo-saxon)
Ces rendus auditifs sont évidemment variables selon le lecteur d'écran ou le navigateur vocal, et selon leur configuration. Mais l'essentiel demeure : croyez-vous vraiment qu'il soit agréable d'endurer ces énumérations de signes de ponctuation tout au long de vos pages ?
Là où un simple signe unique ferait parfaitement l'affaire pour ce qui est de l'accessibilité, nous rendons parfois involontairement la lecture de nos pages singulièrement pénible... Alors, s'il vous-plaît :
Précisons qu'il doit bien traîner sur ce blog quelques séparateurs de ce type : c'est une chose que l'on ne découvre qu'à l'usage, et mon expérience d'utilisateur d'aides vocales est trop récente pour que j'ai pu tous les identifier et les corriger ici.
Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.
Commentaires
YoGi, le 01 mars 2005
Très intéressant !
pour les fans des "::", il doit même y avoir moyen d'en faire des images et d'indiquer pour texte alternatif un séparateur simple comme une virgule.
Laurent Denis, le 01 mars 2005
YoGi, ton commentaire et la mise à jour de mon billet se sont croisées
C'est en effet un des cas où la mise en image d'un contenu textuel est une excellente mesure d'accessibilité, contrairement aux habitudes acquises.
Nico, le 01 mars 2005
Pour ma part, ce sont plutôt les crochets que j'utilise [].
Simple question : existe-t-il un navigateur en mode vocal téléchargeable librement pour mieux comprendre ce genre de problèmes ?
Laurent Denis, le 01 mars 2005
Oui, les crochets sont aussi "neutres" que la barre verticale. Quoique peut-être un peu plus "lourds"... C'est assez subjectif, je crois, à ce stade.
Sinon, pour tester ses pages dans un lecteur d'écran:
La dernière version de Jaws est téléchargeable sur le site de Freedom scientific en version limitée à 40mn d'utilisation après lancement d'une session Windows:
www.freedomscientific.com...
De même, une version ancienne d'IBM HPR peut être utilisée pendant 1 mois gratuitement:
www-306.ibm.com/able/solu...
Opera 8.0 vocal est gratuit, mais ne donne pas une idée exacte du fonctionnement d'un lecteur d'écran (Du point de vue interaction, il ne fonctionne pas du tout comme un lecteur d'écran).
AMHA, IBM HPR est la solution la plus facile pour se faire une idée de ces problèmes : Jaws est plus complexe, et nécessite une prise en main plus longue.
Laurent Denis, le 01 mars 2005
Tiens, à la réflexion : si les lecteurs d'écran implémentaient CSS speech, il me semble qu'il suffirait d'une petite feuille de style "user" pour forcer un lien adjacent à un lien précedent à être précédé d'un signal sonore (propriété cue-before)...
A vérifier, mais si je me trompe pas, c'est un bon exemple de l'importance de CSS pour les futurs lecteurs d'écran
[Mise à jour] Oubliez-ça. Cela ne serait possible que pour les liens ayant le même élément parent.
Steph. K., le 01 mars 2005
Sinon pour ceux qui préfère un truc visuel : Fang
Ca ne remplace pas un lecteur d'écran mais c'est plus rapide.
ps. C'est une extension pour Firefox/Mozilla qui affiche ce qu'un lecteur d'écran est sensé lire.
Laurent Denis, le 01 mars 2005
Steph, je me suis permis d'éditer ton commentaire pour rétablir plus simplement le lien vers l'extension Fang.
Oui, Fang est une simulation possible, mais ce n'est qu'une simulation. L'expérience réelle d'une page **écoutée** sans repère visuel n'a rien à voir avec une simulation. Cela me rappelle l'époque où on disait que Lynx donnait une bonne idée de la navigation avec un lecteur d'écran. A l'usage, c'était une grosse sottise.
giz404, le 02 mars 2005
Pour ma part, j'utilise soit | soit le signe • , qui fait un gros point à mi-hauteur.
Groumphy, le 03 mars 2005
Ne serait-il pas plus intéressant quelques fois d'utiliser une liste à puce mise en Display: inline; pour ce type de lien suivis ?? (Question un peu... Interrogative elle-même ! Et certainement remplie d'incertitude...).
Philippe Worontzoff, le 04 mars 2005
"L'expérience réelle d'une page **écoutée** sans repère visuel n'a rien à voir avec une simulation."

est surement entendu de la sorte :
"L'expérience réelle d'une page étoile étoile écoutée étoile étoile sans repère visuel n'a rien à voir avec une simulation."
Quand à "pour ce type de lien suivis ??", je me demande si le deuxième point d'interogation est dit.
Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.