+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Javascript & accessibilité] Événement click, quelle solution utiliser ? (/showthread.php?tid=2724)
[Javascript & accessibilité] Événement click, quelle solution utiliser ? - Ter Rowan - 09-07-2008
Je reprends ce que j ai posté à la suite d'un post de Kassak. Il y a déjà eu deux réponses, mais pour ne pas pourrir son post (désolé
) je préfère en recréer un ici...Ter Rowan a écrit :justement, je me posais diverses questions sur la manière de coder le
"utilisateur clique sur machin pour lancer un javascript"
entre :
+ un <div> avec un onclick dans le gestionnaire d'événement
+ un <a href:#> avec un onclick dans le gestionnaire d'événement
+ un <a href:# onclick =blabla> donc le onclick dans la balise (c'est beurk hein ?)
+ un <a href=javascript(.....)> donc l appel de la fonction directement dans le href
Y a t il une seule solution propre? est ce que cela dépend du contexte ?
prélude a écrit :Pour ma part, je trouve que la première est la bonne. Quel que soit le cas (enfin, à prioris évidement).
orditeck a écrit :Pour ne pas que la page reviennent en haut avec le onclick sur un lien (<a href="#" onclick="">)
vous POURRIEZ faire
<a href="javascript : void(0);" onclick=""> (Pas d'espace... mais MyBB en veut apprement.)
Mais cette solution n'est pas conseillée
En effet, elle peut causée des bug d'affichage. Il est fortement conseillé de ne pas utiliser de " javascript : ; " dans la balise href=""
Utilisez plutôt (comme dit plus haut)
<a href="#" onclick="MaFonction(); return false;"> Mon lien </a>
Source : http://blog.reindel.com/2006/08/11/a-hrefjavascriptvoid0-avoid-the-void/
Mais personellement, je préfère le faire sur un div
Mais ça dépend toujours du contexte de la mise en page selon moi...
et là une autre interrogation.
Au début j'étais parti sur du div mais... en lisant les forums Alsacréation j'ai été (un peu) sensibilisé à l'accessibilité.
Prenons le cas d'un individu acceptant le javascript (j'écarte déjà un type d'accessibilité là) mais devant utiliser des navigateurs spécialisés à cause d'une déficience particulière.
Les deux premiers avis préconisent la solution du div, et je serais enclin à les suivre (maintenant que je sais presque changer le curseur au survol hihi). Mais quid pour signaler à un navigateur spécialisé que ce div peut générer une action ?
Je suis peut être complètement à côté de la plaque sur ce point, je ne connais personne atteint d'une déficience (visuelle, motrice ou autre) qui nécessite une "adaptation" ou une "rigueur plus importante" dans la conception de page web .
RE: event "clic" quelle solution utilisée ? - Sephi-Chan - 09-07-2008
Je ne comprends pas bien la question, je vais tenter de répondre donc à ce que je crois comprendre.
L'idée pour un Javascript non-intrusif, c'est de proposer une page alternative pour ceux qui n'ont pas Javascript. Si la personne accepte Javascript, tu ne pourras pas vraiment savoir si elle souffre d'un handicap, donc tu es baisé, si je puis dire. Je doute que les navigateurs spécialisés envoient une information générique (qui varie d'un handicap à l'autre, mais pas d'un navigateur à l'autre) qui permettrait d'identifier le handicap de l'utilisateur.
Cette page altérnative s'atteint en faisant un script de ce genre (dans le cas bien sûr où Javascript n'est pas activé, s'il est activé, le script générera une alert) :
Code PHP :
<?php
<a href="actionAlternative.php" onclick="function(){ alert('Jambon !'); }; return false;">Action</a>
Concernant les événements, De mémoire, l'événement click est reconnu même lorsque l'on navigue au clavier (en faisant Enter). Par contre, le cas du mouseover est un peu particulier puisqu'il fonctionne avec la souris, l'altérnative au clavier est focus.
Pour développer plus facilement un Javascript accessible, je ne peux que te conseiller d'utiliser un Framework (jQuery ou Mootools, par exemple) qui te permettra de te concentrer sur l'applicatif plutôt que sur les détails du langage.
J'espère avoir (complètement ou partiellement) répondu à ta question, sinon n'hésite pas à la préciser, en décrivant par exemple l'action effectuée, que l'on puisse t'aider au mieux à trouver une alternative.
Sephi-Chan
RE: event "clic" quelle solution utilisée ? - Feldoran - 09-07-2008
C'est très bien de vouloir rendre son site accessible à tous, et si tu peux le faire c'est l'idéal, mais il est probable que ça nécessite de faire des sites plus simples et sans trop de fioritures. Donc probablement utiliser la balise <a> dans ton cas.
A vérifier, je vais essayer d'en savoir plus.
Sinon, si ça peut te servir, à l'époque où je codais des jeux d'aventure en mode texte, j'étais en relation avec une auteur/joueuse qui était aveugle. Elle s'impliquait beaucoup dans la recherche et la création de jeux pour malvoyants, donc si ça t'intéresse je peux essayer de la recontacter pour voir si elle peut t'aider à vérifier ce que ça donne sous son navigateur (je crois qu'elle a un lecteur vocal comme JAWS).
RE: event "clic" quelle solution utilisée ? - Ter Rowan - 09-07-2008
merci pour vos réponses
je précise juste entre la question que je pose et mon propre projet
ma question : elle concerne n'importe quel projet. Je raisonne plus dans l'absolu, pour de bonnes pratiques (sachant qu'on peut très bien ne pas suivre toutes les bonnes pratiques, c'est juste une prise de risque)
mon projet : même si je m'en soucie, je crains pour le moment de laisser de côté une partie de la population (j'en suis même à me demander si je vais pas laisser de côté ie dans un premier temps). En effet je rame tellement sur des points de ce type que je risque de ne pas voir un jour le projet devenir réalisation, sans parler de l'éventuel succès (si y a trois joueurs intéressés, pour un "mmo", alors même en ouvrant à des populations plus larges, le jeu sera un échec, donc avant de trop investir là dessus, tentons déjà de sortir la chose).
donc entre un futur projet accessible à tous une fois réalisé mais jamais réalisé, et une application, moins ambitieuse d'un point de vue accessibilité mais utilisée, je parie sur l'application. Charge à moi après de rentrer dans une v2 plus accessible
Evidemment cette position tient à la teneur de mon projet. Je ferais un projet type (le livre dont vous êtes le héros, x choix tu clics, page suivante), forcément j'irais vers l'accessibilité maximale. Mais je cherche à faire un projet "application riche", avec du drag and drop par exemple, donc forcément si on ne veut pas utiliser javascript, et bien le jeu ne peut pas fonctionner. (a noter je suis sur prototype script aculo pour sephi
)En forçant le trait, est ce qu'un aveugle a un intérêt à jouer à un jeu avec du drag/drop ou est-ce trop ardu pour lui ? est ce qu'un handicapé moteur (genre ayant des difficultés à manipuler la souris) a un intérêt à jouer à un jeu avec du drag/drop ou est-ce trop ardu pour lui ? mon avis c'est que ce genre de jeu n'est pas adapté de toute manière, mais c'est un avis d'un méconnaissant total, c'est donc plus un a priori qu'autre chose.
mais assez parler de moi et mon projet. Revenons au sujet général si vous le voulez bien
div + event javascript ou
<a href="actionAlternative.php" onclick="function(){ alert('Jambon !'); }; return false;">Action</a>
l'intérêt du <a href> c'est bien d'être accessible au joueur sans javascript mais...
est ce mieux pour les navigateurs spécialisés (genre ah tiens anchor donc action, et ah tiens div donc affichage) ?
et le <a href> n'est il pas moins "pertinent/performant/intéressant" que le <div> pour les navigateurs standards ?
RE: event "clic" quelle solution utilisée ? - Sephi-Chan - 09-07-2008
Sémantiquement, je dirais qu'un lien est sans doute plus adapté puisqu'en cliquant sur un lien, on s'attend à déclencher une action (un changement de page).
Après, si tu as un formulaire où tu veux afficher des infobulles, c'est plus logique de mettre les infobulles dans des paragraphes et des les afficher quand l'utilisateur à le focus sur le champ correspondant.
Sephi-Chan
RE: event "clic" quelle solution utilisée ? - keke - 09-07-2008
Coucou,
J'ai des non-voyants dans mon jeu (environ 1/5 des joueurs inscrits).
La solution que j'ai retenu n'est pas la plus belle au niveau du code, mais elle est efficace :
- un code pour les voyants
- un code pour les non-voyants.
J'emploie cette méthode dans les cas où cela se justifie.
Ainsi, les informations concernant les armes (affiché au survol) sont écrite à la suite du nom de l'arme ... épée + 1 Tranchant + 2 coupant + 0 assomant
La carte n'est plus une image, mais une liste détaillé de lieu où l'on peut se rendre
Le tchat (évolution en cours utilisant Ajax) va rester une simple messagerie où la page se rafraichie en cliquant.
Etc etc...
Les non-voyants ont en particulier de gros problèmes avec les liens en target="_blank" qui ouvre une nouvelle page. Cela leur fausse complètement la navigation.
Le drag & drop n'aura aucune chance de fonctionner ... Jaws, je crois, désactive complètement tous les javascript.
Voilou pour ma contribution à 2 écus ^^
Kéké.
RE: event "clic" quelle solution utilisée ? - Ter Rowan - 09-07-2008
je me demande vraiment, si pour des sites ludiques, ce n'est pas la meilleure solution que d'avoir des codes adaptés à chaque population que l'on souhaite toucher...
Ca a l'air plus couteux mais d'un autre côté, on évite un site "moyen" qui tire vers le bas l'une ou l'autre des populations pour chaque fonctionnalité du jeu.
RE: event "clic" quelle solution utilisée ? - Sephi-Chan - 09-07-2008
Ce n'est pas tout le code qui doit être dupliqué, seulement quelques points conditionnés (en permettant aux utilisateur d'indiquer leurs déficiences dans leur profil).
Je reste persuadé que dans la plupart des cas, une solution générique existe. Le problème est que certains navigateurs pour déficients activent Javascript alors qu'ils ne le supportent que partiellement, du coup ils emmerdent le monde plus qu'autre chose.
Sinon, il suffit de transformer les pages à l'aide de Javascript, comme ça le site n'est en version Javascript que si Javascript est utilisé.
Par exemple avec un site que j'avais fais, mes pages contenaient plusieurs sous parties. Au chargement de la page, Javascript créait des onglets pour chaque de ces sous parties et n'affichaient que la première. Il suffisait ensuite de passer de l'une à l'autre grâce aux onglets générés.
Sephi-Chan
RE: event "clic" quelle solution utilisée ? - QuentinC - 09-07-2008
Hello tous,
Comme vous le savez sûrement déjà, je suis un utilisateur de jaws. Je n'ai pas lu l'intégralité des réponses dans le détail mais voici mes réactions, dans le désordre...
lien ou div avec onclick : le choix est simple, car le div n'est pas un élément focusable, ou autrement dit, il n'est pas accessible au clavier lorsqu'on navigue avec la touche tab, et par extension, il ne sera pas non plus affiché dans une liste de lien (avec jaws : Insert+F7). Donc, à disqualifier sauf si sa préférence à <a> est bien justifiée.
Néanmoins, les versions récentes de jaws annoncent «cliquable » lorsqu'on arrive avec les flèches de direction sur un élément autre que <a> qui déclenche du js par onclick. Dans certaines circonstances, il n'est pas annoncé, mais en règle générale ça fonctionne.
Par contre, pour qu'on puisse réellement y accéder, il faut qu'il y ait du contenu HTML réellement visible : du texte, une image en dur, etc. L'erreur à ne pas faire si vous avez décidé malgré tout d'utiliser du div ou du span cliquable, c'est d'utiliser une image de fond en CSS ou un contenu quelconque caché par display:none, visibility:hidden, text-indent:-1000000px ou un procédé du même genre. Il FAUT qu'il y ait un contenu effectif où jaws peut simuler le clic.
Maintenant, entre href="javascript:..." ou onclick : pour jaws, et là je parle uniquement pour jaws, un bug qui est resté de la version 3 à la 8 (corrigé dans la 9) fait que les onclick qui ouvrent des alert, prompt ou confirm plantent jaws et tout le PC tant qu'on a pas appuyé sur Alt+F4 pour fermer la boîte ouverte, et aucun message n'est lu. Donc il n'est pas possible d'appuyer sur OK ni dans un confirm (Alt+F4 = annuler), ni dans un prompt (Alt+F4 = annuler = la valeur null est retournée). Par contre, si votre script switch display:block/none, visibility:visible/hidden ou ajoute/modifie du contenu HTML visible, jaws a plus de chances de mettre à jour automatiquement son « affichage interne » avec un onclick qu'un href javascript.
Là je parle uniquement des spécificités de jaws, en pratique ça n'a que peu d'importance, hormis que le onclick est tout de même plus propre, tandis que le href javascript relèverait plus du « bricolage ».
Et maintenant, halte aux idées reçues :
Citation :Je doute que les navigateurs spécialisés envoient uneDans le cas des revues d'écran, le navigateur n'envoie aucune info spécifique. Vous n'avez aucun moyen de savoir si l'utilisateur qui surfe sur votre site utilise une revue d'écran. Vous le voyez comme un autre utilisateur avec un navigateur normal, le plus souvent IE6 sous XP ou IE7 avec vista. Firefox est beaucoup moins courant, car bien que jaws le supporte (version 8+), c'est beaucoup plus lent et il y a beaucoup plus de bugs, parfois assez méchants. Je n'ai aucune information au sujet d'opera, ni du support sous mac ou linux.
information générique (qui varie d'un handicap à l'autre, mais pas d'un navigateur à l'autre) qui permettrait d'identifier le handicap de l'utilisateur.
Citation :Concernant les événements, De mémoire, l'événement click est reconnu même lorsque l'on navigue au clavier (en faisant Enter). Par contre, le cas du mouseoverJe pense avoir répondu à ça dans la première partie de mon post. Le problème du focus est le même : vous aurez beau mettre onfocus sur un div ou un span, ça ne marchera pas. Jaws annonce également les éléments onmouseover, mais la manipulation au clavier qui permet de les déclencher est assez compliquée. Les autres revues d'écran moins performantes et les utilisateurs qui sont incapables d'utiliser une souris n'ont pas d'alternative. Donc, à proscrire, y compris pour un menu déroulant, que vous DEVEZ IMPÉRATIVEMENT doubler d'un gestionnaire au clic en plus de tenir compte des remarques à son propos.
est un peu particulier puisqu'il fonctionne avec la souris, l'altérnative au clavier est focus.
Citation :En forçant le trait, est ce qu'un aveugle a un intérêt à jouer à un jeu avec du drag/drop ou est-ce trop ardu pour lui ? est ce qu'un handicapé moteurL'intérêt serait peut-être au rendez-vous, mais c'est sûr qu'en présentant l'information de cette manière, il est clair que vous éliminez d'entrée les utilisateurs de revue d'écran. Il existe un moyen pour « simuler » un d&d mais ça ne marche pas bien, c'est une manipulation qui reste compliquée (perso je ne l'ai jamais utilisée), et surtout ça ne fonctionne pas en naviguant sur le web avec le tampon virtuel de jaws.
(genre ayant des difficultés à manipuler la souris) a un intérêt à jouer à un jeu avec du drag/drop ou est-ce trop ardu pour lui ? mon avis c'est que ce genre de jeu n'est pas adapté de toute manière, mais c'est un avis d'un méconnaissant total, c'est donc plus un a priori qu'autre chose.
Pour quelqu'un qui a des difficultés à manipuler une souris, la question est paradoxale : à des fins d'entraînement pourquoi pas, mais dans un but divertissant, je doute que vous preniez du plaisir d'être contraint d'utiliser un objet que vous avez des difficultés à manipuler. Donc là aussi, vous allez les faire dégager très vite.
Le problème est le même que pour flash : c'est inaccessible par nature, on ne peut rien y faire, donc soit on fait un site accessible et on s'abstient de l'utiliser, ou soit on utilise et alors on assume en étant conscient que le site ne sera pas utilisable par tout le monde.
La proposition de Kéké d'utiliser deux versions différentes d'un même site peut être une solution louable. Mais là vous vous exposez à plusieurs problèmes : le temps de développement et de maintenance sont rallongés, il faut veiller à ce que les mises à jour soient synchronisées entre les deux versions car il faut que les utilisateurs de la version simplifiée aient accès aux mêmes informations que les autres, pour ne citer que les deux points qui me paraissent être les plus importants. Si vous avez prévu d'utiliser du d&d, du flash ou d'autres éléments par nature inaccessibles à certains utilisateurs, proposer une version alternative est une nécéssité.
Mais plutôt que faire deux versions, pourquoi ne pas faire directement une seule version qui convienne à tout le monde ?
Citation :Les non-voyants ont en particulier de gros problèmes avec les liens en target="_blank" qui ouvre une nouvelle page. Cela leur fausse complètement la navigation.J'ajouterais que cela n'est pas uniquement vrai pour les déficients visuels. Ça énerve aussi les utilisateurs bien voyants parfois. L'ouverture dans une nouvelle fenêtre doit être une action contrôlée par l'utilisateur ou alors elle s'applique à des cas bien précis, par exemple un genre de boîte de dialogue où là c'est clair pour tout le monde qu'on saisit vite en encart quelques informations avant de revenir où on était avant.
Citation :Le drag & drop n'aura aucune chance de fonctionner ... Jaws, je crois, désactive complètement tous les javascript.Une fois encore, halte aux idées reçues. Jaws fonctionne par-dessus un navigateur conventionnel (IE6 ou IE7) supportant le javascript.
J'arrive au terme d'un long post, j'espère avoir pu vous apporter quelques réponses constructives.
RE: event "clic" quelle solution utilisée ? - Raoull - 09-07-2008
Long mais bon
Merci pour toutes ces infos.
J'ai déjà l'habitude de tester mes sites avec un navigateur texte (genre lynx) pour voir si mes pages sont reellement utilisable en texte seul et sans javascript.
Et cela me donne maintenant très envie de tester jaws par moi-même, au moins pour ne pas mourrir idiot, et peut-être pour améliorer ce qui peut l'être encore.