Aller au contenu

Sujets conseillés

Posté

bonjour à tous.

A l'occasion d'un échange que j'ai eu avec Laurent Denis sur le blog d'alsacreation, ce dernier a évoqué le fait que title pouvait poser des problème quant à l'accessibilité. Je serais vraiment intéressé d'en savoir plus.

Si quelqu'un veut bien m'aider.

Merci

Posté

Hum... tu pourrais nous fournir un lien vers cette discussion ? Je serais curieux de savoir ce qui a motivé cette affirmation de Laurent... parce qu'à priori, la seule raison que je puisse imaginer, ce serait que le title fautif soit simplement mal exploité. Parce qu'en terme d'accessibilité, un title bien exploité ne peut qu'être bénéfique il me semble...

Posté (modifié)

La discussion ( http://www.alsacreations.com/blog/index.ph...-et-sigles#c832 ) portait sur la manière d'ajouter une information sur le sens d'un mot, à l'aide d'un code du type :

<span title="une petite explication">le mot</span>

(Sachant que le mot en question n'est pas une abréviation et qu'abbr ne se justifiait pas plus qu'un autre balisage plus précis).

Cet emploi de span est correct:

- span est un élément neutre sémantiquement, destiné à permettre d'ajouter de la structure lorsqu'aucun élément HTML plus précis ne convient

- title est un attribut destiné à ajouter un information, notament textuelle.

Mais avec des réserves sur l'accessibilité : pour que l'information soit accessible, encore faut-il que l'attribut title soit restitué. Or :

- Les navigateurs graphiques le feront lorsque le mot sera survolé, ce qui suppose que l'utilisateur en ait l'idée, et la possibilité. On peut le lui suggérer avec la présentation CSS qui convient (curseur, soulignement), mais ce sera impossible pour celui qui ne peut pas utiliser la souris (handicap moteur).

- Les navigateurs textes ne restituent pas le title

- Les lecteurs d'écrans ne restituent pas le title d'un élément span, sauf erreur de ma part, et Opera 7.60 ne le lit pas.

- Qu'en est-il sur un mobile ?

Bref, title est un moyen apparemment très séduisant, mais à utiliser, AMHA, avec prudence sur les éléments autres qu'abbr et a : l'information donnée doit être un "plus", et son absence ne doit pas compromettre la compréhension du document.

Modifié par LaurentDenis
Posté

Je réalise qu'alors que vous parlez de l'attribut title, j'avais compris initialement que nous parlions ici de l'élément HTML <title>... ça change le débat ! ^_^

Ceci dit, je suis plus ou mons d'accord avec Laurent, dans la mesure ou, partout ou l'attribut title est interprété, il s'avère un plus indéniable pour l'accessibilité.

Ceci étant dit, il est vrai que Jaws, pour ne pas le nommer, ne prend pas en considération l'attribut title par défaut (c'est donc dire qu'il ne le supporte pas à moins que l'utilisateur aille jouer dans ses configurations logicielles); l'utiliser partout comme un gage d'accessibilité serait donc faussé pour certains utilisateurs - notamment ceux qui en auraient le plus besoin...

Ainsi, là ou je rejoins Laurent, ce serait de condamner une pratique qui mise à 100% sur la fiabilité de cet attribut.... ce serait aussi trompeur que de croire aveuglément aux accesskeys, qui malhré la promesse d'un monde meilleur, continuent de faire atrocement défaut à certains d'entre nous.

Posté

Et là je pose une question bête : comment alors donner des précisions accessibles aux navigateurs textes qui ne prennent pas en compte title ?

Posté

un lien direct

<a href="#gouttereaux" title="définition de gouttereaux">gouttereaux</a>

puis en bas de page

<h3>Définitions</h3>

<dl>

<dt id="gouttereaux">gouttereaux: </dt>

<dd>murs latéraux portant les gouttières</dd>

</dl>

c'est jouable non ?

Posté

Les possibilités sont nombreuses, mais l'essentiel est de placer l'info quelque-part "en dur" comme texte HTML, hors attribut, en effet.

- notes (au fil du texte sans CSS, joliments positionnés dans une colonne adjacente au texte avec CSS)

- parenthèses

- page de glossaire et d'aide, avec lien direct

- à la limite, pourquoi pas des popups sur un intranet, si le lien va sur l'entrée correspondante du glossaire en l'absence de javascript

- etc.

C'est assez frustrant de ne pas exploiter pleinement title sur les éléments pour lesquels il n'y a pas de comportement systématique du navigateur... Mais encore une fois, si l'information n'est qu'un "ajout" non essentiel à la compréhension du contenu, c'est différent.

Posté

Laurent Jouanneau ( http://ljouanneau.com/blog/ ) avait publié une solution comparable, avec un javascript non obstructif si ma mémoire est bonne.

Pour celle que tu signales, il faut voir en effet ce que ça donne en remplaçant display:none par une solution accessible du type clip.

Cela dit, j'ai des problèmes de rémanence du tool-tip dans Opera (pas testé plus avant dans d'autre navigateurs).

Enfin, et surtout, ça reste inaccessible pour qui ne navigue qu'au clavier dans un navigateur graphique, comme la plupart des :hover sur autre-chose que des liens...

La meilleure page accessible est finalement plutôt "plate".

Posté
Enfin, et surtout, ça reste inaccessible pour qui ne navigue qu'au clavier dans un navigateur graphique, comme la plupart des :hover sur autre-chose que des liens...

Et en rajoutant un :focus en plus du :hover ?

Posté

le pseudo-sélecteur :focus n'étant pas supporté par MSIE, et la plupart des synthétiseurs vocaux ne fonctionnant qu'en surcouche de MSIE, le tout ne me semble pas la solution idéale... :(

Posté

Par rapport à l'intervention de sibelius

Et là je pose une question bête : comment alors donner des précisions accessibles aux navigateurs textes qui ne prennent pas en compte title ?

Je me permet de proposer l'idée suivante, qui ne résoud certainement pas tout (et je me demande d'ailleurs comment il pourrait en être autrement vu la panade que vous me faites découvrir :( )

soit 1 lien :

<a href="page" title="decription explicite du contenu visé">lien</a><span class="textcomment">(decription explicite du contenu visé)</span>

avec en CSS :

.textcomment {

display:none;

}

Posté

J'ai parlé de "panade" mais il va de soi que toutes ces informations sont très précieuses.

je vous remercie donc tous pour vos interventions.

Posté (modifié)

Ba tant pis

j'avais fait le test avec le Lynx Viewer, et là ça marchait (mais bon ça aurait été trop beau)

A propos personne n'aurait une liste exhaustive de liens pour tester ce que l'on fait par rapport à toutes les configurations possibles ? :D

Modifié par clb56
Posté
Non justement : le display none pose des problèmes car il est pris en compte aussi par les navigateurs textes.

Heu... le clavier de Sibelius a fourché et trahit son maître, qui voulait dire que display:none est pris en compte par les lecteurs d'écran et autres médias vocaux. Les navigateurs textes n'étant pas graphiques, ignorent tout CSS ;)

Posté
Heu... le clavier de Sibelius a fourché et trahit son maître, qui voulait dire que display:none est pris en compte par les lecteurs d'écran et autres médias vocaux. Les navigateurs textes n'étant pas graphiques, ignorent tout CSS ;)

Oui, maintenant que tu le dis, ça paraît plus que logique en effet.

J'ai vraiment des problèmes psychomoteurs avec mon clavier en ce moment.

Quel est donc le problème du display: none alors ?

Posté (modifié)

display n'est pas une propriété spécifique au media screen (ou à tout autre media "visuel"). C'est une propriété qui agit quelque-soit le media, et donc aussi bien dans un navigateur vocal (Opera) à travers une CSS "all". Cependant, elle ne doit pas agir sur un navigateur vocal dans une CSS "screen".

Mais ceci se double d'un comportement erroné des lecteurs d'écrans (Jaws...) qui ne sont pas des navigateurs, mais des synthétiseurs vocaux dépendant du navigateur graphique pour accéder au contenu Web : ils interprètent partiellement les CSS <edit>ou reçoivent le résultat de celle-ci</edit> quelque-soit le media, et appliquent la propriété display:none dans un certain nombre de cas. Les combinaisons de ces cas selon les lecteurs sont telles qu'un display:none dans une CSS "screen" masque toujours du contenu à au moins un lecteur d'écran.

Tant qu'on y est : visibility:hidden est au contraire une propriété uniquement visuelle, théoriquement sans effet dans un media vocal. De fait, elle est ignorée par Opera. Mais là encore, il y a un bug des lecteur d'écran qui leur fait appliquer ce visibility:hidden de la même manière que le display:none.

En bref :

- display:none ne doit jamais être utilisé pour masquer du contenu dans un lecteur d'écran, et c'est normal dans une CSS "all", mais dû à un bug dans une CSS "screen".

- visibility:hidden ne doit pas être utilisé non plus, mais cette fois uniquement en raison d'un bug.

Le Web "aural" en est encore à ses premiers balbutiements...

Modifié par LaurentDenis
Posté

Bonjour,

Je profite de l'occasion pour rappeler la différence, avec un navigateur graphique, entre les deux propriétés :

display: none;

    cette valeur fait qu'aucune boîte n'est générée par l'élément dans la structure de formatage (c.à.d., cet élément n'a pas d'influence sur la mise en forme du document). Les éléments qui en descendent ne génèrent pas de boîtes non plus ; on ne peut plus modifier leur comportement avec la propriété 'display'.

    Noter qu'une valeur 'none' ne crée pas de boîte invisible, elle ne crée pas de boîte du tout. CSS comprend des mécanismes permettant la génération de boîtes dans la structure de formatage, boîtes qui influencent la mise en forme mais qui ne sont pas visibles. Consulter la partie traitant de la visibilité pour les détails

visibility: hidden;

La propriété 'visibility' spécifie le rendu, ou non, des boîtes générées par un élément donné. Ces boîtes, bien qu'invisibles, influencent toujours la mise en forme du document (utiliser la propriété 'display' avec la valeur 'none' pour prohiber la génération d'une boîte, et ainsi toutes influences sur la mise en forme).

hidden La boîte générée est invisible (entièrement transparente), mais celle-ci influençant toujours la mise en forme

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...