Venez tester un questionnaire valide AAA

bonsoir,

le site http://www.web-pour-tous.org/ s'ettoffe peu a peu et on travaille surtout sur l'accessibilité du site et du forum. ( quand je dis "on", faut surtout remercier frank et oli, frank etant l'initiateur du projet)

Pour permettre aux handicapés de nous exposer leur façon de surfer, nous avons mis en ligne un questionnaire. Ce questionnaire a été réalisé de façon a le rendre le plus acccessible possible. Mais peut etre avons nous oublié des choses, peut etre penserez vous a certaines choses qui nous ont echappées.

Si vous souhaitez nous aider, venez tester ce questionnaire et donner nous vos impressions.
Toutes les critiques sont bonnes a prendre: accessibilité, presentantion, contenu, etc.....
Une chose importante, pour tester le questionnaire, prenez un login commençant par " test" car ce questionnaire est ensuite envoyé par mail sur la boite de Web-pour-tous.
Pour info, ce questionnaire est traité en php ce qui nous permet d'avoir des stat precise sur toutes les questions posées. ( merci oli )

D'avance merci a tous
Modifié par Philippe (26 Jun 2005 - 13:02)

Je suis aller voir votre formulaire et j'ai tester sans souris ! alors pas de soucis réel si ce n'est que lorsqu'on arrive sur les boutons radio il faut utiliser les flêche de déplacement du claivier (haut - bas) et sur les checkbox la tabulation. Peut être une explication sur comment naviguer au sein du fomulaire serait la bienvenue

D'autre part plutôt que d'avoir deux liens bas et haut de questionnaire il me semblerait plus judicieux d'avoir partie suivant et précedente...

Autre remarque, si j'utilise la tabulation, lorsque j'arrive dans une zone tel qu'un champ de saisie ou un textarea, le contenu informatif s'efface automatiquement et pas le temps de le lire.

Voilà, pour ma petite contribution à cette très bonne initiative qu'est ce site.

Cordialement, Eric.

merci Eric pour ce test et ces critiques constrctives. En esperant que d'autres suivront ton exemple
Par contre, pour la navigation sur les boutons radio, chez moi sur FF je navique uniquement avec la touche TAB....bizarre

Mais je suis confiant. Les "posters" d'ALSA sont les meilleurs
Modifié par Philippe (24 Jun 2005 - 22:54)

a écrit :
Peut être une explication sur comment naviguer au sein du fomulaire serait la bienvenue

L'explication à été mise en ligne.

a écrit :
Autre remarque, si j'utilise la tabulation, lorsque j'arrive dans une zone tel qu'un champ de saisie ou un textarea, le contenu informatif s'efface automatiquement et pas le temps de le lire.

Oui je l'ai remarqué hier également même le fait de vouloir remonter à l'aide de la tabulation supprime le texte de l'utilisateur.

Bonsoir,

Quelques remarques :

- Les listes de bouton radio impliquent une "saisie obligatoire", il serait souhaitable de rajouter une valeur générique permettant de ne pas y répondre, ou rajouter l'étoile afin de garantir la cohérence de l'ensemble.

- J'aurais, à priori séparé les items "handicap visuel" et "handicap auditif" en "non-voyant" / "mal-voyant" et "Sourd"/"mal entendant".

- Il faudrait rajouter la plage braille, qui est un dispositif courant dans la question 7, et retirer dragon natural speaking dans la précision de l'item 4.

- L'implémentation des ancres, qui utilise l'ID d'un élément comme cible est une mauvaise idée.
Cette méthode déplace le focus mais n'assure pas la "prise de focus".

Pour le lien "haut" le focus se déplace sur le fieldset mais la prise de focus se fait sur le premier lien du fieldset (premier élement cliquable), autrement dit le premier lien "haut" ce qui rends la méthode inutilisable pour qui voudrais retourner à la première question.

Pour le lien "bas" le focus est perdus (je suppose dans l'ordonnancement du tabindex) et n'assure pas la prise de focus sur le submit.

Scénario en cause : je clique sur "bas", rien ne se passe, je tabule pour tenter de trouver le focus et je me retrouve au premier lien de la page ("accessibilité").

Il faudrait implémenter des ancres classiques pour rendre le système utilisable.

Je ne comprends pas bien l'utilité du lien "bas", le submit étant jouable tant qu'on est dans la zone du questionnaire, je ne vois pas à qu'elle occasion je peux avoir besoin d'aller très vite en bas de ce questionnaire.

De même, pourquoi aurait-on besoin de revenir en haut de questionnaire dans les étapes intermédiaires.

En revanche on peut avoir besoin de revenir à une question précédente, ou de passer rapidement à une question suivante, lors de la "relecture" d'un questionnaire long.

Un système de navigation plus productif serait d'implémenter à la place des liens "suivant/précédent".

- Ce questionnaire comprends un grand nombre de questions thématiques.

C'est toujours intéressant de structurer ces zones thématique au moyen de l'élément fieldset (c'est sa fonction première).

Ad minima le questionnaire comprends trois groupes de question : les deux première (handicap), les 8 suivantes (internet) et les deux dernières (web pour tous).

Ces trois groupes devraient être implémentés dans trois fieldset différents avec une légende explicite.

a écrit :
Oui je l'ai remarqué hier également même le fait de vouloir remonter à l'aide de la tabulation supprime le texte de l'utilisateur.

Le point 10.4 des WAI qui demande de palier au défaut des "vieux" lecteurs d'écrans concernant l'utilisation de "contrôles" vides en mettant dans les input et textarea des valeurs par défaut est très problématique.

Elle est écidemment toujours complété du celèbre this.value='' destiné à effacer la valeur par défaut.

On conseille généralement ce procédé pour des champs isolés (comme le champs de recherche WAI) et on le déconseille dans le cas de formulaires structurés.

Il y à deux solutions sachant qu'il faut résoudre ce problème:

1. Retirer ces valeurs par défaut et la commande javascript qui va avec.
Ce sera problématique dans des cas assez rares, je n'en ai personnellement jamais entendus parler, même avec des versions désuètes de jaws ou window eyes.

2. Remplacer la commande javascript par une véritable fonction de contrôle de saisie.


JP
Modifié par jpv (25 Jun 2005 - 03:51)

Heuu vos vacances les gars c'est prévu pour 2006 c'est ça

On les prends ensemble?

Je crois clairement que l'on vois le chemin qui nous reste à parcourir "100 km à pieds ça use ça use" .

Mais c'est bien!
Modifié par knarf (25 Jun 2005 - 04:09)

Salut JP

Merci d'avoir pris le temps de faire une analyse si complète

J'aimerai bien que tu nous éclaires sur certains point stp :

jpv a écrit :
retirer dragon natural speaking dans la précision de l'item 4.

Pourquoi ?

jpv a écrit :

Je ne comprends pas bien l'utilité du lien "bas", le submit étant jouable tant qu'on est dans la zone du questionnaire, je ne vois pas à qu'elle occasion je peux avoir besoin d'aller très vite en bas de ce questionnaire.

De même, pourquoi aurait-on besoin de revenir en haut de questionnaire dans les étapes intermédiaires.

C'était surtout en cas de non validation du questionnaire. Actuellement, peu de champs sont obligatoires et peuvent soulever des erreurs mais si le questionnaire venait à évoluer...

jpv a écrit :

En revanche on peut avoir besoin de revenir à une question précédente, ou de passer rapidement à une question suivante, lors de la "relecture" d'un questionnaire long.

Les liens précédant les questions suivantes, est ce bien utile ?

jpv a écrit :

Il y à deux solutions sachant qu'il faut résoudre ce problème:

2. Remplacer la commande javascript par une véritable fonction de contrôle de saisie.

Ok pour cette solution.


En tout cas merci encore JP


Modifié par oli (25 Jun 2005 - 12:16)

Philippe a écrit :
merci Eric pour ce test et ces critiques constrctives. En esperant que d'autres suivront ton exemple

De rien.

Philippe a écrit :

Par contre, pour la navigation sur les boutons radio, chez moi sur FF je navique uniquement avec la touche TAB....bizarre

Tout le monde n'est pas passé à Firefox comme navigateur par défaut . Je suis sous Opera 8.

Cordialement, Eric.
Modifié par Eric (25 Jun 2005 - 22:13)

Pour l'effacement des champs, je vais peut-être dire une bêtise (ça me parait tellement évident...) moi dans mes formulaires j'utilise souvent onfocus="this.select()".

ça a pour effet que lorsque l'utilisateur entre dans le champ, le texte déjà présent est sélectionné :
- s'il tape directement du nouveau texte, il viendra en remplacement
- s'il veut compléter il n'a qu'à déplacer le curseur (clavier/pointage)

Cette solution n'est-elle pas bonne ?

naholyr a écrit :
Pour l'effacement des champs, je vais peut-être dire une bêtise (ça me parait tellement évident...) moi dans mes formulaires j'utilise souvent onfocus="this.select()".

ça a pour effet que lorsque l'utilisateur entre dans le champ, le texte déjà présent est sélectionné :
- s'il tape directement du nouveau texte, il viendra en remplacement
- s'il veut compléter il n'a qu'à déplacer le curseur (clavier/pointage)

Cette solution n'est-elle pas bonne ?

je pense que oui

a écrit :
Pourquoi ?

Je parle de l'item :

a écrit :
Système de commande par le regard (Visioboard, Dragon NaturallySpeaking...)

Ou dragon n'à rien à faire, c'est uniquement un systeme vocal.

Au delà de ça, Dragon natural speaking est un logiciel de dictée, qui ne permets en rien de navigauer sur le web.

Mieux vaudrais le remplacer par les références de lecteur d'écrans : HPR (IBM home page reader) et windows eyes qui sont avec Jaws les trois logiciel les plus utilisés.

a écrit :
C'était surtout en cas de non validation du questionnaire.

Je suis désolé,je dois êre fatigué mais je ne vois toujours pas

a écrit :
Les liens précédant les questions suivantes, est ce bien utile ?

Précédent devrait ramener au focus de la question précédente (N-1) et suivante de la question suivante (N+1).
Après il faut voir comment l'implémenter, logiquement c'est avant la question, comme un lien d'évitement.
Pour améliorer la lisibilité on pourrait numéroter les questions (de toute manière les numéroter est toujours une bonne idée).
Mais évidemment il faut tester et si c'est trop lourd supprimez...
L'idée est d'assurer un moyen simple à la navigation tabulaire d'aller rapidement d'une question à l'autre pendant la relecture car on peut supposer que les utilisateurs vont relire leur réponses avant de les valider.

Pour les boutons radio, la touche spacebar agit comme un switch on/off sr les boutons radios et case à cocher. Ensuite chaque navigateur à sa manière de gérer les items des listes, soit tabulation soit flêche haut/bas.

a écrit :
Pour l'effacement des champs, je vais peut-être dire une bêtise (ça me parait tellement évident...) moi dans mes formulaires j'utilise souvent onfocus="this.select()".

C'est une solution, néanmoins elle oblige à un CTRL Z en cas d'erreur de l'utilisateur.

Il y à d'autres moyen : il suffit d'utiliser un flag, par exemple en rajoutant un caractere au label ou en modifiant la classe CSS et de tester cette valeur au focus, ensuite on efface ou pas fonction du flag.
On assure là une méthode simple.
Pour être complet, la valeur par défaut devrait être la plus courte possible pur ceux qui n'aurait pas javascript d'activé ce qui leur éviterait d'avaoir à effacer une longue suite de caractères.
Dis moi si tu à besoin d'un exemple...

JP

jpv a écrit :

Je parle de l'item : Système de commande par le regard (Visioboard, Dragon NaturallySpeaking...)

Ou dragon n'à rien à faire, c'est uniquement un systeme vocal.

énorme bourde de ma part (copier coller) , merci

jpv a écrit :

Je suis désolé,je dois êre fatigué mais je ne vois toujours pas

non c'est moi qui m'exprime mal ( ) en fait je veux dire que si tu envoie le questionnaire et que tu as fait une erreur en haut de document pas exemple, au lieu de scroller jusqu'en bas de page tu clique sur le lien pour tout passer. Alors c'est vrai que dans le cas des input il suffit de faire entrer mais on ne peut pas pour les textarea.

jpv a écrit :

Il y à d'autres moyen : il suffit d'utiliser un flag, par exemple en rajoutant un caractere au label ou en modifiant la classe CSS et de tester cette valeur au focus, ensuite on efface ou pas fonction du flag.
On assure là une méthode simple.
Pour être complet, la valeur par défaut devrait être la plus courte possible pur ceux qui n'aurait pas javascript d'activé ce qui leur éviterait d'avaoir à effacer une longue suite de caractères.
Dis moi si tu à besoin d'un exemple...
JP

En fait cette fonction est déjà présente mais seulement si tu fais une erreur lors de l'envoie et que tu dois corriger. Si tu veux tester envoie le formulaire avec une @ email erronnée ou vide en ayant précedemment renseigné un ou plusieurs textarea. Tu verras que si tu avais mis quelque chose le texte ne s'effacera pas et si tu n'avais rien mis le texte par défaut s'éffacera.

Merci encore, oli

jpv a écrit :
Pour l'effacement des champs, je vais peut-être dire une bêtise (ça me parait tellement évident...) moi dans mes formulaires j'utilise souvent onfocus="this.select()".

C'est une solution, néanmoins elle oblige à un CTRL Z en cas d'erreur de l'utilisateur.Comprends pas

a écrit :
Il y à d'autres moyen : il suffit d'utiliser un flag, par exemple en rajoutant un caractere au label ou en modifiant la classe CSS et de tester cette valeur au focus, ensuite on efface ou pas fonction du flag.

Oui mais ça c'est pour ne pas effacer lorsqu'on prend le focus une seconde fois, le problème qui était soulevé est tout autre

"Eric" a écrit :
Autre remarque, si j'utilise la tabulation, lorsque j'arrive dans une zone tel qu'un champ de saisie ou un textarea, le contenu informatif s'efface automatiquement et pas le temps de le lire.

C'est gênant si on n'a pas un écran assez haut pour afficher tout le formulaire, et qu'on navigue visuellement mais sans souris.
Modifié par naholyr (26 Jun 2005 - 13:33)

a écrit :
si on se balade avec tabulation et que l'écran n'est pas assez haut pour afficher tout le questionnaire, lorsqu'on arrive sur un champ qu'on n'avait pas encore vu, son contenu est directement effacé et on n'a pas eu le temps de le lire.

La valeur par défaut de ces champs n'est pas destiné à porter de l'information, qui est elle donné par le commentaire et le label.
Elle est juste destiné à donner la possibilité à certains vieux lecteurs d'écrans de pouvoir donner le focus sur le champ.
Malheureusement si celui ci est vide ces vieux lecteurs (et peut-être d'autres dispositifs mais je n'ai encore jamais été confonté à ce cas) ne donne pas le focus et la saisie est donc impossible.

Donc WAI préconise de rentrer une valeur, mais ça peut-être n'importe laquelle un tiret ou un point suffise, ça n'à pas d'importance.

Donc le fait de tabuler sur un champs masqué par l'écran n'à aucune importante, pour un voyant il verra le commentaire et pour un non-voyant le label associé sera lu donc le sujet du champs sera connu.

Ceci dit ce serait intéressant de le revérifier...

a écrit :
en fait je veux dire que si tu envoie le questionnaire et que tu as fait une erreur en haut de document pas exemple, au lieu de scroller jusqu'en bas de page tu clique sur le lien pour tout passer.

Ben... pourquoi aurais besoin de scroller en bas de questionnaire après avoir corrigé une erreur ?
Scénario : je récupère le message d'erreur, je corrige l'ereur, je presse enter et le formulaire est renvoyé...
Je n'ai pas besoin de scroller jusqu'au bouton "envoi".

Quand au sytème de flag je vais préparer une petite demo, ce sera plus simple à comprendre...

JP

jpv a écrit :

Ben... pourquoi aurais besoin de scroller en bas de questionnaire après avoir corrigé une erreur ?
Scénario : je récupère le message d'erreur, je corrige l'ereur, je presse enter et le formulaire est renvoyé...
Je n'ai pas besoin de scroller jusqu'au bouton "envoi".

pas pour les textarea et certains navigateurs

jpv a écrit :

Quand au sytème de flag je vais préparer une petite demo, ce sera plus simple à comprendre...

merci

Modifié par oli (26 Jun 2005 - 13:50)

Bonjour,

Oui bien sur, pour les textarea c normal, dans ce cas là je corrige et je tabule avant de presser enter.

Quels sont les navigateurs en cause (donc qui n'autorise pas le submit sur un enter dans la zone de focus d'un formulaire) ?

D'autres part, si on reste dans la logique de ce système, il faudrait en implémenter entre chaque textarea de la question 11 (En fonction de votre handicap et des outils que vous utilisez pour surfer, pouvez-vous citer des sites...).
Enfin ce lien sur la dernière question est par contre inutile dans tous les cas

Ce n'est pas que je sois absolument contre cette méthode, entendons nous bien, c'est juste que cela me semble charger inutilement le formulaire.

En revanche c'est un excellent sujet de test

JP
Modifié par jpv (26 Jun 2005 - 22:19)

jpv a écrit :

Quels sont les navigateurs en cause (donc qui n'autorise pas le submit sur un enter dans la zone de focus d'un formulaire) ?

Lynx par exemple

jpv a écrit :

Ce n'est pas que je sois absolument contre cette méthode, entendons nous bien, c'est juste que cela me semble charger inutilement le formulaire.
En revanche c'est un excellent sujet de test

en effet

Bonjour,

Oui effectivement lynx ne permets pas ça, pour autant lynx est un cas très particulier qui n'est plus guère utilisé que par les dispositifs emulant VT100 comme certain terminaux brailles autonomes.

Pour la navigation internet le couple lecteur/navigateur vocal ou plage braille couplé au navigateur graphique représente quand même l'immense majorité des cas d'usage.

Le formulaire demandant environ 40 tabulations (ce qui est déjà assez lourd) en rajouter 24 demande de bien peser le bénéfice attendu de la méthode.

D'autres part ces liens ne semblent-ils pas inutiles lors de la première saisie ?

JP

knarf a écrit :

Je crois clairement que l'on vois le chemin qui nous reste à parcourir "100 km à pieds ça use ça use" .

Mais c'est bien!

Paris ne s'est pas fait en un jour, comme on dit !
Le retour des utilisateurs ne se fera pas non plus en un jour ...