Re: [Accessibilite] Question pour du développement web sur un logiciel libre.

[Philippe Vayssière <philippe AT vayssiere.fr>]

Le 23/02/2012 22:58, Denis Chenu a écrit :
> Le 23/02/2012 20:12, Vincent Aniort a écrit :
>> bonjour Denis,
>> belle intention,
>> pour ce qui est des cases à cocher dans des tableaux :
>> attention galère !
>> les cases à cocher comme les radio boutons et les autres éléments de
>> formulaires dans des taleaux dont les en-têtes sont les labels, les
>> principales aides technique ne les supportent pas ! Donc préférer : un
>> label caché hors champ reprenant l'entête de ligne et colonne ou mieux
>> faire comme un tableau (visuellement) et au niveau du code mettre un
>> fieldset avec un legend reprennant l'entête de ligne et un label pour
>> la colonne (ou inversement).
>> Pour ce qui est de l'utilisation d'Aria(qui n'est pas du CSS3, c'est
>> de ARIA 1.0) son support est loin d'être ubiquitaire parmi les aides
>> techniques (seul les dernières version de certains d'entre eux
>> supportent certaines propriétés mais labelledby c'est bon !). En
>> revanche, c'est facile à implémenter et pratique à utiliser, donc à
>> utiliser !
>>
>> Pour les fieldset, c'est à utiliser avec parcimonie, que quand c'est
>> nécessaire donc que deux champs d'un même formulaire ont le même label !
>> Pour la priorisation, ç'est function du contenu de ta page que l'on
>> peut statuer. Mais c'est pour le cas que tu cites, tableau avec scope
>> avant les fieldset !
>> voilà a+
>>
>>
>> -- 
>> Vincent Aniort
> Merci beaucoup,
>
> Donc pour les formulaires dans les tableaux, si je comprend bien, la
> priorité serait les scope bien pensés, puis ajouter les labelledby pour
> l'avenir (et c'est vrai que c'est très facile). De mon coté, c'est
> facile à mettre en place et cela est faisable sur l'ensemble des
> différents tableaux.
> Ensuite selon le type de tableaux ( choix unique, choix multiple, texte
> etc ... ), utiliser des labels ou des fieldset là ou cela est
> intéressant, éventuellement complété par des aria-describedby.
> Si cela intéresse certain, je pourrais envoyer un lien pour les types de
> questions les plus complexe à gérer pour moi. La difficuté étant que les
> utilisateurs peuvent aussi faire n'importe quoi.
>
> Merci encore,
>
> Denis
Bonjour Denis,

j'ai noté 3 discussions sur les mailing-list Access-tech et avant cela
sur celle du groupe de travail Accessiweb. De la plus récente à la plus
ancienne :
-
http://archives.rezo.net/archives/accesstech.mbox/7CM32HLFNFPDKLC5ND57XOFHCPE4BVDO/
-
http://list.accessiweb.org/pipermail/liste_gta_list.accessiweb.org/2011-October/thread.html#2573
-
http://list.accessiweb.org/pipermail/liste_gta_list.accessiweb.org/2010-October/001817.html
(la "question 23" à laquelle je fais référence dans ma question renvoie
une 404 mais c'est exactement le type de sondage avec tableau farci de
cases à cocher ou de boutons radio dont tu parles)

Ces tableaux avec 1 question par ligne et autant de colonnes que de
réponses possibles (oui, non, peut-être, non applicable, beaucoup, à la
folie, etc) sont problématiques quand il y a un élément de formulaire
dans chaque cellule. Les lecteurs d'écran ne se comportent alors pas
"normalement" en mode lecture mais sont en mode (remplissage de)
"formulaire".
Sur une feuille de papier, l'affichage des résultats en tableau ou des
cases organisées en tableau ne pose pas de problème, si cela reste d'une
taille raisonnable et si l'on peut retrouver facilement à quelles ligne
et colonne appartient chaque case.
Pour présenter des résultats, un tableau bien codé est également une
bonne solution (éléments th en haut et à gauche, attributs
scope="col|row" sur ces th).
Pour poser plusieurs questions aux réponses similaires, là par contre il
faut tester avec un maximum d'assistances techniques (AT).

Au sein de ma boîte, nous avons eu à créer un système de sondage très
accessible (les personnes qui répondaient étaient à 100% des étudiants
ou anciens étudiants handicapés). Au vu de cette contrainte j'ai fait le
choix de séparer les questions "en tableau" en autant de questions
successives. Ça augmentait de 30% le nombre déjà conséquent de questions
mais cela évitait des problèmes avec des assistances techniques que ni
nous ni le client n'auraient pu tester et cela évitait également que les
agrandisseurs d'écran (loupes) n'affichent pas en même temps la
question, les entêtes de colonne et les cases ou boutons radio.
Mais j'imagine que pour un logiciel libre utilisé par tout un chacun,
supprimer ces tableaux n'est pas une option ; c'est ancré dans les
habitudes.

Parmi les pistes possibles :
Une liste de choix (select) peut remplacer un ensemble de boutons radio
et c'est tout aussi compact. Par contre pour remplacer un ensemble de
cases à cocher, le select multiple est une horreur ergonomique (à mon
avis) et très peu de monde sait que Ctrl et Shift permettent de
sélectionner plusieurs options, même en le rappelant juste avant dans un
texte. Là aussi ce n'est pas une option viable, enfin utilisable.

On peut utiliser un fieldset avec legend autour de chaque ensemble
d'éléments de formulaire et styler le tout comme une table.
Je viens d'en réaliser un exemple : http://jsfiddle.net/PhilippeVay/4fWA5/
- chaque question est un élément legend placé à gauche,
- les étiquettes envoyées hors écran (donc encore lues par un lecteur
d'écran puisqu'associées via for/id mais plus visibles),
- les boutons radio sont légèrement agrandis et centrés dans un élément
de largeur fixe avec un attribut title identique à l'étiquette.
Visuellement on fait précéder ces fieldset par une liste des réponses
possibles, bien alignées verticalement, pour que ça ressemble à une
table. C'est là qu'est l'inconvénient de cette solution : cette liste
est utile visuellement lorsque les CSS sont activées mais pas CSS
dsactivées et pas non plus pour les lecteurs d'écran. Dans ce cas j'ai
rajouté un attribut aria-hidden="true" pour ceux chez qui ça
fonctionnera mais il faudrait peut-être ajouter un texte (hors écran)
expliquant à quoi sert cette liste, que ce sont juste les réponses aux
questions qui vont suivre.
En pratique l'affichage est à peu près correct sous IE7 (c'est à cause
de lui qu'il y a un span dans le legend) mais je n'ai pas pris le temps
de corriger pour IE6. Limesurvey supporte-t-il encore IE6 ?

Voilà c'est une solution parmi d'autres, qui prend le parti de choisir
les éléments HTML sans se soucier par avance du résultat graphique
attendu et de se débrouiller ensuite en CSS pour obtenir le résultat
voulu. Il y aurait même plus simple pour IE8+ uniquement avec display:
table;

Cordialement,
Philippe
--
alsacreations.com - alsacreations.fr