5568 sujets
Sémantique web et HTML
<ol>
<li>Vous</li>
<li>aviez</li>
<li>remarqué</li>
<li>qu'une</li>
<li>phrase</li>
<li>est</li>
<li>une</li>
<li>liste</li>
<li>ordonnée</li>
<li>de</li>
<li>mots</li>
<li>?</li>
</ol><ol>
<li><p>De même, un article est bien souvent une liste ordonnée de paragraphes.</p></li>
<li><p>Il me semble indispensable de mettre des listes UL et OL à la moindre occasion.</p></li>
</ol>Plus sérieusement, ne pas confondre une séquence (suite d'éléments de même nature) avec une liste au sens de la spécification HTML.
Un repère qui va bien: si dans une représentation visuelle des marqueurs tels que des nombres (énumération) ou des puces semblent excessifs ou même parasites, alors on n'a probablement pas besoin d'une liste HTML.
Modifié par fvsch (04 Dec 2011 - 23:58)
Bonsoir Florent
Merci pour cette démonstration éloquente (un brin moqueuse ?
), du coup j'ai été rechercher la définition des listes au sens de la spécification HTML sur la-grange.net et j'avoue que je ne suis guère plus avancée...
Je t'explique mon point de vue et ma problématique : j'ai une page référence où j'affiche une liste de clients. Si je devais la traiter avec simplement leur nom, j'utiliserai une liste car pour moi c'est une énumération. Là, je mets leur logo + leur nom (figure + figcaption) mais pour moi, c'est toujours une liste d'énumération... je voulais donc savoir si les balises figure et figcaption "remplaçaient" les balises ul et li pour structurer cette information.
Dans la même optique, j'ai des pages réalisations qui affichent des couples "image + légende" mais qui n'ont pas de liens entre eux (sauf qu'ils font partis de la même rubrique, exemple réalisation > édition) et pour moi, là aussi, c'est une liste d'énumération...
Ce matin en cherchant si je ne pouvais pas attribuer un "role" aux balises figure, je suis tombée sur ce lien : http://dev.w3.org/html5/alt-techniques/#nested
Modifié par cilou (05 Dec 2011 - 14:55)
Merci pour cette démonstration éloquente (un brin moqueuse ?
), du coup j'ai été rechercher la définition des listes au sens de la spécification HTML sur la-grange.net et j'avoue que je ne suis guère plus avancée...Je t'explique mon point de vue et ma problématique : j'ai une page référence où j'affiche une liste de clients. Si je devais la traiter avec simplement leur nom, j'utiliserai une liste car pour moi c'est une énumération. Là, je mets leur logo + leur nom (figure + figcaption) mais pour moi, c'est toujours une liste d'énumération... je voulais donc savoir si les balises figure et figcaption "remplaçaient" les balises ul et li pour structurer cette information.
Dans la même optique, j'ai des pages réalisations qui affichent des couples "image + légende" mais qui n'ont pas de liens entre eux (sauf qu'ils font partis de la même rubrique, exemple réalisation > édition) et pour moi, là aussi, c'est une liste d'énumération...
Ce matin en cherchant si je ne pouvais pas attribuer un "role" aux balises figure, je suis tombée sur ce lien : http://dev.w3.org/html5/alt-techniques/#nested
Modifié par cilou (05 Dec 2011 - 14:55)
Tout est une liste est une liste est une liste est une liste.
De la même manière que dans un article, si tu listes des objets ou des personnes en donnant peu de détails une liste UL ou OL peut être adaptée.
Si tu commences à avoir suffisamment d'info pour basculer sur du titrage (H2, H3, H4... suivant ta structure), tu peux abandonner la liste.
Si tu as des éléments structurants un peu «forts», un balisage de liste en prime peut être lourd ou redondant.
Pour des FIGURE avec peu d'informations (pas de besoin d'utiliser du titrage), j'ai envie de dire que c'est kif-kif: ça passe avec ou sans liste (déjà un peu structuré sans liste, et pas trop lourd avec), et à la rigueur on s'en fout.
J'ai envie de dire pourquoi pas.
Du grand n'importe quoi: inutile et inefficace.
Inefficace car recommander une structure un peu complexe, en particulier avec des imbrications d'éléments pour surcharger sémantiquement, c'est juste une connerie. L'espoir que ça soit bien fait par les auteurs est faible, de même que l'espoir que ça soit bien interprété ou exploité par les navigateurs et aides techniques.
Inutile car leur exemple marcherait beaucoup mieux avec un HN avec comme texte «The castle through the ages» (pour les dates, elles sont en légende de chaque image, et si on tient vraiment à les avoir au départ on rajoute un paragraphe d'introduction), suivi par les différents FIGURE.
cilou a écrit :
Je t'explique mon point de vue et ma problématique : j'ai une page référence où j'affiche une liste de clients. Si je devais la traiter avec simplement leur nom, j'utiliserai une liste car pour moi c'est une énumération.
De la même manière que dans un article, si tu listes des objets ou des personnes en donnant peu de détails une liste UL ou OL peut être adaptée.
cilou a écrit :
Là, je mets leur logo + leur nom (figure + figcaption) mais pour moi, c'est toujours une liste d'énumération... je voulais donc savoir si les balises figure et figcaption "remplaçaient" les balises ul et li pour structurer cette information.
Si tu commences à avoir suffisamment d'info pour basculer sur du titrage (H2, H3, H4... suivant ta structure), tu peux abandonner la liste.
Si tu as des éléments structurants un peu «forts», un balisage de liste en prime peut être lourd ou redondant.
Pour des FIGURE avec peu d'informations (pas de besoin d'utiliser du titrage), j'ai envie de dire que c'est kif-kif: ça passe avec ou sans liste (déjà un peu structuré sans liste, et pas trop lourd avec), et à la rigueur on s'en fout.
cilou a écrit :
Dans la même optique, j'ai des pages réalisations qui affichent des couples "image + légende" mais qui n'ont pas de liens entre eux (sauf qu'ils font partis de la même rubrique, exemple réalisation > édition) et pour moi, là aussi, c'est une liste d'énumération...
J'ai envie de dire pourquoi pas.
cilou a écrit :
je suis tombée sur ce lien : http://dev.w3.org/html5/alt-techniques/#nested
Du grand n'importe quoi: inutile et inefficace.
Inefficace car recommander une structure un peu complexe, en particulier avec des imbrications d'éléments pour surcharger sémantiquement, c'est juste une connerie. L'espoir que ça soit bien fait par les auteurs est faible, de même que l'espoir que ça soit bien interprété ou exploité par les navigateurs et aides techniques.
Inutile car leur exemple marcherait beaucoup mieux avec un HN avec comme texte «The castle through the ages» (pour les dates, elles sont en légende de chaque image, et si on tient vraiment à les avoir au départ on rajoute un paragraphe d'introduction), suivi par les différents FIGURE.
Bonsoir
Concernant le lien, de ce que j'ai pu lire (et comprendre ???) c'est que figure et figcaption n'ayant pas de "poids" sémantiques pour l'instant (et n'ayant pas de role non plus d'attribués), il est difficile de les utiliser comme un couple (image + légende) donc du coup ils rajoutent le role "group" sur figure et des étiquettes (les différentes dates) dans le premier figcaption, chaque date se retrouvant ensuite dans les figcaption suivants pour donner du sens... bon, c'est compliqué !
C'est peut-être plus compréhensif là : http://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/
En tout cas, j'ai appris pleins de choses (notamment là : http://www.temesis.com/html5accessibility/ et la page solutions) sur la compatibilité de l'HTML5 avec les technologies d'assistance.
<HS> dans la page solutions de temesis, ils disent : ajouter le role ARIA role="article" à l'élément nav... c'est une coquille ou ???? </HS>
Concernant le lien, de ce que j'ai pu lire (et comprendre ???) c'est que figure et figcaption n'ayant pas de "poids" sémantiques pour l'instant (et n'ayant pas de role non plus d'attribués), il est difficile de les utiliser comme un couple (image + légende) donc du coup ils rajoutent le role "group" sur figure et des étiquettes (les différentes dates) dans le premier figcaption, chaque date se retrouvant ensuite dans les figcaption suivants pour donner du sens... bon, c'est compliqué !
C'est peut-être plus compréhensif là : http://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/
En tout cas, j'ai appris pleins de choses (notamment là : http://www.temesis.com/html5accessibility/ et la page solutions) sur la compatibilité de l'HTML5 avec les technologies d'assistance.
<HS> dans la page solutions de temesis, ils disent : ajouter le role ARIA role="article" à l'élément nav... c'est une coquille ou ???? </HS>
Pour le cas exposé, je dirais que ça n'a pas beaucoup d'importance. IL faut juste éviter de tomber dans la surstructuration (+1 pour le post humoristique), et penser à passer aux titres, beaucoup plus efficaces dans la navigation avec aide technique, quand les items commencent à devenir importants.
Donc pour une image et un court text, ça ne change pas grand chose d'utiliser une liste ou pas, mais si le court texte se transforme en paragraphe alors je passerais aux titres et abandonnerais les listes.
Un exemple de surstructuration typique, c'est quand on commence à faire des listes avec les titres, les champs de formulaire ou les paragraphes. Certains sites dits accessibles le font, mais en fait ça parasite inutilement la sortie et ralentit donc la navigation.
N'oubliez pas à ce sujet que les instructions CSS pour masquer les types de listes, ne sont pas toujours interprétés dans tous les contextes par les aides techniques. Donc une liste ol avec list-style-type:none risque toujours de faire apparaître des 1, 2, 3 dans le document virtuel lu par l'aide technique. De même que les compteurs, une fonctionnalité qui devrait toujours être interprétée par l'aide technique, ne l'est pas !
Pour l'exemple sur role="group", c'est complètement ridicule. Déjà pour un ce rôle n'est reconnu par aucun navigateur et aucune aide technique donc il est totalement inutile, et de deux même s'il était reconnu ça reste ridicule, parce que ça remplace une fonctionnalité qui existe déjà, qui fonctionne bien et qui n'a pas de raison dêtre remplacée: les titres.
Donc pour une image et un court text, ça ne change pas grand chose d'utiliser une liste ou pas, mais si le court texte se transforme en paragraphe alors je passerais aux titres et abandonnerais les listes.
Un exemple de surstructuration typique, c'est quand on commence à faire des listes avec les titres, les champs de formulaire ou les paragraphes. Certains sites dits accessibles le font, mais en fait ça parasite inutilement la sortie et ralentit donc la navigation.
N'oubliez pas à ce sujet que les instructions CSS pour masquer les types de listes, ne sont pas toujours interprétés dans tous les contextes par les aides techniques. Donc une liste ol avec list-style-type:none risque toujours de faire apparaître des 1, 2, 3 dans le document virtuel lu par l'aide technique. De même que les compteurs, une fonctionnalité qui devrait toujours être interprétée par l'aide technique, ne l'est pas !
Pour l'exemple sur role="group", c'est complètement ridicule. Déjà pour un ce rôle n'est reconnu par aucun navigateur et aucune aide technique donc il est totalement inutile, et de deux même s'il était reconnu ça reste ridicule, parce que ça remplace une fonctionnalité qui existe déjà, qui fonctionne bien et qui n'a pas de raison dêtre remplacée: les titres.
Ben c'est surtout qu'un balisage de liste doit être utilisé ce dont pour quoi il a été conçu, c'est-à-dire pour une liste d'éléments. Comme toujours: pas de balisage abusif, même réflexion que pour les tableaux. Le problème est de savoir ce qu'on considère comme étant une liste et comme étant un élément.
Dans le sens commun qu'on donne à une liste, un élément reste normalement assez court: le nom d'un objet ou d'une personne, un lien, le libellé d'une option parmi plusieurs, ou un court paragraphe décrivant une étape.
En fait l'erreur, c'est que HTML dans toutes ses versions définit l'élément <li> comme un genre d'élément joker acceptant à peu près n'importe quoi à l'intérieur, notamment des paragraphes complets, des tableaux, des champs de formulaire voire des formulaires complets... pour moi c'est un non-sens total. Le seul élément de niveau bloc qui devrait être accepté est une sou-liste du même type.
J'en profite pour casser un mythe qui n'a rien à voir, mais les calendriers dynamiques qui supposent qu'un mois est une liste de jours est un non-sens, tous les calendriers devraient être des tableaux car les jours sont organisés en semaines.
Dans le sens commun qu'on donne à une liste, un élément reste normalement assez court: le nom d'un objet ou d'une personne, un lien, le libellé d'une option parmi plusieurs, ou un court paragraphe décrivant une étape.
En fait l'erreur, c'est que HTML dans toutes ses versions définit l'élément <li> comme un genre d'élément joker acceptant à peu près n'importe quoi à l'intérieur, notamment des paragraphes complets, des tableaux, des champs de formulaire voire des formulaires complets... pour moi c'est un non-sens total. Le seul élément de niveau bloc qui devrait être accepté est une sou-liste du même type.
J'en profite pour casser un mythe qui n'a rien à voir, mais les calendriers dynamiques qui supposent qu'un mois est une liste de jours est un non-sens, tous les calendriers devraient être des tableaux car les jours sont organisés en semaines.