Giuseppe, j'oubliais cette très bonne introduction aux propriétés display:table <http://www.alsacreations.com/tuto/lire/610-Mise-en-page-CSS-avancee-grace-a-la-propriete-display.html> sur le site d'Alsacréations.
[image: --] Olivier Nourry [image: http://]about.me/oliviernourry <http://about.me/oliviernourry> Le 2 novembre 2015 14:03, Olivier Nourry <[email protected]> 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. > > > > > [image: --] > Olivier Nourry > [image: http://]about.me/oliviernourry > <http://about.me/oliviernourry> > > > Le 2 novembre 2015 13:37, ROSA Giuseppe (93) < > [email protected]> 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 <[email protected]> <[email protected]> >> Pour : [email protected] <[email protected]> >> <[email protected]> >> 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 >> [image: --] >> Olivier Nourry >> [image: http://]about.me/oliviernourry >> <http://about.me/oliviernourry> >> >> >> Le 2 novembre 2015 11:08, ROSA Giuseppe (93) < >> [email protected]> 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 >>> [email protected] >>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>> >>> >> ------------------------------ >> >> _______________________________________________ >> liste_gta mailing >> [email protected]http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >> >> _______________________________________________ >> liste_gta mailing list >> [email protected] >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >
_______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
