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

2015-12-18 Par sujet ROSA Giuseppe (93) 




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 
Pour : liste_gta@list.accessiweb.org
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 
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

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

2015-12-18 Par sujet Jean-Pierre Villain 

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 > 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.


-- 
Olivier Nourry

http://about.me/oliviernourry




Le 2 novembre 2015 14:32, Romain Gervois > 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

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

2015-12-18 Par sujet Olivier Nourry 
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



Le 18 décembre 2015 à 11:17, ROSA Giuseppe (93) <
giuseppe.r...@dgfip.finances.gouv.fr> 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  
> Pour : liste_gta@list.accessiweb.org
> 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  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