Je me disais justement qu'il fallait réouvrir ce fil de discussion pour la question des loupes d'écran, discutée en off avec JP récemment ;-) [clin d'oeil]
Une question que je me pose: dans une perspective responsive web design, quelle liberté a-t-on pour réorganiser l'affichage d'un tableau avec nombreuses colonnes, sur un écran étroit? On peut a priori remettre en cause entièrement la structure de tableau pour en faire tout autre chose en CSS3. Mais du coup, est-ce que ça vaut le coup de se prendre la tête à partir sur un tableau, et ne vaut-il mieux pas directement adopter un affichage de grille, plus souple, à base de conteneurs empilés? (sachant qu'au final on fait tout ce qu'on peut avec cette construction via TABLE pour se débarrasser des propriétés de TABLE...) [image: --] Olivier Nourry [image: http://]about.me/oliviernourry <http://about.me/oliviernourry> Le 18 décembre 2015 à 11:17, ROSA Giuseppe (93) < [email protected]> a écrit : > Merci Jean-Pierre pour ces précisions, j'avais effectivement omis le cas > des utilisateurs de loupe d'écran. Je transmets tes recommandations. > > Bonnes fêtes. > > 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 : Jean-Pierre Villain <[email protected]> <[email protected]> > Pour : [email protected] > Date : 18/12/2015 10:26 > > Bonjour, > > Je n'avais pas vu cette conversation, je me me permet d'ajouter mon grain > de sel et quelques précisions. > > Comme tout le monde l'utilisation d'un tableau de données est à proscrire. > En revanche la solution de labels cachés ou de liaison aria-labelledby > peux être insuffisante, par exemple pour les utilisateurs de loupe d'écran > qui ne voyant qu'une portion du tableau risque de perdre l'information du > label fournie par les en-têtes. > Ce souci est habituel sur les tableaux de grande dimension mais il peut > être, dans le cas de champ de formulaire considérablement amélioré en > traitant un label caché en tooltip ou en utilisant un title de préférence à > aria-labelledby. > > Pour les fieldset, le critère est "Critère 11.5 [A] Dans chaque > formulaire, les informations de même nature sont-elles regroupées, si > nécessaire ? " ce qui laisse tout le loisir d'adapter l'exigence de la > présence d'un fieldset. > > Si les labels sont suffisamment explicites le couple fielset/legend > devient naturellement inutile. > > J'aurais donc tendance traiter ce cas en tableau de présentation, les > lignes et colonnes d'en-tête en aria-hidden true et des labels masqués, > suffisamment pertinents pour éviter le fieldset, traités en tooltip au > moment de la prise d'action (souris/clavier naturellement). > > JPV > > > > > Le 09/11/2015 14:32, Romain Gervois a écrit : > > 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 > [email protected]http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > > -- > _____________________________________ > Jean-Pierre VILLAIN - @villainjp - +33 (0)6 98 08 50 49 > Expert senior, formateur et responsable du pôle R&D > Access42 : expertise, conseil et formation en accessibilité numérique+33 (0)1 > 78 17 88 55 - access42.net - @access42net > > ------------------------------ > > _______________________________________________ > 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
