Merci à tous les deux, je pense que chaque solution à ces avantages et ces inconvénients.

Merci aussi Olivier pour le lien sur les display table

Merci aussi Romain pour le renseignement sur la différence de restitutions des vocalisateurs sur les fieldset/legend

Cordialement,

DGFiP Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda
tel : 01.573.36.997
pièce : 2388
 



Adoptez l'éco-attitude.
N'imprimez ce mail que si c'est vraiment nécessaire


-------- Message original --------
Sujet : Re: [Liste GTA] Champ de formulaires & cellules de tableaux
De : Romain Gervois <cont...@romaingervois.fr>
Pour : GTA <liste_gta@list.accessiweb.org>
Date : 02/11/2015 14:32
Considérer des tableaux de mise en forme comme du détournement revient à les interdire (même dans les différents textes, personne n'ose le faire). On peut bien sur revenir aux pratiques anciennes où les table/tr/td sont devenus des div/span... Perso, je préfère un tableau de mise en forme assumé et bien implémenté que de passer par des solutions bancales et chiantes full CSS.

Olivier écrit :
Face à cette construction, le lecteur d'écran va rentrer dans quel mode? Formulaire ou tableau? Je ne sais pas trop, et je ne sais pas non plus comment l'utilisateur comprendra réellement la chose -- Tu as sûrement un avis plus pertinent que moi sur la question!

Il faudrait faire des tests plus large ; en tout cas, sous VO OS X (avec role presentation) le tableau est totalement omis. Et en fait, je vois même pas le problème selon le mode de navigation choisit et la façon dont l'utilisateur va utilisé son lecteur ça va dépendre...

Olivier écrit :
La longueur réelle des labels ne joue pas trop, puisqu'ils sont cachés avec mon "affichage tableau".
La solution que je te propose n'est pas plus complexe, en termes de code, qu'une table; si tu crées un plug-in de zéro, cela reviendra au même. L'avantage est que sur un design responsive, en largeur étroite tu pourras facilement revenir à une représentation en fieldset, où tu fais réapparaitre les labels, et tu positionnes les boutons les uns en dessous des autres. Chose impossible avec un tableau, pour lequel la largeur minimale sera la somme de celles des colonnes.

Sur l'implémentation, ça ne changera effectivement rien. Par contre dire que c'est impossible avec un tableau, c'est une erreur. On peut jouer avec la propriété display pour réadapter comme on veut. D'ailleurs, fieldset et legend sont détestés par nos amis intégrateurs lors de l'application de styles (donc tu vas devoir retomber sur des div/span pour faire ce que tu veux faire).

Enfin pour finir, le support de fieldset et legend est très inégal. Par exemple, VO ne vocalise pas la légende du regroupement, les versions (certaines ? toutes ?) des JAWS restituent à chaque champ la légende... Donc entre l'implé de rêve (full CSS, sémantique et cie) et la pratique, par moment, il faut savoir faire quelques écarts.

Romain




Le 2 novembre 2015 14:03, Olivier Nourry <olv.nou...@gmail.com> a écrit :
L'usage d'un tableau de données ne me parait pas souhaitable car c'est à mon sens un détournement d'usage de l'élément (même si on a vu pire!). Face à cette construction, le lecteur d'écran va rentrer dans quel mode? Formulaire ou tableau? Je ne sais pas trop, et je ne sais pas non plus comment l'utilisateur comprendra réellement la chose -- Tu as sûrement un avis plus pertinent que moi sur la question!
La longueur réelle des labels ne joue pas trop, puisqu'ils sont cachés avec mon "affichage tableau".
La solution que je te propose n'est pas plus complexe, en termes de code, qu'une table; si tu crées un plug-in de zéro, cela reviendra au même. L'avantage est que sur un design responsive, en largeur étroite tu pourras facilement revenir à une représentation en fieldset, où tu fais réapparaitre les labels, et tu positionnes les boutons les uns en dessous des autres. Chose impossible avec un tableau, pour lequel la largeur minimale sera la somme de celles des colonnes.



Le 2 novembre 2015 13:37, ROSA Giuseppe (93) <giuseppe.r...@dgfip.finances.gouv.fr> a écrit :
Merci Olivier pour ta réponse.

En effet, je sais qu'on ne peut pas croiser les fieldset avec les cellules de tableaux, c'est pourquoi j'ai par ailleurs chercher s'il existait des role fieldset et legend, mais ce n'est à priori pas le cas. La solution du tableau intéressait le client pour des questions d'alignement et parce que ces tableaux seront en fait généré par un CMS, le contenu ajouté probablement par des contributeurs non développeur. Je cherchai donc un moyen "d'émuler" le comportement du fieldset à partir du tableau.

La solution display table est une solution que j'avais mis de côté bien qu'elle semblait intéressante car je la maîtrise imparfaitement (donc me demandera un peu de temps) et j'ai peur d'avoir du mal à donner des indications pour l'auto-générer ensuite avec des plugins drupal. Mais je vais regarder de plus près puisque c'est une solution que tu sembles également penser viable.

Pour information, les labels de l'exemple, sont donnés juste pour illustration. Ceux utilisé sont généralement plus long (20 à 30 caractères)

A ton avis, la solution 1 : tableau de donnée peut elle être viable ou est à proscrire ?

Merci encore pour ta réactivité et ton analyse.

Cordialement,

DGFiP Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda
tel : 01.573.36.997
pièce : 2388
 



Adoptez l'éco-attitude.
N'imprimez ce mail que si c'est vraiment nécessaire


-------- Message original --------
Sujet : Re: [Liste GTA] Champ de formulaires & cellules de tableaux
De : Olivier Nourry <olv.nou...@gmail.com>
Pour : liste_gta@list.accessiweb.org <liste_gta@list.accessiweb.org>
Date : 02/11/2015 12:55
Bonjour Giuseppe,

L'inconvénient de ta solution 2 (fieldset dans une table) est qu'on ne peut pas "croiser" de la sorte fieldset et table, ça casse le code HTML. Ou alors il faut faire une table à l'intérieur de chaque fieldset, et une table à 1 colonne comme wrapper. Bof bof.
Perso j'aurais fait une suite de fieldset, un par matière, avec des label à chaque bouton.
Pour obtenir la représentation visuelle que tu décris, j'aurais ensuite mis ça en lignes, caché les label (mais est-ce nécessaire?), et aligné avec des propriétés display de la famille table-* ou équivalent.
Les textes dans la 1ère ligne, rappelant la fonction des boutons, ne sont alors utiles que pour la représentation visuelle, pas besoin de les relier aux boutons.
De cette manière, en lecture non visuelle, c'est accessible (avec un peu d'infos en trop, celles de la première ligne); et en visuel, on a les informations et l'alignement nécessaires pour comprendre la fonction de chaque bouton radio.

J'espère t'avoir été utile
 J'espère t'avoir été utili
 

Le 2 novembre 2015 11:08, ROSA Giuseppe (93) <giuseppe.r...@dgfip.finances.gouv.fr> a écrit :
Bonjour la liste,

Je voulais connaître votre avis sur la meilleur manière d'implémenter un formulaire présenter dans un tableau (plusieurs "clients" semblent impacter chez nous par ce type de présentation).

Je pense qu'il s'agit d'un cas déjà rencontré, puisque des outils de génération de questionnaire en ligne doivent générer des cas similiaires.

Dans le dernier cas qu'il m'a été soumis, il s'agit d'une sorte de formulaire de notation (pour faire simple) :
  • Sur la première ligne les intitulés des notes
  • Sur les lignes suivantes :
    • première cellule : l'intitulé de la matière
    • cellules suivantes : bouton radio (symbolisé ci-dessous par ©)

 Bon
Moyen
Mauvais
Matière 1
©
© ©
Matière 2
© © ©
Matière 3
© © ©

Le problème est doit-on (ou est-il préférable) traiter ce tableau en tant que tableau de données, et dans ce cas les cellules de la première ligne et de la première colonne seraient les cellules d'en-tête.
Par contre, les contenus de ces en-têtes peuvent-ils être considérés comme les étiquettes des cases boutons radio (cas prévus pour rendre explicite des liens mais je n'ai pas l'impression que cela soit le cas pour des boutons radio, cases à cocher voire champ de saisie de formulaire). Si je rajoute des labels (aria-label ou autre), j'ai un redondance d'information (intitulé de la cellule d'en-tête + étiquette du bouton).

Une autre solution serait de traiter cela comme un tableau de présentation, avec un label (aria-label ou aria-labelledby par exemple) sur chaque bouton, avec un aria-hidden sur la 1ère ligne. Par contre, je ne sais pas si on peut regrouper chaque ligne pour simuler le cas d'un fieldset/legend afin d'éviter de répéter à chaque bouton le nom de la matière et ainsi fonctionner comme avec une succession de groupement tel que celui-ci :
<fieldset>
    <legend>Matière 1</legend>
    <input aria-label="Bon" type="radio" value="
Bon" name="M1">
    ...
</fieldset>

Si vous avez des suggestions du meilleur traitement d'un cas tel que celui-ci je suis preneur.

Avec tous mes remerciements pour cette lecture.

Cordialement,

DGFiP Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda
tel : 01.573.36.997
pièce : 2388
 



Adoptez l'éco-attitude.
N'imprimez ce mail que si c'est vraiment nécessaire


_______________________________________________
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org



_______________________________________________ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org


_______________________________________________
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org



_______________________________________________
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org



_______________________________________________ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org




_______________________________________________
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Répondre à