Bonjour Olivier, Désolé pour ma réponse tardive. J'ai effectivement mal lu ta précédente réponse. On est donc d'accord sur le fait que si il y a utilisation d'un tableau, il doit s'agir d'un tableau de présentation et non de données. Pour ARIA, il s'agit ici surtout de réaliser les liaisons input et pseudo-en-têtes, rien de plus ; on est loin de la bidouille et, pour le coup, ça n'évite de toute façon pas les redites. On pourrait imaginer une implémentation s'appuyant sur ARIA pour gérer ça mais ça touche au problème de support et du "où doit-on s'arrêter ?".
Concernant la redistribution d'un tableau de présentation en contexte responsive, je n'ai pas d'exemple à dispo (c'est forcément du spécifique pour le coup). Mais il suffit d'appliquer des display block sur les éléments td pour réaliser une simple linéarisation de ce tableau et de masquer/afficher les éléments nécessaires à la situation. Alors, il faut bien avoir en tête que dans le cas évoqué, c'est jouable. Dans un cas où il s'agit d'un tableau de données ça peut être bien autre chose... Concernant le problème du support, il s'agit surtout de mesurer la réelle pérennité de l'implémentation (quelle soit pour contourner ou pour améliorer). Et ça, effectivement, ça dépend de plein de facteurs (compétences du concepteur, impacts réels du problème, projet...). Romain Le 2 novembre 2015 15:47, Olivier Nourry <[email protected]> a écrit : > Bonjour Romain, > > J'ai bien précisé que c'est l'utilisation d'un tableau de données qui me > parait un détournement. Bien sûr un tableau de présentation sera > transparent s'il est bien fait, et tant que l'ordre de lecture est cohérent > avec l'interface, et que le code est bien formé, ça ne me pose pas de > problème -- modulo le RWD, mais j'y reviens plus tard. > Par contre bidouiller en ARIA un tableau "de données", sémantiquement > parlant, pour lui faire jouer ce rôle de combinateur de labels en évitant > les redites, me parait un brin tiré par les cheveux. Pas d'objection, non > plus, cependant, tant que ça marche et que l'utilisateur s'y retrouve. > C'est bien sur ce dernier point que j'ai un doute - à lever avec des tests. > > Je suis allé un peu vite pour dire qu'on ne pouvait pas "casser" un > tableau en RWD pour le réagencer en largeur étroite. Mais n'ayant jamais vu > la chose en pratique, j'ai du mal à imaginer comment l'en-tête se > positionne si les lignes (fonctionnelles) sont distribuées sur plusieurs > lignes (graphiques)? Tu as un exemple à dispo? Ça me parait tellement > contradictoire avec le principe des lignes et colonnes que je bute, > mentalement, sur la forme que ça peut prendre. > > Sur le problème de support de fieldset: l'éternel débat... faut-il coder > pour contourner les bugs, ou suivre la ligne claire du standard et croiser > les doigts?... Chaque projet aura une réponse, pas forcément toujours la > même. > > > > [image: --] > Olivier Nourry > [image: http://]about.me/oliviernourry > <http://about.me/oliviernourry> > > > Le 2 novembre 2015 14:32, Romain Gervois <[email protected]> a > écrit : > >> 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 >> >> > > _______________________________________________ > 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
