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]
<mailto:[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.
--
Olivier Nourry
http://about.me/oliviernourry
<http://about.me/oliviernourry>
Le 2 novembre 2015 14:32, Romain Gervois <[email protected]
<mailto:[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]
<mailto:[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.
--
Olivier Nourry
http://about.me/oliviernourry
<http://about.me/oliviernourry>
Le 2 novembre 2015 13:37, ROSA Giuseppe (93)
<[email protected]
<mailto:[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]>
<mailto:[email protected]>
Pour : [email protected]
<mailto:[email protected]>
<[email protected]>
<mailto:[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
--
Olivier Nourry
http://about.me/oliviernourry
<http://about.me/oliviernourry>
Le 2 novembre 2015 11:08, ROSA Giuseppe (93)
<[email protected]
<mailto:[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 :
o première cellule : l'intitulé de la matière
o 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>
<inputaria-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]
<mailto:[email protected]>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
------------------------------------------------------------------------
_______________________________________________
liste_gta mailing list [email protected]
<mailto:[email protected]>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
_______________________________________________
liste_gta mailing list [email protected]
<mailto:[email protected]>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
_______________________________________________ liste_gta
mailing list [email protected]
<mailto:[email protected]>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
_______________________________________________ liste_gta
mailing list [email protected]
<mailto:[email protected]>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
_______________________________________________ liste_gta mailing
list [email protected]
<mailto:[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
