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 <[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 > >
_______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
