Un ptit test site svp! à votre bon coeur

(reprise du message précédent)

a écrit :
Il faut avouer que des fois c'est pas facile de se faire une idée de ce qu'il faut mettre en oeuvre exactement entre les specs, les validateurs, les utilisateurs, on se retrouve des fois avec 3 interprétations différentes.

L'accessibilité est un domaine où l'expérience est primordiale et je dirais d'ailleurs qu'il n'y à que ça qui compte, les recommandations du WCAG étant particulièrement réduites et facile à apprendre.

Ceux qui trainent des pieds en se disant qu'il sera toujours temps de prendre le train en route (je parle des professionnels du web) vont avoir des réveils douloureux.

Et si il est facile de former un technicien du code en quelques semaines, moi après 5 années de travail sur le sujet et des dizaines de sites refaits, j'en apprends encore tous les jours, et quand je dis tous les jours c'est vraiment tous les jours.

Là je viens d'apprendre qu'on pouvait mettre un label en dehors d'un formulaire, l'idée ne m'en était même jamais venu, tant il parait naturel de l'associer dans le code à son contrôle, ce qui est recommandé par tout le monde...

Peu-être n'est ce finalement pas aussi important que ça et peu-être même que ça ouvre des perspectives, par exemple à goetsu et à pas mal d'autres auteurs auxquels ça pose problème dans des tables de layout.

Tu m'aurais inttérrogé y'à deux heures la dessus je t'aurais "affirmé" mordicus que c'était une erreur et un contre-sens et je me serais trompé.

C'est sur que comme tout les domaines "d'expertise" l'apprentissage est plus long, mais ce qui en fait également son intérêt.

JP

a écrit :

Pas forcemment, pour les checkbox il n'est pas rare de trouver le label après la checkbox sans que cela ne gêne les utilisateurs ce qui est important c'est de lier explicitement le label et l'input avec le for="".

Cela ne gène pas les utilisateurs pourquoi?

Parceque avec le temps ils ont finis par s'y faire.

Parce que cela n'est pas particulièrement génant.

Sans parler du coté visuel le fait de placer le label avant le contrôle peut il amener un confort utile et pertinent dans la navigation.

EDIT:

Je prends par exemple le questionnaire de web-pour-tous ou les labels sont apres les bouton radios et les cases à cocher.

Doit on dans un soucis d'accessibilité et de confort permuté nos labels ou peut on laisser en l'état en étant sur que cela ne cause aucune gène.

Parceque là je me précipitais sur mon éditeur html favoris (dreamweaver ) pour tous changer sur notre questionnaire .
Modifié par knarf (22 Jul 2005 - 18:48)

Il y à aussi la solution très facile et très profitable :
Placer le label avant le controle, comme ça s'est toujours tout bon, et le repositionner derrière en CSS...

Ca marche dans tous les cas, les label sont toujours à la même place dans le flux ce qui assure la cohérence de l'ensemble et c'est facile...

jp
Modifié par jpv (22 Jul 2005 - 18:47)

Donc je vais quand même me précipité sur mon editeur favoris

En parlant de placer un label avant le contrôle, je visais explicitement le cas des input text . Dans ce cas précis, le respect de l'ordre "naturel" étiquette > champs permet, lorsque le formulaire est parcouru linéairement, d'anticiper la présence du champ et la nature de l'information à y entrer.

Outre des rendus vocaux par des outils n'implémentant pas le for= (Opera 8.0 par exemple), cela peut être particulièrement important lorsque l'utilisateur n'a accès qu'à une portion de contenu à la fois, et que la "navigation" dans ce contenu n'est pas aisée :
- tablette braille
- loupe

Un ordre inattendu peut désorienter et obliger à des manipulations parfois longues (explorer certains formulaires avec une loupe peut être particulièrement ardu). Il faut donc simplement que l'ordre HTML et visuel du formulaire soit aussi intuitif que possible.

<edit>Cet ordre "naturel" de l'information, qui n'est pas évident à déterminer parfois, est également important face aux déficits cognitifs</>
Modifié par Laurent Denis (22 Jul 2005 - 18:57)

a écrit :

je visais explicitement le cas des input text

Oui j'ai encore lu et répondu trop vite.

Mais dans une logique de lecture dans le flux j'avais pensé de suite aux label des cases et boutons.

Donc je vais faire en sorte que les labels soient luent en premier dans le flux sans toucher à l'ordre graphique.

Au passage, je me permets deux suggestions à propos de http://www.web-pour-tous.org/QuestionnaireWPT :

- donner des valeurs par défaut aux attributs rows et cols des textarea : sans CSS, le résultat peut être... assez inconfortable

- corriger ce fichu javascript qui vide les textarea de leur contenu par défaut. En effet, imagine que je remplisse le premier textarea, suant à grosses gouttes pour ne pas faire de fôtes... Tout content, je passe au second quand tout à coup, je m'aperçois que j'ai justement fait une fôte dans le premier. Je clique donc dans mon texte pour le modifier... et... et ? Devinez ce qu'il fait, le javascript ?
Modifié par Laurent Denis (22 Jul 2005 - 19:20)

hehe toujours faire un copier coller du texte qu'on vient de pondre , on est jamais assez prudent. Ceci dit, je ne vois pas directement l'interêt de mettre ca sur un textarea. On est pret à tapper une tartine , ce n'est pas un double clique + delete qui va nous importuner.
Modifié par Vlili30 (22 Jul 2005 - 19:46)

En fait, c'est la présence du texte par défaut des champs textes sur laquelle on peut s'interroger:
- c'était une recommandation temporaire de la WCAG1.0, destinée à compenser la non reconnaissance des champs vides par certains lecteurs d'écran (pas de focus possible), ou l'absence de support de <label>.
- elle est aujourd'hui considérée comme périmée par la future WCAG2.0
- ces textes par défaut sont plus une gène qu'autre-chose pour l'utilisateur (on ne se rend pas forcément compte dans un lecteur d'écran, par exemple, qu'on est en train d'ajouter du texte au texte par défaut, et qu'il fallait d'abord effacer celui-ci)
- mais il subsisterait un doute sur son inutilité : tous les dispositifs braille actuel peuvent-ils rendre un champ vide, dns le cas où ils n'exploitent pas les sattributs size/cols/rows ? Il semble que ce soit le cas...

a écrit :
Cet ordre "naturel" de l'information, qui n'est pas évident à déterminer parfois, est également important face aux déficits cognitifs

Le cas des handicaps cognitifs est extrèmement difficile à traiter car les solutions, notamment en terme d'ergonomie, vont quasi-systématiquement à l'encontre du confort d'utilisation attendus par les autres publics.

Par exemple dans le cas du formulaire de web pour tous, il pourrait être intéressant de le séquencer en plusieurs parties afin de "guider" les handicaps cognitifs.

Evidemment les autres publics trouveraient ça idiot...

Il y à un véritable travail à faire sur l'utilisation du web pour les handicaps cognitifs qui n'est vraiment pas évident, il y à nottamment très peut d'études par rapport aux autres handicaps.

JP

a écrit :

Un formulaire comme celui de Web-pour-tous pourrait, AMHA, être présenté en deux versions au choix : séquencé / d'un seul tenant. Reste à rendre le choix lui-même accessible

Oui absolument c'est en général ce qu'on utilise, ce qui est d'ailleurs la seule application "intelligente" de la notion de "site alternatif", car ce principe peut également être appliqué à d'autres section d'un site...

@Laurent : je ne connaissais pas cet article, merci du lien

JP
Modifié par jpv (22 Jul 2005 - 20:53)

malheureusement en anglais

J'adresse mes excuses à Mme pots pour avoir foutu le bronx dans ces cours d'anglais plutôt que de suivre
Modifié par knarf (22 Jul 2005 - 21:48)

bon j'ai corrigé les liens d'évitement en mettant les liens vers
<a href="#" name="contenu_site"></a> qui lui semble fonctionne partout.

Merçi à tous de vos commentaires

Tu peux te contenter de :

<a name="contenu_site"></a>

Si c'est juste pour faire un point d'ancrage

Non justement IE n'aime pas si l'attribut "href" n'est pas présent et ne prendras pas le focus sur le lien suivant l'ancre en cas de tabulation.

Il se déplacera par contre bien visuellement sur ton ancre mais c'est tout.

Donc l'attribut href est important au contraire.