Jaws : on fait le point ?

Bonjour à tous,

Cela fait un moment que je me pose beaucoup de questions à propos du lecteur Jaws (le fait de l'avoir testé chez moi ne les résoud pas toutes).

Je me suis dit que d'autres personnes doivent certainement aussi se poser des questions quant à l'utilisation de cet outil et du coup, je pense réunir ici une véritable Fiche Pratique (une sorte de tuto quoi) qui expliquerait tout que ce tout le monde veut savoir sur Jaws sans oser le demander.

Tout le monde (surtout s'il est utilisateur de Jaws) est invité à participer à ce sujet. J'aimerais au final regrouper les informations sous forme de Tutoriel que l'on pourrait héberger chez Web-pour-tous (si l'équipe WPT est d'accord).

Voici la trame (que je modifierai au fur et à mesure de vos informations) :

----------------
JAWS : Fiche Pratique pour les Webmasters soucieux de l'accessibilité de leur site

1) L'environnement et le fonctionnement de Jaws
- Ce qu'est Jaws, comment il s'installe et fonctionne.
- Combien il coûte (y'a-t-il des aides, des compensations financières ?)

2) Utilisation "classique" de Jaws
- Comment un utilisateur "lambda" navigue-t-il avec Jaws par défaut ?
- Quels sont les autres manières de naviguer ? (par liens, par titre, par...). Sont-elles fréquemment employées ?

3) Jaws et les "techniques d'accessibilité" pour l'utilisateur "lambda"
- Les liens d'évitement sont-ils utiles et employés sous Jaws ?
- La page de politique d'accessibilité est-elle utile et employée sous Jaws ?
- Les Accesskeys sont-ils utiles et employés sous Jaws ?
- Les Tabindex, la navigation par la touche Tab sont-ils utiles et employés sous Jaws ?

4) Jaws et les techniques HTML
- Comment Jaws traite l'attribut "alt" sur les images ?
- Comment Jaws traite l'attribut "title" sur les éléments et les images ? Que se passe-t-il si title et alt sont présents ?
- Comment Jaws traite-t-il les liens sans contenu textuel, mais accompagnés d'un title ?
- Comment Jaws traite les règles CSS "display:none" et "visibility:hidden" ?
- Comment Jaws perçoit la séparation fond (HTML) / forme (CSS) ? Est-ce un réel apport dans la facilité de navigation ?

5) Jaws et les CSS2 de média Aural/Speech
- Comment Jaws traite-t-il le média vocal ?
- Le media speech en CSS2 apporte-t-il un réel confort sur Jaws ?
- Quelles propriétés peuvent être utiles pour l'utilisateur "lambda" ?

6) Les obstacles
- Quels sont les obstacles sur lesquels butte Jaws ? En clair, quelles sortes de sites web, quelles genres de pages, sont difficiles d'accès ?
Modifié par Raphael (30 Sep 2005 - 16:55)

JAWS for Windows Headquarters (en) (y a un bug d'affichage sous FF )

HTML Support in various screenreaders (ALA #203) (l'article parle des PDF et de leur accessibilité, ce qui concerne le Sujet c'est uniquement la section "Screen readers" et ses 3 tableaux comparatifs)

EDIT: Wikipedia - Jaws (logiciel pour mal-voyants) (fr)
Modifié par Felipe (03 Oct 2005 - 01:01)

Merci Felipe, la FAQ française est une piste intéressante aussi : http://sonobraille.free.fr/jaws/faq.php

Mais aucun de ces liens ne répond vraiment aux questions précises posées dans le 1er message.

Donc ce serait vraiment intéressant si des utilisateurs quotidiens de Jaws passaient par ici

Selon le lien de Felipe (ALA), voici le support HTML des différents lecteurs d'écran :

Jaws v4 : titres (H*), longdesc, accesskey, onmouseover et onclick, table header (th), fieldset, legend, accesskey vides

Window-Eyes : frames, tables with headers, accesskey, abbr, acronym, title (and alt ) on form elements, headings, language codes, lists, longdesc, object, q, blockquote, thead, tbody, tfoot while navigating through table cells; th, select frames by document title or frame name, title, or longdesc, title on most, if not all, elements (also alt)

IBM Home Page Reader : caption, headers, and summary for tables, alt for images and areas, title and longdesc for images, noframes and noscript, apparently also understands “paragraphs, table cells/rows/columns, headings… lists, forms, maps, and select menus”, “HPR supports HTML 4.0 including common deprecated elements, but not SMIL, CSS, MathML, or DOM”, label for select, optgroup, legend for fieldset, title attribute for abbr and acronym, cite attribute for blockquote, ruby (!), meta refresh, Flash objects and the title for object, frame title and longdesc, table summary, disabled attribute for form controls, mouse and keyboard event handlers (such as onmouseover, onclick, onkeypress), start attribute for ol, readonly attribute for input and textarea, accesskey, tabindex, maxlength attribute for input, “unsupported lang attributes by providing a setting to announce, but not speak, text which requires speech engines not available with HPR, such as Greek”
Modifié par Raphael (30 Sep 2005 - 14:24)

Bonjour tous,

Pour ma part cela ne pose pas de problème au contraire.

Voilà ce que wpt a sur JAWS

http://xavier.claudet.free.fr/raclav.htm

http://www.wats.ca/resources/jawskeystrokes/9

Comme JAWS peut être utilisé avec LYNX je crois, au cas ou, je rajoute cela mais juste au cas où car ce n'est pas le suje tinitial.

http://perso.wanadoo.fr/winaide/lynx_doc.html

http://dominique.guebey.club.fr/tekno/lynx/index.htm


Dans les questions je rajouterais peut être le cas de la balise <link> car je crois que JAWS les prends en compte.
Modifié par knarf (30 Sep 2005 - 15:40)

a écrit :
Selon le lien de Felipe (ALA), voici le support HTML des différents lecteurs d'écran :

Précision importante :
Ces tableaux représentent les éléments html dont le support a été ajouté

a écrit :
HTML support added

Jaws supporte parfaitement alt, title par exemple.

Jean-pierre

jpv a écrit :
Jaws supporte parfaitement alt, title par exemple.

Ah ok, c'est effectivement important à savoir.

En tout cas, toutes les réponses à mes questions précises sont les bienvenues

Pour jaws on peut signaler également l'excellent base de connaissance sdu support technique, par exemple cet item

Tips on HTML code and expected behavior from JAWS (en)

Jean-pierre

jpv a écrit :
Pour jaws on peut signaler également l'excellent base de connaissance sdu support technique, par exemple cet item

Tips on HTML code and expected behavior from JAWS (en)

Jean-pierre

Ah oui, j'y trouve quelques réponses à mes questions :

a écrit :
Any elements that use a style with the attributes "visibility:hidden" or "display:none" are not included in the JAWS rendering of the page. However, if the page has elements shown when it first loads, but then dynamically hides these elements without user intervention after the page loads, JAWS does not detect that this has occurred and may still show the hidden content. Conversely, if a page hides content when it first loads but then dynamically shows this content after the page loads, JAWS does not announce the new content.

En clair :
- "visibility:hidden" et "display:none" font que l'élément ne sera pas pris en compte par Jaws
- Si l'élément est visible au chargement de la page, puis effacé de façon dynamique (ex: un menu déroulant). Il restera pris en compte par Jaws.
- Si l'élément est invisible au chargement de la page, puis affiché de façon dynamique. Il restera "invisible" sous Jaws.

a écrit :
Does JAWS support the "media" attribute, within the link tag, for cascading stylesheets (CSS)?

A: Partially. JAWS supports "@media" for display. All other media types are currently ignored. Thus, it should be possible to create stylesheets specifically for Braille output devices by indicating the media type through the "media" attribute.

a écrit :
How can I expect JAWS to handle JavaScript on my Web page?

A: JAWS will work correctly with JavaScript if:

* The scripts are activated by clicking a link or clickable item and the script dynamically updates the HTML source.
* The scripts do not update the page without user intervention.

En clair :
- Jaws reconnaît le javascript si celui-ci est exécuté par une action volontaire de l'utilisateur

a écrit :
Actually, when you hover the mouse pointer over a link, it may be the TITLE attribute that is actually displayed.

If JAWS cannot find any title or screen text for a link, it looks at the onMouseOver attribute. In the case of a mouse over which looks like the following example, the text within the single quotes would be spoken by JAWS:
<a href="somewhere.html onMouseOver="someFunction('hello there')"></a>

Notice that this link has no screen text.

En clair : un lien hypertexte dénué de texte de contenu (<a href=""></a>) est "lisible" sur Jaws à condition qu'un attribut "title" pertinent y soit ajouté. Ex : <a href="" title="contenu du lien"></a>

J'ai tout juste ?
Modifié par Raphael (30 Sep 2005 - 16:52)

Felipe a écrit :
Wikipedia - Jaws (logiciel pour mal-voyants) (fr)

Wikipédia répond bien à la partie introductive qui est la présentation de Jaws :

Wikipédia a écrit :
Jaws (Job Access With Speech) est un logiciel pour mal-voyants, sous Windows, édité par la société Freedom Scientific. Plus exactement, il s'agit d'un screen reader, un logiciel qui tranforme un texte affiché sur un écran en un texte parlé ou un texte en braille.

Il existe d'autres logiciels dans le même domaine (gratuit ou payant, Windows ou Unix). Jaws permet en plus d'avoir des scripts personnalisés, ce qui lui assure un grand succès dans la communauté des non-voyants utilisateurs de PC.

Microsoft et la société Freedom Scientific sont en partenariat pour le développement du logiciel JAWS.

Ordre de grandeur des prix en 2005

En 2005,

* Version d'essai de 40 minutes, francophone
* Version d'essai pour 2 mois : 40 US $ (ce n'est qu'un ordre de grandeur).
* Version pour XP familial : 900 US $ (ce n'est qu'un ordre de grandeur).
* Version pour Windows XP Professionnel : 1100 US$ (ce n'est qu'un ordre de grandeur).

Les extensions pour SMA (Software Maintenance Agreements) sont payantes.

PS : tiens, j'avais cru lire que Jaws était bien plus chèr que cela.
Modifié par Raphael (30 Sep 2005 - 17:02)

Bonjour,

Knarf > non, Jaws ne supporte pas LINK.

Je reprends votre trame de départ pour être sûr de ne rien oublier.

1) L'environnement et le fonctionnement de Jaws
- Ce qu'est Jaws :
C'est un lecteur d'écran, c'est-à-dire qu'il peut restituer en audio la plupart des éléments présents à l'écran.
IL est prévu pour suivre le focus, c'est-à-dire le curseur système, et lit au fur et à mesure les informations qui se trouvent au focus.
Les commandes principales du lecteur (répéter, lire le mot, lire la phrase, lire le caractère, lire la barre d'état, lire le titre de la fenêtre, lire le contenu sélectionné, etc) sont accessibles par de simples raccourcis clavier composés de deux ou trois touches.
Les commandes un peu moins courantes mais non moins utiles sont disponibles par des raccourcis composés de 4, 5 voire 6 touches.

AFin d'augmenter le nombre de possiblités de raccourcis possibles et pour diminuer les risques d'entrer en conflit avec les raccourcis des applications usuelles (utilisant déjà un grand nombre de raccourcis composés de Ctrl+lettre ou Ctrl+Maj+Lettre), on modifie le fonctionnement de la touche Insert (celle qu'on ne sert jamais qui se trouve au-dessus de la touche Suppr) est modifié pour pouvoir l'utiliser comme Ctrl ou Alt.
Les raccourcis de base de jaws sont donc composés de Insert+lettre (voyez à la fin la liste des raccourcis usuels)

Installation :
C'est un programme d'installation ordinaire, trois clics sur suivant et c'est prêt.
Sa configuration est ensuite particulièrement difficile. Il offre énormément d'options.
Les plus simples à manipuler et à comprendre se trouvent dans le menu options accessible dans la fenêtre de jaws ou par le raccourci Insert+J.
Pour des options plus subtiles, on utilise le Configurateur. Chaque application peut y avoir une configuration différente pour adapter au mieux à leurs spécificités.
Chaque application peut être accompagnée d'un script jaws, un script programmé à l'aide d'un langage spécifique au lecteur d'écran, souvent dénommé jaws-scripting.
Ces scripts sont composés de différentes procédures et chaque procédure peut être attribuée à un nouveau raccourci clavier, pour permettre d'utiliser des fonctionnalités typiques de l'application.

Par exemple, lire l'adresse URL, aller au prochaîn titre, ... pour Internet Explorer.
Ou alors : choisir une police dans la barre d'outils de word... etc.
OU encore : Lire le résultat affiché dans la calculatrice windows.
Enfin on rmearque que les possibilités de tels scripts sont quasiment infinies.


Combien il coûte (y'a-t-il des aides, des compensations financières ??

Environ 2500 CHF soit 1570€. Mais en Suisse par exemple, les assurances sociales prennent en charge.



2) Utilisation "classique" de Jaws dans le cas du Web
- Comment un utilisateur "lambda" navigue-t-il avec Jaws par défaut ?
Il n'y a pas de "par défaut". Chacun a ses habitudes et elles varient beaucoup d'un utilisateur à l'autre.

- Quels sont les autres manières de naviguer ? (par liens, par titre, par...). Sont-elles fréquemment employées ?

Là encore, il y a énormément d'options.
Dans le cas d'Internet Explorer (que j'utilise perso donc) :
- De lien en lien avec Tab.
- De titre en titre à l'aide des touches 1, 2, 3, 4, 5, 6 seules, ou on peut obtenir une liste des titres de la page pour y aller directement.
- de tableau en tableau à l'aide de la touche T
- de liste en liste avec la touche L
- de bloc de texte ne contenant pas de lien ... avec N ou Insert+Entrée selon les versions
- d'élément de formulaire en élément de formulaire avec F (ou B pour les boutons)
- d'image en image avec G

ON peut naturellement se balader avec les flèches comme dans un document Word.
ET il en existe des tas d'autres.


3) Jaws et les "techniques d'accessibilité" pour l'utilisateur "lambda"
- Les liens d'évitement sont-ils utiles et employés sous Jaws ?
Perso, non, je peux éviter les menus avec plusieurs appuis successifs sur N, mais pour les débutants et pour les versions antérieures à la 5.0, c'est toujours utile.

- La page de politique d'accessibilité est-elle utile et employée sous Jaws ?
Là, je comprends pas : la page d'accessibilité est une page comme une autre, qu'on décide de lire ou de ne pas lire... je ne vois pas où il y aurait un problème ?

- Les Accesskeys sont-ils utiles et employés sous Jaws ?
Oui, car ils sont signalés (avec IE) même si le webmaster ne les a pas indiqués clairement.
Lorsqu'un accesskey est rencontré, jaws lira l'intitulé du lien suivi de la combinaison de touche de raccourci.

- Les Tabindex, la navigation par la touche Tab sont-ils utiles et employés sous Jaws ?
Les tabindex buggent sur IE, pour information, donc perso, je recommande de les éviter tant que le parcours de lien en lien par tab vous semble logique. FAites en sorte de ne pas les utiliser.
La navigation générale de lien en lien avec la touche Tab est capitale ! C'est un moyen simple de choisir la prochaîne page qu'on veut visiter sans lire forcément tout le texte.
On peut également obtenir une liste des liens avec Insert+Fx (je ne sais plus si c'est F7 ou F9)


4) Jaws et les techniques HTML
- Comment Jaws traite l'attribut "alt" sur les images ?
Cela dépend des configurations, mais, dans le cas général :
a+img+alt : jaws lira "lien" suivi du contenu de alt, sauf s'il est vide (alt="")

a+img : jaws lira "lien" suivi de l'adresse URL absolue de l'image... pas génial. Si alt="", c'est également le cas.

img+alt : Jaws lira "graphique" ou "image" suivi de l'intitulé, sauf si alt est vide (alt="")

img : si l'image n'est pas un lien et si alt est absent ou vierge, selon la configuration, jaws lira "graphique" ou "image" suivi de l'adresse URL, ou alors, ne dira rien du tout.
Ceci dépend des paramètres fixés dans la partie "HTML" et la partie "Graphiques" du Configurateur.

Il est d'ailleurs possible de modifier l'ordre de lecture des attributs pour faire en sorte qu'un title ait la priorité sur un alt ou l'inverse. Par défaut, alt a la priorité, sauf erreur.

- Comment Jaws traite l'attribut "title" sur les éléments et les images ? Que se passe-t-il si title et alt sont présents ?

J'ai répondu en partie ci-dessus. Sur un lien, title n'est pas lu, et sur un élément autre qu'une image, non plus.

- Comment Jaws traite les règles CSS "display:none" et "visibility:hidden" ?

Lorsque la propriété display est fixée à "none" et/ou la propriété visiblity est fixée à "hidden", d'un élément, il est ignoré et donc n'est pas lu.

- Comment Jaws perçoit la séparation fond (HTML) / forme (CSS) ? Est-ce un réel apport dans la facilité de navigation ?

IL est évident que les sites conçus avec les standards XHTML 1.0 scrict/transitional et séparant donc le contenu de la présentation sont nettement plus accessibles que les autres.
Jaws est d'ailleurs plus rapide à réagir sur des sites standardisés.

5) Jaws et les CSS2 de média Aural/Speech
- Comment Jaws traite-t-il le média vocal ?
- Le media speech en CSS2 apporte-t-il un réel confort sur Jaws ?
- Quelles propriétés peuvent être utiles pour l'utilisateur "lambda" ?

Jaws, en tout cas dans sa version 5.0, ignore TOTALEMENT les propriétés CSS spécifiques aux médias vocaux.
Pour la version 6.0 assez récente, je ne sais pas.

6) Les obstacles
- Quels sont les obstacles sur lesquels butte Jaws ? En clair, quelles sortes de sites web, quelles genres de pages, sont difficiles d'accès ?

Les sites qui ont une structure désorganisée ne sont pas très pratiques.
De nombreuses imbrications de tableaux non justifiés nuisent à l'accessibilité des pages, mais ce n'est pas forcément le cas.
Le genre de sites avec de la pub partout et n'importe comment (exemple telecharger.com)
Les sites qui font apparaître des popup à tout va sans que ce soit justifié (c'est très ch*** le coup de la popup qui interrompt la lecture au milieu d'une page)
Les sites utilisant un rafraîchissement automatique, quelque soit la manière (meta tag, javascript, etc), car jaws recommence en haut de page lorsqu'elle se rafraîchit, et , de ce fait, la lecture est interrompue.

Voilà, désolé d'avoir fait un immense post.

Merci QuentinC pour avoir pris le temps de dégrossir tout ça.

Je reviens sur quelques points flous :

QuentinC a écrit :
- Comment un utilisateur "lambda" navigue-t-il avec Jaws par défaut ?
Il n'y a pas de "par défaut". Chacun a ses habitudes et elles varient beaucoup d'un utilisateur à l'autre.

En fait, quand je dis "par défaut", cela signifie : lorsque le logiciel est utilisé par défaut, sans avoir modifié aucune des options possibles.
Un peu comme les autres logiciels, je présume que la majorité des utilisateurs (donc non avertis comme toi), utilisent Jaws "par défaut".

QuentinC a écrit :
- La page de politique d'accessibilité est-elle utile et employée sous Jaws ?
Là, je comprends pas : la page d'accessibilité est une page comme une autre, qu'on décide de lire ou de ne pas lire... je ne vois pas où il y aurait un problème ?

Oui je me suis très mal exprimé.
En fait la question est... est ce que les utilisateurs de Jaws lisent cette page selon toi ? en clair, s'intéressent-il à la politique d'accessibilité d'un site, à ses raccourcis clavier, etc.
Est-ce que tout bêtement, les utilisateurs de Jaws savent qu'il existe des règles et normes d'accessibilité ? (j'en suis pas si sûr)

a écrit :
Les tabindex buggent sur IE, pour information

Ah bon? De quelle manière ?
J'ai déjà fait des tests pourtant. Y'a t-il des conditions où les tabindex bugguent ?

a écrit :
img+alt : Jaws lira "graphique" ou "image" suivi de l'intitulé, sauf si alt est vide (alt="")

Si alt est vide, Jaws ne lira rien, ou il lira quand-même "graphique" ?

a écrit :
Sur un lien, title n'est pas lu, et sur un élément autre qu'une image, non plus.

Tiens, cela est contraire à ce que je viens de lire et de rapporter plus haut par rapport à la source donnée par JPV :

a écrit :
Actually, when you hover the mouse pointer over a link, it may be the TITLE attribute that is actually displayed.

If JAWS cannot find any title or screen text for a link, it looks at the onMouseOver attribute. In the case of a mouse over which looks like the following example, the text within the single quotes would be spoken by JAWS:
<a href="somewhere.html onMouseOver="someFunction('hello there')"></a>

Notice that this link has no screen text.

En clair : un lien hypertexte dénué de texte de contenu (<a href=""></a>) est "lisible" sur Jaws à condition qu'un attribut "title" pertinent y soit ajouté. Ex : <a href="" title="contenu du lien"></a>

Selon toi, title n'est jamais lu sauf sur une image ?
Qui a raison alors ?

Encore merci pour ces réponses
Modifié par Raphael (30 Sep 2005 - 19:30)

Raphaël a écrit :

En fait, quand je dis "par défaut", cela signifie : lorsque le logiciel est utilisé par défaut, sans avoir modifié aucune des options possibles.
Un peu comme les autres logiciels, je présume que la majorité des utilisateurs (donc non avertis comme toi), utilisent Jaws "par défaut".

Ca ne va pas beaucoup éclairer la réponse : sur le net, on peut naviguer de titre en titre, de lien en lien, etc, comme j'ai dit avant, et ça on peut le faire quelque soit notre config.

Raphaël a écrit :

En fait la question est... est ce que les utilisateurs de Jaws lisent cette page selon toi ? en clair, s'intéressent-il à la politique d'accessibilité d'un
site, à ses raccourcis clavier, etc.

Axu raccourcis clavier, sans doute. Mais il n'y a pas besoin de lire cette page pour les connaître, car jaws les signale juste après les liens auxquels ils se rattachent, même si le webmaster ne l'a pas "écrit" expressément.

Par exemple : <a href="..." accesskey="1">test</a>
ici, jaws lira : "lien test alt+1"

Raphaël a écrit :

Est-ce que tout bêtement, les utilisateurs de Jaws savent qu'il existe des règles et normes d'accessibilité ? (j'en suis pas si sûr)

Moi non plus. Je pense aussi que le 95% des utilisateurs de jaws n'en connaisent pas l'existance.

Raphaël a écrit :

J'ai déjà fait des tests pourtant. Y'a t-il des conditions où les tabindex bugguent ?

Je ne sais pas trop pourquoi ni comment, mais j'ai déjà remarqué un problème de tabindex sur WPT. Je ne connais pas les circonstances mais un moment donné, au lieu d'aller au lien qui devrait précéder logiquement avec maj+tab, il reprend au début...

Raphaël a écrit :

Début balises de citations
img+alt : Jaws lira "graphique" ou "image" suivi de l'intitulé, sauf si alt est vide (alt="")
Fin balises de citations

Si alt est vide, Jaws ne lira rien, ou il lira quand-même "graphique" ?

Ca, ça dépend des configurations. Par défaut, je pense qu'il ne lira rien. mais je n'ai pas envie de remettre mes paramètres par défaut pour tester... c'est trop long à tout reprendre après.

Raphaël a écrit :

Début balises de citations
Sur un lien, title n'est pas lu, et sur un élément autre qu'une image, non plus.
Fin balises de citations

Tiens, cela est contraire à ce que je viens de lire et de rapporter plus haut par rapport à la source donnée par JPV.

C'est peut-être dû à ma config, mais je ne me rappelle pas avoir entendu une fois le contenu d'un title.

Raphaël a écrit :

En clair : un lien hypertexte dénué de texte de contenu (<a href=""></a>) est "lisible" sur Jaws à condition qu'un attribut "title" pertinent y soit ajouté.
Ex : <a href="" title="contenu du lien"></a>

Selon toi, title n'est jamais lu sauf sur une image ?
Qui a raison alors ?

Dans le cas particulier que tu mentionne, c'est exact. Mais dès que le texte du lien contient un espace, c'est fini, title est ignoré.
et pour les images, je rappelle que title n'est lu que si alt est absent ou vide.

Raphaël a écrit :

Encore merci pour ces réponses

Bah, le meilleur moyen d'améliorer l'accessibilité, c'est de coopérer en échangeant des arguments constructifs.
Il n'y a pas de quoi.

QuentinC a écrit :

Dans le cas particulier que tu mentionne, c'est exact. Mais dès que le texte du lien contient un espace, c'est fini, title est ignoré.

Désolé d'en remettre une couche, mais vu que cela me paraît très important, j'aimerais que tu me dises ce qu'il en est des différents cas suivants :

1) <a href="" title="contenu du lien"></a>
2) <a href="" title="contenu du lien"> </a> (juste un espace dans le lien)
3) <a href="" title="contenu du lien">&nbsp;</a> (juste un espace insécable dans le lien)
4) <a href="" title="contenu du lien">un lien</a> (texte contenant un espace)

Dans quel(s) cas le title est-il lu ?

1 : title, soit "contenu du lien"
2 : title, soit "contenu du lien"
3 : title, soit "contenu du lien"
4 : le texte, soit "un lien", title n'est pas lu

Je me suis donc un peu trompé tout à l'heure.

Mais franchement, quel est l'intérêt d'avoir un lien comme en 1, 2, ou 3?
Modifié par QuentinC (30 Sep 2005 - 21:14)

QuentinC a écrit :
Mais franchement, quel est l'intérêt d'avoir un lien comme en 1, 2, ou 3?

Justement, cela permet de faire des "boutons" graphiques sans obligatoirement avoir à employer des techniques de masquage de texte.

Ce tuto par exemple a longtemps été décrié a cause du lien vide.

On a toujours été mis en garde contre les liens vides de texte et leur inaccessibilité aux non-voyants. Du coup, on bidouille des pseudo-textes pseudo-masqués à l'aide de display none, de clip, de décalages hors du document, etc... alors qu'en fait il suffirait de renseigner l'attribut "title".

Mais ce qui vaut pour Jaws ne vaut peut-être pas pour HomePageReader ou les autres, donc c'est peut-être un peu précipité de s'enthousiasmer.
Modifié par Raphael (01 Oct 2005 - 01:14)

Bonjour,

Je n'interviens pas beaucoup pour l'instant (travail sur le forum et le site de wpt avec tous le monde) mais je suis la discussion.

Bonjour,

Raphael a écrit :
Mais ce qui vaut pour Jaws ne vaut peut-être pas pour HomePageReader ou les autres, donc c'est peut-être un peu précipité de s'enthousiasmer.

En effet, inutile de chercher très loin pour casser l'enthousiame éventuel (désolé, Raphaël ):
- navigateur texte : flop.
- navigateur graphique CSS désactivée : flop.
- navigateur graphique options d'arrière-plan utilisateur : flop.
- Jaws, configuration utilisateur différente : flop.
- IBM HPR, selon la configuration utilisateur : flop.
- tablette braille: flop.
- scripts extrayants les liens tels la barre d'accessibilité d'IE ou le panel des liens d'Opera: flop.
- mode lecture de page Opera: flop.
- rendu sur un mobile: flop.
- rendu imprimé: flop.
- mise en favoris dans IE, en signet dans Opera ou en marque-page dans Firefox: flop.
- je continue ?

Idée à oublier, comme toujours quand CSS sert à créer un contenu à la place de HTML, ou que HTML n'est pas employé correctement : l'attribut title n'est pas un équivalent alternatif au libellé du lien, mais une information supplémentaire et optionnelle. Un lien sans libellé n'a pas d'existence.

(A l'inverse, par exemple, title peut être un équivalent alternatif aux labels d'éléments de formulaire, dans certains cas).

Pour des boutons graphiques CSS accessibles et donnant toute liberté graphique, attendre l'implémentation de la propriété content CSS3 telle qu'actuellement dans Opera :

@media screen, projection, tv {
   a[href="..."] {
   content: url(image1.png);
   }
   a[href="..."]:hover {
   content: url(image2.png);
   }
}

<a href="...">Texte du lien</a>

Et pour l'instant, sont accessibles :
- le bouton avec effet au survol, combinant le texte HTML affiché et l'arrière-plan CSS, avec moins de liberté graphique, bien-sûr. Et en pensant à l'utilisateur qui appliquera des couleurs d'arrière-plan spécifiques.
- le bouton sans effet de survol avec une <img src="..." alt="...">. En pensant à l'utilisateur de loupe pour lequel le texte deviendra illisible au-delà d'un certain facteur d'agrandissement, et qui devra passer par l'affichage sans images (Ce qui veut dire qu'il faut des alt assez bref pour ne pas être rognés par la loupe ou le navigateur).
Modifié par Laurent Denis (01 Oct 2005 - 09:09)

Une remarque générale sur le sujet de ce fil : il montre bien la difficulté à tenter de savoir ce qu'on pourrait faire ou ne pas faire à partir du comportement précis d'un ou de quelques utilisateurs, et non à partir du comportement par défaut et de ce que prévoient les normes d'accessibilité synthétisant des tests beaucoup plus étendus :
- l'utilisateur est très rarement au courant de ses propres options et des possibilité de son lecteur, en dehors de sa configuration particulière. Voire également des différences entre sa configuration et celle par défaut.
- il ne sait pas, souvent, ce que fait exactement le lecteur (a-t-il lu un title ou un intitulé ? Pour ma part, je n'en ai en général pas la moindre idée et je m'en contre-fiche quand j'utilise Jaws. Comme vous moquez de savoir si vous lisez un <p> ou une <div>)
- les configurations peuvent être très différentes d'un utilisateur à l'autre
- il faut parvenir à différencier ce qu'on va gérer dans la page et ce qu'on va laisser à gérer par l'utilisateur. C'est certainement le plus difficile, le plus problématique et le plus important problème de l'accessibilité au stade actuel. Il pose en effet la question que tout le monde veut éviter : la formation de l'utilisateur.

Ce fil montre bien également qu'on atteint très vite les limites des problématiques techniques, consacrées à l'utilisation ou l'implémentation de tel ou tel élément, attribut, etc. Il faut savoir cesser d'aborder ces questions sous cet angle, et revenir sur des problématiques essentielles (qui auront des conséquences techniques) : la démarche d'accessibilité dans le processus de développement, la formation des utilisateurs, la nature du développement Web, très différent du développement applicatif ou du design traditionnel.

Alsa est un forum très applicatif : c'est ce que lui demande spontanément ses utilisateurs. Mais il faut comprendre que c'est aujourd'hui une limite très restrictive qu'il va falloir dépasser.

As-tu remarqué, d'ailleurs, comme on en vient de plus en plus systématiquement dans ce forum, de manière toute naturelle, à poser la question du "pourquoi veux-tu faire cela" face à une question technique ? Ou à dire immédiatement: "le problème n'est pas là. Il est dans la démarche dans laquelle s'inscrit la question".

Raphael a écrit :

2) Utilisation "classique" de Jaws
- Comment un utilisateur "lambda" navigue-t-il avec Jaws par défaut ?
- Quels sont les autres manières de naviguer ? (par liens, par titre, par...). Sont-elles fréquemment employées ?

Il n'y a pas d'utilisateur lambda, ni de lecteur d'écran lambda, pas plus en accessibilité qu'en ergonomie, ni plus généralement du point de vue de la qualité Web. Il n'y a pas de comportement déterminé que l'on puisse projeter sur l'utilisateur. Il y a seulement des possibilités à mettre à disposition de l'utilisateur, sur la base du seul plus petit dénominateur commun possible, c'est à dire le standard structurel.

La page doit donc favoriser chacun des différents modes de navigation structurelle possible :
- titres
- listes
- liens
- tableaux
- blocs textuels
- images
- formulaire
- etc.

Autrement dit, reposer sur un flux HTML cohérent, éviter les structures exotiques ou détournées, privilégier une structure linéaire où se succèdent des blocs fortement structurés (Voir les dicusssions récentes sur l'accessibilité, dans ce forum)... Beaucoup de sites, même soucieux d'accessibilité, commencent en fait par créer des problèmes potentiels d'accessibilité qu'ils replâtrent ensuite avec plus ou moins de succès. Tenter de se représenter mentalement la structure de sa page en oubliant la présentation graphique : celle d'une page accessible se "visualise" mentalement sans difficulté.

On ne va pas restreindre la créativité (je devance les hurlements prévisibles) : on va lui demander de se développer autrement. C'est ce que dit depuis longtemps l'approche du lâcher prise, qui peut aujourd'hui trouver sa place dans une problématique plus globale.

Raphael a écrit :

3) Jaws et les "techniques d'accessibilité" pour l'utilisateur "lambda"
- Les liens d'évitement sont-ils utiles et employés sous Jaws ?
- La page de politique d'accessibilité est-elle utile et employée sous Jaws ?
- Les Accesskeys sont-ils utiles et employés sous Jaws ?
- Les Tabindex, la navigation par la touche Tab sont-ils utiles et employés sous Jaws ?

Les liens d'accès direct au contenu/menu... en tête de page sont sans doute les plus probants, car immédiatement perceptibles à tous les utilisateurs dès l'arrivée dans le document (quand on ne les masque pas graphiquement). Ils disent clairement une chose simple: cette page a deux parties, navigation et contenu.

Les liens d'évitement à l'intérieur des contenus et des menus seront plus ou moins utiles ou gênants selon les utilisateurs et selon leur complexité. Un lien d'évitement d'une série de liens balisés de manière tortueuse (liste de définition, plusieurs listes combinées, etc.) ne corrigera pas la difficulté créée pour la navigation structurelle.

D'une manière générale, les systèmes de navigation propres à un site (menu d'accessibilité en tête de contenu, architecture de tabindex, de liens d'évitements et d'ancres, accesskeys, tout autre mécanisme nécessitant d'aller lire un mode d'emploi...) peuvent aider s'ils restent simples et discrets, et s'ils s'appuient sur une structure en flux prévue comme ci-dessus. Ils seront d'une utilité limitée pour corriger une structure complexe ou problématique.

Raphael a écrit :

- Comment Jaws perçoit la séparation fond (HTML) / forme (CSS) ? Est-ce un réel apport dans la facilité de navigation ?
5) Jaws et les CSS2 de média Aural/Speech
- Comment Jaws traite-t-il le média vocal ?
- Le media speech en CSS2 apporte-t-il un réel confort sur Jaws ?
- Quelles propriétés peuvent être utiles pour l'utilisateur "lambda" ?

Aucun lecteur d'écran n'implémente actuellement les type de medias speech/aural, ni les propriétés CSS2.0 aural ou CSS3 speech (Opera et Emacspeack les implémentent, mais ne sont pas des lecteurs d'écran).

Au passage :
- aural = CSS2.0, aucune implémentation sauf celle, très partielle et déformée, d'Emacspeack. Obsolète en CSS2.1. N'existe plus en CSS3
- speech = nouveau media créé par CSS3, avec des propriétés revues et corrigées. Implémentation partielle par Opera, dans l'optique de l'interaction vocale avec le format de page XHTML+Voice, plus que dans l'optique "accessibilité". Selon toute probabilité, il sera d'abord implémenté dans cette optique par le reste de l'industrie (mobiles, verticaux, téléphonie) avant de l'être par les lecteurs d'écran. La priorité économique et commerciale d'une entreprise comme Freedom Scientific (Jaws) est en effet de traiter le Web en l'état (donc de rendre accessible le HTML tel qu'il est majoritairement utilisé), plus que de le faire évoluer en favorisant des standards émergeants. C'est une question de revenu sur investissement... Il y a peut-être, cependant, des surprises à attendre d'IBM, fortement investi dans X-Voice (le moteur vocal d'Opera est produit par IBM), qui pourrait réinvestir ses récents développements dans ses produits d'accessibilité (c'est une pure spéculation personnelle)...
Modifié par Laurent Denis (01 Oct 2005 - 09:43)

IL ne faut pas oublier non plus que freedom est de mèche avec m$ et que, par conséquent, programme jaws en fonction des possibilités d'IE... c'est pour ça que j'attends depuis longtemps un script pour opera ou firefox et qu'il n'existe encore pas réellement...