Re: [Liste GTA] Champ de formulaires & cellules de tableaux

[ROSA Giuseppe (93)]

Merci pour ces précisions. Je pense que l'argument RWD peut notamment jouer en la faveur de la solution que tu proposes. Il faut juste que je trouve le temps de m'y plonger. Si je ne propose pas un proto fonctionnel je n'arriverai pas à faire adopter cette solution. Encore merci, ainsi qu'à Romain du temps consacré pour vos conseils. 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 14:03 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.   Olivier Nourry about.me/oliviernourry     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 Olivier Nourry about.me/oliviernourry     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