5568 sujets

Sémantique web et HTML

Bonsoir tout le monde,

Ce post est une question que je pose à la suite de la lecture de l'article d'ALA sur la visualisation graphique des données en CSS.

Ma question est donc : peut-on considérer comme sémantiquement correct/acceptable l'usage d'une balise "style=40%" dans le code HTML? Cela l'est sans doute visuellement, l'information est dégradée pour les navigateurs textuels, mais est-ce vraiment purement sémantique (ie. respectueux des recommandations du W3C pour représenter ce type de données)? Qu'en pensez-vous? Doit-on considérer cela comme une "bonne méthode"?

Cordialement, SD.

Texte édité en gras
Modifié par SiDi (20 May 2008 - 17:17)
Il n'y a pas d'élément permettant d'indiquer qu'une quantité est une proportion d'une autre. Il n'est donc pas possible, à mon avis, de trouver un élément ou un attribut "sémantique" qui pourrait permettre de transmettre cette information, et il faut donc bricoler.

Du moment que l'information est présente en texte (ce qui est le cas à chaque fois, en survolant rapidement l'article...), alors l'essentiel est sauf: l'accessibilité à l'information.
SiDi a écrit :
Ma question est donc : peut-on considérer comme sémantique l'usage d'une balise "style=40%" dans le code HTML?
Non.

SiDi a écrit :
mais est-ce vraiment purement sémantique?
Non plus.

a écrit :
Qu'en pensez-vous?
Que tu ne poses pas la bonne question. Et que tu utilises le mot «sémantique» à tort et à travers en parlant de quelque chose qui n'a rien à voir avec la (généraliste) notion de sémantique ou le (plus précis) Web sémantique. Smiley cligne

SiDi a écrit :
Doit-on considérer cela comme une "bonne méthode"?

Ah ben la voilà la bonne question. Smiley smile

La méthode est bonne si elle répond au besoin. Ici le besoin c'est de faire des graphiques simples de type jauge ou graphiques en bâtons, et de faire en sorte qu'ils soient accessibles. La première partie du contrat marche plutôt bien, même si c'est une solution limitée par rapport à l'utilisation d'images:
1. une image est visible même avec styles CSS désactivés, ou avec d'autres styles CSS appliqués (feuille de styles pour l'impression, réutilisation du contenu d'un article pour générer un PDF de l'article à proposer sur le site, contenus syndiqués...);
2. une image peut être récupérée, collée dans un autre document (un traitement de texte par exemple), etc.

Vient ensuite la question de l'accessibilité (les deux points ci-dessus étant plutôt du domaine de la compatibilité). Et là, ça dépend du contenu. Les dispositifs proposés dans cet article de Wilson Miner sur A List Apart, qui sont au nombre de trois (avec à chaque fois une structure HTML et une mise en page différentes), peuvent être accessibles. Cela va vraiment dépendre du contenu. Il me semble que pour toute présentation de données un peu complètes ou complexes, ces dispositifs vont vite être dépassés, et pour des choses comme une présentation de statistiques accessibles on aura intérêt à utiliser quelque chose comme: un ou plusieurs graphiques (IMG alt="descriptif court" longdesc="#descriptif-long"), chaque graphique étant accompagné d'un paragraphe de description (id="descriptif-long") extrayant la ou les informations essentielles du graphique, et suivi d'un ou plusieurs tableaux structurés affichant les données du graphique. On peut éventuellement mettre les tableaux en annexe.
(Là encore, le dispositif exact dépend du contenu... ainsi que des objectifs et des moyens.)

Enfin, on peut critiquer chacun des exemples donnés, en partant du contenu (fictif) utilisé ou de ce qu'on envisage comme utilisation plus concrète de chaque dispositif.

Les exemples sont ici:
http://www.alistapart.com/d/accessibledata/example-final.html
Et le rendu sans styles CSS (ou plutôt avec les styles par défaut du navigateur) est visible ici:
http://www.alistapart.com/d/accessibledata/example-unstyled.html

Premier exemple: liens avec un compteur

Contenu: une série de liens semblable à un menu, où chaque intitulé de lien est accompagné d'une information sur une proportion et une quantité. L'exemple donné n'est pas très parlant, mais on peut imaginer un site qui présenterait ses principales rubriques sous cette forme, en indiquant le nombre d'articles dans chaque rubrique, et la proportion que cela représente par rapport à tous les articles du site.

Critique: c'est une solution plutôt correcte, qui ne pose pas de net problème d'accessibilité. Mais on pourra éventuellement envisager de moins charger le contenu texte, en omettant la proportion par exemple. Attention à la surcharge d'information pour un dispositif de navigation, ainsi qu'aux informations peu explicites (comparer: «Droit 280 (28%)» et «Droit (280 articles, 28% des articles)»...). Une information qui se fait discrète dans le rendu visuel peut éventuellement être omise dans d'autres contextes (quoique ce sera peut-être incompatible avec les méthodes d'implémentation des WCAG 1 telles qu'Accessiweb ou RGAA).

Deuxième exemple: statistiques par date
(Pas trouvé de traduction correcte de timeline dans ce contexte.)

Contenu: une série de quantités pour chaque jour d'un mois (ou chaque mois d'une année, etc.). Le genre de contenu qui se présente typiquement dans un tableau à deux colonnes (date, quantité), ou sur plus de colonnes si on veut présenter plusieurs informations pour chaque date.

Critique: le contenu sans styles est du type «12 (128)», «Fev (128)» ou «2006 (128)». C'est assez vague. On peut préciser avec un contenu du type «12 février: 128 petits pois» ou «Février 2006: 128 petits poits» ou «2006: 128 petits pois». Mais ça risque d'être difficile à caser dans notre dispositif HTML/CSS. Et, dans ce cas, mieux vaut un tableau de deux colonnes pour présenter ces informations. Bref, ça me semble un peu bancal.

Troisième example: ...
(Là je sais pas comment le décrire...)

Contenu: une navigation avec un intitulé principal et, sous la forme d'un graphique miniature pour chaque item de navigation, un aperçu d'informations statistiques. On peut reprendre notre exemple des rubriques d'un site, avec pour chaque nom de rubrique un micro-graphique qui représente la popularité des articles de la rubrique.

Critique: le micro-graphique affiché est discret. L'équivalent textuel donné est envahissant («(60, 220, 140, 80, 110, 90, 180, 140, 120, 160, 175, 225, 175, 125) Apples»), totalement incompréhensible, et parasite l'information principale. C'est une très mauvaise solution, qui plombe l'accessibilité de la navigation en rendant le contenu difficile à déchiffrer. À oublier.


Au final, je retiens:
1. que c'est une technique permettant de mettre en place de petits graphiques facilement et de faciliter leur mise à jour (valeurs tirées directement d'une base de données);
2. que c'est utile quand on a besoin d'un résultat rapide et qu'on n'a pas le temps (ou éventuellement pas les compétences) pour mettre en place un système de génération d'images (type google charts ou autre) ou éventuellement un système d'affichage de graphiques en Flash;
3. que pour certains cas précis, avec des contenus limités et de préférence accessoire (premier exemple), ça peut être sympa;
4. que si on veut présenter des données de manière accessible, on passera son chemin.

Voilà pour moi. Smiley smile


PS: Si ton sujet porte en priorité sur l'accessibilité, fais-moi signe, je déplacerai le sujet dans le salon ad hoc.
Modifié par Florent V. (20 May 2008 - 17:11)
Merci pour la réponse !

Je me posais la question d'une certaine cohérence sémantique (ie. par rapport aux usages recommandés par le W3C) parce qu'il n'existe pas, à ma connaissance, d'attributs ou de balises permettant d'exprimer des quantités ou des proportions.

Au niveau de la cohérence entre l'usage d'une liste et le rendu "graphique", on peut aussi simuler cela en CSS avec un tableau, et éventuellement des <span style="display : none"> pour "filtrer" certains éléments lorsque CSS est activé, obtenant alors un véritable tableau de données en NoCSS ou au print.

Pour ce qui est de mon cas, je veux les utiliser dans un système représentant des notations. Ainsi, une liste de domaines d'évaluation, avec une note attribuée. L'usage de ce genre de visualisation permet, en HTML, et avec peu de ressources serveur, de montrer ces données.

Je pense que le gros avantage sur les images est le cas - si bien sûr le code est propre et compréhensible sans CSS - où l'on veut économiser la bande passante. Ou encore dans un système de statistiques en temps réel, qui devrait souvent régénérer ses images, par ex. des cours de bourse (les ressources du serveur seraient donc précieuses).


Dans ce cas, et compte tenu d'une véritable "lisibilité" en mode texte avec ou sans CSS, peut-on considérer la méthode comme valable?
Sur la sémantique
SiDi a écrit :
Je me posais la question d'une certaine cohérence sémantique (ie. par rapport aux usages recommandés par le W3C) parce qu'il n'existe pas, à ma connaissance, d'attributs ou de balises permettant d'exprimer des quantités ou des proportions.

Ces attributs et balises n'existent effectivement pas en HTML, qui est un langage sémantiquement pauvre. Voilà pourquoi quand on utilise l'adjectif sémantique pour parler d'HTML on dit souvent des bêtises (c'est à dire qu'on parle de sémantique pour des choses qui n'ont pas grand chose à voir).

Je développe rapidement: une liste ul n'est pas un bon moyen de baliser sémantiquement des statistiques de fréquentation pour chaque jour du mois de mars 2008. Une liste ul est un bon moyen pour baliser sémantiquement une... liste non ordonnée. C'est à dire que lorsqu'on utiliser ul, on transmettra le message «ceci est une liste non ordonnée», ce qui est finalement très vague sans être complètement neutre. S'il y a plus à dire pour que les données soient compréhensibles, il faut:
1. éventuellement utiliser un balisage différent s'il existe un balisage ad hoc;
2. rendre les données compréhensibles par leur rédaction et les informations données en contexte.

En résumé, la question «Est-ce que c'est sémantiquement correct?» sera avantageusement remplacé par les deux questions suivantes:
1. est-ce que le balisage transmet une information correcte (ou, le cas échéant, suffisamment neutre)?
2. est-ce que le contenu est compréhensible?

Ces deux questions me semblent un peu plus concrètes. Smiley smile

Sur les graphiques HTML/CSS
SiDi a écrit :
Au niveau de la cohérence entre l'usage d'une liste et le rendu "graphique", on peut aussi simuler cela en CSS avec un tableau, et éventuellement des <span style="display : none"> pour "filtrer" certains éléments lorsque CSS est activé, obtenant alors un véritable tableau de données en NoCSS ou au print.

Mouais... J'ai un doute sur la faisabilité, en dehors de choses très simples. De plus, un graphique n'est pas un tableau et le deux-en-un risque de poser problème dans tel ou tel contexte d'utilisation. Mais je veux bien voir un essai. Pour des choses très simples, ça peut être intéressant.

SiDi a écrit :
Dans ce cas, et compte tenu d'une véritable "lisibilité" en mode texte avec ou sans CSS, peut-on considérer la méthode comme valable?

Comme je le disais, la méthode n'est pas «valable» dans l'absolu. Tout dépend du contenu. Tu évoques un cas précis, mais avec trop peu de détails pour qu'il soit possible de trancher. Je te propose donc de monter un exemple de ce que tu penses faire, et on pourra en discuter. Smiley smile
Rebonjour,

Alors voilà, comme je disais, il s'agit de donner une "note".

Là, c'est pour le portfolio que je dois finir pour l'université. Je dois entre autres définir mes compétences (en auto-notation). Perso, je sors pas du lot dans les domaines "habituels", parce que je me consacre pas mal au Web, qui est complètement et royalement ignoré par les instances universitaires (ce qui fait de moi, humble codeur, l'un des meilleurs de la promo dans le domaine).

Voilà donc la façon dont j'utilise ce mode.

Je dois surtout dresser un listing de langages / softwares connus, et donc la "notation" est une information complémentaire, qui a une importance moins importante que l'énonciation même des langages.

Voilà, je pense que cette manière de faire est logique, même si niveau code c'est pas tip top (même si j'ai pas trop retapé le CSS encore, sachant que le debug IE6, je m'assois dessus à l'heure actuelle).
Ben dans ce cas précis, ça marche bien. Tu fais bien de laisser les span.index vides de contenu.