[resolu] Comportement synthèses vocales <noscript>

Bon(soir)jour à tous. J'ai besoin de votre avis sur une question est probablement bête... mais bon, je vous fais confiance pour me secouer si c'est le cas
Voilà la situation : pour un site public je dois intégrer un menu déroulant qui me pose question pour l'accessibilité dans la mesure où il utilise javascript. Il me faut garantir l'accès au site si javascript est désactivé et je comptais utiliser la balise <noscript> pour y placer un menu alternatif (tout déroulé, disposé autrement etc... mais permettant d'accéder à toutes les rubriques).
Ma question est celle-ci : comment une synthèse qui a javascript activé va-t-elle se comporter sur cette balise ? Va-t-elle l'ignorer comme les navigateurs lorsque js est actif ? Ou va-t-elle "relire" tout le menu qu'elle contient ? (allez messieurs dames, le menu était pas assez complet, on en remet une couche !)
Modifié par cktoon (22 Jun 2005 - 14:26)

Quand tu caches du contenu avec du JavaScript, souvent également tu utilises par exemple des display: none dans une CSS.

Malhreusement, le comportement des lecteurs d'écran est difficilement prédictible dans ces situations, car ils ne respectent pas les guides d'accessibilté publié par le W3C pour les agents utilisateurs:
http://css-discuss.incutio.com/?page=ScreenreaderVisibility

Si tu te concentres sur Jaws, tu peux trouver une discussion intéressante sur Accessify Forum, dont voici un extrait:

a écrit :

JAWS and WindowEyes both use MSAA to talk to Internet Explorer to retrieve the details of the document. Changes to the document done by CSS and Javascript are thus visible to these screen readers. display:none styled content is effectively hidden from screen readers, and content dynamically generated using Javascript (e.g. DOM manipulation) is read out by the screen reader

Un effet secondaire important est que si ton menu est généré à l'aide d'un mouseover en javascript, Jaws ne le lira jamais (les aveugles n'utilisent pas la souris, et le code javascript ne sera lancé qu'avec l'aide de la souris...). Pour éviter cela, utilise aussi l'attribut onfocus, pour permettre la navigation au clavier (et donc l'utilisation du script par les aveugles).
Modifié par Gilles (10 Jun 2005 - 08:56)

Merci Gilles de tes liens et te l'ouverture de la discussion lancée par ma question... Mais celle-ci n'était pas une question sur l'utilisation de javascript ou les effets du display:none, mais sur l'utilisation de la balise <noscript> et du comportement des lecteurs face à cette balise...

La navigation au clavier fonctionne, avec attribution des accesskeys recommandée par l'ADAE sur les liens concernés.

Nous avons déjà beaucoup travaillé ce menu pour essayer d'être au maximum accessible tout en respectant les comportements qui nous sont demandés.

Le menu "alternatif" qui est accessible lorsque javascript est désactivé est en place, lui aussi accessible.

Maintenant je me pose la question suivante : est-ce que les lecteurs d'écran se comportent comme les navigateurs face à une portion de code dans la balise noscript, à savoir : je ne lis rien de qui est dedans si j'ai javascript activé ; je ne m'en préoccupe que lorsque j'ai javascript désactivé ?

Voilà, merci de vos avis

bonjour,

Tu peux eventuellement tester JAWS. il est telechargeable en version d'essai.
( 40 mn renouvellable apres reboot du pc ).


lien de telechargement

amicalement

Merci Philippe... j'ai jaws en version d'essai. Une idée sur le comportement des autres ?

Dans les liens que je t'ai indiqués, il était dit que les lecteurs, comme ils sont basés sur notamment IE, suivent les mêmes options que ce dernier. SI JS est désactivé, ils lisent le noscript, sinon, ils sont sensibles au script...

Justement lors des tests que je fais, j'ai un problème d'accès au contenu de la balise noscript...
Avec IE, javascript désactivé, en mode "visuel" : le contenu de ma balise noscript est affiché à l'écran, je le vois bien.
Avec IE, javascript désactivé, et Jaws : le contenu de ma balise noscript est ignoré... il ne l'énonce pas.
Est-ce un problème local ?

Il semble donc pour moi que Jaws se comporte comme s'il considérait que le javascript était forcément activé : si le javascript se trouve désactivé, il ne lit pas le contenu de la balise <noscript>... J'ai beau tester plusieurs choses, rien n'y fait, la balise est ignorée.
Personne n'a constaté ça ?

je te conseille de lire cela
en anglais malheureusement en gros les vieille version de lecteur d'écran supporte javascript mais ne rendent pas les fonctionnalité à l'affichage

http://www.boxofchocolates.ca/archives/2005/06/12/javascript-and-accessibility

Merci Goetsu, mais l'article parle de la gestion de javascript par les synthèses... ce n'est pas l'objet de ma question.

Mon problème semble apparemment incompréhensible ??????

Faisons simple avec un exemple illustré :

<body>
<p>Texte</p>
<noscript>Texte du noscript</noscript>
</body>

C'est aussi bête que ça...

- Test 1 : navigateur standard, javascript actif
A l'écran je vois "Texte".

- Test 2 : navigateur standard, javascript désactivé
A l'écran je vois "Texte du noscript"

Tout est normal jusque là....

- Test 3 : IE + jaws, javascript actif
A l'écran je vois : "Texte"
Jaws annonce : "Texte"

- Test 4 : IE + jaws, javascript désactivé
A l'écran je vois : "Texte du noscript"
Jaws annonce : rien du tout. C'est là qu'est mon problème.

Je ne peux pas être plus claire que ça.

La théorie qui dit "vous utilisez du javascript pouvant empêcher l'accès du site si celui-ci est désactivé -> mettez le contenu alternatif permettant l'accès au site dans la balise <noscript>" n'est pour moi pas si évidente que ça puisque tests réalisés, cette balise est ignorée dans certains cas.

Alors je pourrais me contenter d'appliquer la théorie sans chercher à vérifier si en pratique elle fonctionne... mais ce n'est pas mon habitude.

Est-ce que ce comportement est vérifié chez vous ?

Et si oui.... comment faire alors pour ce cas de figure ?

Merci de vos lumières

Tu devrais changer de stratégie pour ton menu déroulant.

Quand tu implémentes une solution javascript, il est bien plus efficace de penser le problème autrement : Par défaut tout élément doit être accessible et utilisable et ce n'est qu'au chargement de la page, à la condition que javascript soit activé, que ces éléments sont initialisés.

Cela consiste, dans ton cas, à implémenter ton menu dans son état "déroulé" et de le replier, par javascript, au chargement de la page.

De cette manière, il est toujours utilisable, particulièrement pour les utilisateurs de lecteurs d'écran car il conserve sa place naturelle dans le flux et donc sa cohérence par rapport à ton organisation de page.

Les contraintes sont de deux ordres :
- D'abord il faudras vraisemblablement que tu adaptes ton design pour créér la place nécéssaire à ton menu "déplié".
- Ensuite tu va avoir un effet disgracieux au chargement de la page que tu peux résudre en implémentant, juste après ton menu le passage javascript qui commandera le repliement initial.

Ce principe est valable pour tout les traitements javascript, sauf si tu t'assures qu'ils ne représentent pas de gène quand ils ne sont pas disponibles.

A ces conditions tu n'à besoin de la balise noscript que pour indiquer que javascript est nécéssaire à certaines dispositions et pas pour en implémenter des clones.

JP
Modifié par jpv (17 Jun 2005 - 12:42)

Mon post concerne le comportement des synthèses vocales face à un contenu de balise noscript. Je regrette une fois encore que les contributions en réponse à ma question soit des réponses "à côté"...
Le menu en question ne peut être présenté déroulé car il est horizontal, avec plusieurs niveaux de sous menus eux également horizontaux qui ne peuvent être tous déroulés en même temps. Mais peu importe, là n'est pas ma question.

Avec comme question subsidaire : ton menu déroulant est-il accessible avec un lecteur d'écran et javascript activé, et autre point crucial avec la navigation tabulaire.

Pour ne pas répondre à coté de ta question: ça va dépendre du type la synthèse vocale (lecteur d'ecran, navigateur vocal...), de son éditeur (windows-eyes, IBM, jaws...) de la version (ancienne ou récente) et des paramétrages utilisateurs, notamment avec un lecteur d'écran comme Window-eyes par exemple.

Je te laisse devinner la conclusion : tu ne peux pas t'appuyer sur la balise noscript comme alternative "accessible' à un menu javascripté.
D'où nos suggestions...

Il existe d'autre manière de faire, celle que je te proposais en est une aprmis d'autres, dans le cas d'un menu horizontal multi-niveaux tu peux recourir à d'autres techniques.

Ceci étant, si nous nous répondons à coté, peut-être que toi aussi tu lis à coté...

JP
Modifié par jpv (18 Jun 2005 - 19:10)

cktoon a écrit :

La navigation au clavier fonctionne, avec attribution des accesskeys recommandée par l'ADAE sur les liens concernés.

Si ce n'est pas assez clair : ceci est vrai en version écran ET en navigation avec synthèse.

Maintenant, la question, si elle doit devenir plus générale, n'est pas à ouvrir sur "et si tu proposais un menu autrement?" mais bien sur "faut-il avoir confiance en la théorie qui dit que l'on doit utiliser la balise noscript pour placer un contenu destiné aux internautes qui ont désactiver javascript".

L'objet de mon post est bien celui là : je constate une situation où <noscript> ne joue pas son rôle puisqu'elle est ignorée, et il n'est pas question de mon menu ni même de mon code, regardez les tests que j'ai pris la peine d'indiquer...

J'attendais un retour d'autres sur cette base là, genre "chez moi ça marche" ou bien "tiens chez moi non plus ça marche pas..." parce que dans ce cas, celà voudrait dire que celà ne nous suffit pas de placer un contenu alternatif dans une balise <noscript> en dormant sur nos deux oreilles, persuadés que le site en question est bien accessible pour tout le monde puisqu'on a prévu un contenu pour le cas où javascript est désactivé.

Je ne sais pas être plus précise, mais si c'est incompréhensible pour tout le monde, alors tanpis.

Bonjour,

a écrit :

L'objet de mon post est bien celui là : je constate une situation où <noscript> ne joue pas son rôle puisqu'elle est ignorée, et il n'est pas question de mon menu ni même de mon code, regardez les tests que j'ai pris la peine d'indiquer...

La balise noscript joue parfaitement son rôle dans un navigateur.
En revanche pour les couches logicielles qui utilisent le navigateur ce n'est pas garantis.
Les synthèses vocales sont encore développés dans un esprit très "propriétaire" car il s'agit d'un marché assez juteux.
C'est malheureux mais c'est comme ça. Il s'agit d'autres part d'un marché en évolution et il y à de grandes différences entre les versions d'un même logiciel, particulièrement pour les plus anciennes, encore très utilisées et qui pour la plupart vont poser ce genre de problèmes.
Au vue du prix astronomique et pour le moins stupéfiant de ces logiciels (1500 Euros) il est à craindre que ce phénomène persiste et que l'on doivent encore longtemps faire avec.

a écrit :
parce que dans ce cas, celà voudrait dire que celà ne nous suffit pas de placer un contenu alternatif dans une balise <noscript> en dormant sur nos deux oreilles, persuadés que le site en question est bien accessible pour tout le monde puisqu'on a prévu un contenu pour le cas où javascript est désactivé.

C'est absolument vrai, cela ne suffit généralement pas et c'est assez problématique dans le cas d'un menu de navigation.

D'où, dans l'esprit de produire un menu réellement accessible et comme tu ne peux pas compter sur la seule balise noscript, il te faut trouver une solution alternative.

Enfin, pardonnes moi te de dire ça mais tu trouveras généralement ici des gens sympathiques qui tente de t'aider en essayant de comprendre ton problème et de trouver des solutions.

Je ne suis pas certain qu'en les renvoyant dans les cordes tu parviennes à les motiver à te répondre.


JP
Modifié par jpv (20 Jun 2005 - 23:37)

cktoon a écrit :
sur "faut-il avoir confiance en la théorie qui dit que l'on doit utiliser la balise noscript pour placer un contenu destiné aux internautes qui ont désactiver javascript".

Comme tu le dis toi-même, c'est "théorique", un objectif d'implémentation pour les navigateurs.
Doit-on faire confiance à des éléments théoriques ou recommandations ? On ne peut que partir du principe que les outils sont développés "pour le mieux", mais qu'ils n'atteignent jamais la perfection... Sinon, ça se saurait...
Partant de là, il n'y a plus qu'à agir en conséquence, et travailler en fonction de ce que font ou ne font pas les outils de l'utilisateur.

Bonjour à tous,

jpv a écrit :
Bonjour,
Enfin, pardonnes moi te de dire ça mais tu trouveras généralement ici des gens sympathiques qui tente de t'aider en essayant de comprendre ton problème et de trouver des solutions.

Et je crois en faire partie, il m'arrive de pousser des tests assez loin et d'en faire profiter tout le monde.... même si ces derniers temps j'ai rarement du temps à passer ici.

jpv a écrit :
Je ne suis pas certain qu'en les renvoyant dans les cordes tu parviennes à les motiver à te répondre.

Désolée de passer pour une mal embouchée. Cependant,je trouve qu'à vouloir proposer des solutions à tout prix, il arrive qu'on ne lise qu'en travers les données d'un problème, surtout lorsqu'il est pointu et je trouve que c'est particulièrement énervant... et de fait il nous a fallu des posts et des posts avant d'arriver sur LE POINT en question...

macpom a écrit :
Partant de là, il n'y a plus qu'à agir en conséquence, et travailler en fonction de ce que font ou ne font pas les outils de l'utilisateur.

Dans la case "ce que ne font pas les outils de l'utilisateur" je rajoute donc que JAWS (dernière version) n'interprête pas le contenu de <noscript> si on l'utilise avec IE et javascript désactivé... puisque personne ne constate un comportement différent.

Quant au "il n'y a plus qu'à", heureux ceux qui maîtrisent tous les aspects de la création d'un site et ne sont pas obligés de répondre à des exigences contradictoires entre un graphisme et des fonctionnalités magnifiques pour un internaute "voyant" mais pour lesquelles l'accessibilité reste bien théorique et les exigences du type "garanti accessible tout navigateur, toute plateforme, tout outil"...Personnellement je n'ai pas cette chance...

jpv a écrit :
Enfin, pardonnes moi te de dire ça mais tu trouveras généralement ici des gens sympathiques qui tente de t'aider en essayant de comprendre ton problème et de trouver des solutions.

Je ne suis pas certain qu'en les renvoyant dans les cordes tu parviennes à les motiver à te répondre.

cktoon a écrit :
Et je crois en faire partie, il m'arrive de pousser des tests assez loin et d'en faire profiter tout le monde.... même si ces derniers temps j'ai rarement du temps à passer ici.

Désolée de passer pour une mal embouchée. Cependant,je trouve qu'à vouloir proposer des solutions à tout prix, il arrive qu'on ne lise qu'en travers les données d'un problème, surtout lorsqu'il est pointu et je trouve que c'est particulièrement énervant... et de fait il nous a fallu des posts et des posts avant d'arriver sur LE POINT en question...

Il fait trop chaud pour s'énerver ... Merci de maintenir des échanges cordiaux svp

Mon avis sur les menus javascript de plusieurs niveaux rejoint ceux de beaucoup de membres ici qui estiment que ce n'est pas un bon système de navigation pour l'accessibilité... J'ai fait le choix de ne pas les utiliser.

Si tu souhaites ou doit faire un site accessible, je te suggère de renoncer à ce type de gadget. Je sais que ça ne répond pas à ta question sur le fond, mais je craint que personne ne puisse te répondre avec précision.
Modifié par dominique (22 Jun 2005 - 15:06)

dominique a écrit :

Il fait trop chaud pour s'énerver ... Merci de maintenir des échanges cordiaux svp

Quelqu'un a manqué de cordialité ? Je me suis moi-même qualifiée de mal embouchée, j'assume parfaitement ce qualificatif... quant à jpv, il n'a pas tord de dire que je l'ai un peu "envoyé dans les cordes"... parce que ça virait dialogue de sourds... Bah quoi, ça ne nous empêche pas d'échanger sur un mode cordial... on se dit bonjour et merci et tout et tout... non ?

dominique a écrit :
Mon avis sur les menus javascript de plusieurs niveaux rejoint ceux de beaucoup de membres ici qui estiment que ce n'est pas un bon système de navigation pour l'accessibilité... J'ai fait le choix de ne pas les utiliser.

C'est mon avis aussi... contrairement à ce que tout le monde semble comprendre. Je ne les utilise pas quand j'ai moi aussi le choix... mais quand je n'ai pas le choix parce qu'on m'impose de faire ce genre de menu que je ne qualifierais pas (je risque encore de manquer de zen ) je tente de faire au mieux pour que ce soit accessible à tous... C'est pourquoi je venais chercher des infos / avis sur un comportement particulier...

dominique a écrit :

Si tu souhaites ou doit faire un site accessible, je te suggère de renoncer à ce type de gadget.

Si seulement j'avais le choix....