The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Author Archive

La loterie du longdesc

Tuesday, September 18th, 2007

This is a French translation of this article : The longdesc lottery

Parlons maintenant de l'attribut longdesc. En HTML 4, il est défini comme un pointeur vers une longue description, pour une image complexe. Tout le monde peut apprendre à écrire une longue description pertinente. Il n'y a qu'un seul problème : dans les faits, personne ne s'en soucie, et celui qui s'en soucie se trompe.

Maintenant, quantifions le phénomène. En Août 2007, Ian Hickson a analysé un échantillon d'un milliard d'éléments <img> dans l'index de Google. Approximativement 1,3 millions (soit 0,13 %) avaient efectivement un attribut longdesc. Eh bien direz-vous, c'est normal : toutes les images n'ont pas besoin d'un tel attribut. Et vous auriez raison. Mais sans se soucier de savoir s'il est nécessaire ou pas, longdesc n'est pas utilisé si souvent : un seul pour une centaine d'image.

Maintenant, voyons dans combien de cas l'attribut longdesc est utilisé judicieusement. Bien sûr, ce critère est plus subjectif, mais on peut tout de même relever les erreurs les plus évidentes. Des 1,3 millions d'images qui avaient un attribut longdesc, ôtons celles ou l'attribut longdesc ...

Cela élimine purement et simplement 1,25 million (environ 96%) d'images du lot. Ce n'est pas 96% de toutes les images présentes sur le web - c'est 96% des 0.13% des images qui incluaient un attribut longdesc en première instance. Et lorsqu'on regarde plus attentivement aux 50 000 images restantes, (soit 4% de 1,3 million) les résultats empirent encore : des liens vers d'autres images, des liens brisés, des liens vers une description d'une ligne identiques à l'attribut alt, et des liens vers une page qui vous indique les dimensions de l'image, mais pas son contenu (Wikipedia, c'est bien de toi dont je parle). Si on extrapole à 1,3 million d'image, les 50 000 se réduisent à 10 000. Cela signifie que moins de 1% des images qui fournissent un attribut longdesc sont réellement utiles. Pas plus d'une image sur 100 est correcte (sur les 1% qui se donnent la peine d'essayer).

Parallèlement, les même personnes qui souhaitaient conserver l'attribut longdesc ont récemment réalisé quelques expériences de test par les utilisateurs. C'est-à-dire qu'ils ont testé avec quelle précision une vraie personne aveugle avec un vrai lecteur d'écran pouvait lire une vraie page web. Il s'est avéré que le sujet ne connaissait pas l'existence de l'attribut longdesc avant que le testeur n'en fasse mention. Peut-on vraiment lui en vouloir ? 99.87% des images qu'il avait rencontré n'avaient même pas d'attribut longdesc. Même s'il en avait eu connaissance, et qu'il en avait rencontré une par hasard, il restait tout même 99% de chances que les informations fournies ne présentent aucun intérêt. Il a ainsi plus de chance de gagner à la loterie.

Je ne dis pas qu'il n'y a pas là un réel problème qu'il faudrait résoudre. Il y en a bel et bien un. Les gens peuvent publier des images complexes qui nécessitent des alternatives textuelles tout aussi complexes. Les diagrammes, graphiques et autres photos très détaillées. Mais peu importe. « une image vaut mieux qu'un long discours » et tout ça ... L'attribut longdesc est, théoriquement, une solution à ce problème. Mais cela ne veut pas dire pour autant qu'il s'agisse d'une bonne solution et encore moins de la seule solution. Cela fait 10 ans maintenant que nous vivons avec longdesc et je peux vous l'assurer : cela ne fonctionne pas. Ainsi, pourrions nous éviter la levée de boucliers et commencer à parler d'une meilleure solution ?

Posted in Elements | Comments Off on La loterie du longdesc

Pourquoi le texte alternatif peut être omis (French)

Thursday, August 23rd, 2007

This article is a French translation of the article Why the Alt Attribute May Be Omitted.

La spécification de l'attribut alt a été retravaillée récemment, afin d'améliorer sa définition, en incluant une explication en profondeur de comment fournir le texte alternatif le plus approprié avec de réelles exigences éditoriales.

La spécification décrit des situations où le texte alternatif doit être précisé, où un attribut alt vide doit être utilisé et où, de façon plus sujette à controverse, l'attribut alt peut parfaitement être omis. Cette omission peut sembler être sujette à controverse, parce que au premier regard, cela ressemble à une tentative pour justifier la mauvaise pratique, contraire aux principes de l'accessibilité, qui consiste à oublier l'attribut alt ... Et à jeter un pavé dans la mare. C'est une confusion malheureuse qui nécessite qu'on s'y arrête un instant pour balayer les doutes qu'elle pourrait susciter chez bien des gens. Bien que cela puisse paraître rétrograde, la situation est ainsi bien meilleure.

Il y a bien des cas où le texte alternatif est tout simplement indisponible et où il y a peu de choses que l'on puisse faire pour remédier à la situation. Par exemple, la plupart des utilisateurs de sites de partage de photos comme Flickr n'auraient certainement aucune idée de quoi écrire comme texte alternatif, même si Flickr leur en offrait la possibilité. Et même si, bien sûr, tout le monde s'accorde à dire que si ce serait formidable si, comme la spécification l'encourage, tous les utilisateurs le faisaient, la plupart ne le feront tout simplement pas.

Le problème que nous venons de soulever est le suivant : que devons-nous faire dans le cas où aucun texte alternatif n'a été spécifié et où il reste virtuellement impossible à définir ? De nombreux systèmes actuels tentent de satisfaire la recommandation actuelle en matière de texte alternatif en générant ce texte à partir des métadonnées des images.

Flickr, par exemple, répète le titre de l'image ; Photobucket semble combiner le nom du fichier image, le titre et le nom de l'utilisateur - et Wikipédia reproduit de façon redondante la légende de l'image. Le problème de ces approches est qu'aucune d'entre elles ne fournit une information additionnelle utile à propos de l'image et, dans certains cas, cela est pire que de ne fournir aucun texte alternatif.

Le bénéfice que l'on peut retirer de permettre l'omission du texte alternatif, plutôt que de nécessiter une valeur vide est que cela permet de créer une distinction claire entre une image qui n'a pas de texte alternatif (comme une icône où une représentation graphique du texte environnant) et une image qui fait partie intégrante du contenu, mais pour laquelle aucun texte alternatif n'est disponible. Il a été dit que Lynx et Opera faisaient déjà cette distinction. Pour des images qui n'ont pas d'attribut alt, Lynx montre le nom du fichier et Opera le texte "Image", mais aucun des deux ne montre quoi que ce soit pour les images dont l'attribut est laissé vide. Il reste à déterminer si cette disctinction est effectivement utile dans l'affichage du contenu du "monde réel" et il y a réellement un débat à mener si vous avez des preuves à avancer.

On a suggéré que retirer la présence inconditionnelle de l'attribut alt affecterait la capacité des validateurs à montrer leurs erreurs aux utilisateurs et retirerait un bon outil de promotion de l'accessibilité. Cependant, utiliser les erreurs de validation comme un outil d'évangélisation de l'accessibilité n'est certainement une bonne façon d'envisager cette problématique.

Tandis qu'il est en effet très utile pour les auteurs de savoir quand ils ont oublié par erreur un attribut alt en cherchant à les obliger à l'utiliser de façon inconditionnelle, utiliser un outil aussi éculé qu'un validateur est contre-productif, car il encourage l'utilisation de textes générés automatiquement de pauvre qualité. Paralèllement, rien n'empêchera les outils de validation et d'édition web de signaler ces erreurs aux auteurs si tel est leur bon plaisir.

Aucun des bénéfices de l'accessibilité n'est perdu en acceptant le fait qu'il est impossible de forcer tout le monde à fournir un texte alternatif et en rendant l'attribut alt optionnel pour pouvoir s'assurer de la conformité d'un document. Personne ne proclame que la conformité au HTML 5 est équivalente à la conformité avec les recommandations d'accessibilité. Il y a de nombreuses choses qui sont considérés conformes techniquement en HTML, mais qui demeurent "inaccessibles" si elles sont mal utilisées. Rendre l'attribut alt techniquement optionnel ne se dresse pas contre les recommandations d'accessibilité, pas plus qu'il n'a un quelconque impact sur l'évangélisation de l'accessibilité. Il s'agit simplement d'accepter la réalité de la situation à laquelle nous faisons face, dans l'espoir de réduire la prolifération des textes alternatifs de mauvaise qualité générés automatiquement.

Posted in Browsers, Elements, Processing Model, WHATWG | 2 Comments »

Présentation: comment HTML 5 peut-il être utilisé aujourd’hui ? (French)

Monday, August 20th, 2007

This is a French translation of the article: Presentation: How HTML5 can be used today.

Hier, j'ai fait une présentation pour Creuna puis au Geek Meet sur la façon dont HTML 5 peut être utilisé aujourd'hui. La présentation était faite en Suédois, et c'est pourquoi les diapos sont disponibles en Suédois.

L'audience était essentiellement composée de personnes dont le métier est de créer des sites web.

La discussion qui a suivie était intéressante, mais elle n'a pas été enregistrée et je ne peux pas me souvenir de toutes les questions qui ont été posées, malheureusement. En voilà toutefois quelques unes qui me reviennent en mémoire :

Quand est-ce que HTML 5 sera effectivement utilisé par les développeurs web ?
Ca dépend de vous.
Quand est-ce que HTML 5 sera terminé ? Quels sont les délais prévus ?
Le tout est de savoir à quelle vitesse les différents navigateurs l'implémenteront. Le groupe de travail du W3C pour HTML 5 indique qu'une recommandation pour ce langage sera disponible pour 2010, mais je ne pense pas qu'il soit réaliste de penser qu'à cette date les navigateurs l'auront implémenté totalement et correctement. Un délai de 15 ans me semble plus réaliste, mais cela ne veut pas dire pour autant que vous avez besoin d'attendre 15 ans pour utiliser HTML 5.
Quel est l'intérêt d'utiliser Web Forms 2.0 plutôt que d'utiliser les formulaires HTML 4 et du Javascript ?
Moins de travail pour les développeurs et un meilleur rendu pour les utilisateurs. Par exemple, utiliser un <input type=email> signifie pour le développeur qu'il n'a pas à écrire du Javascript côté client pour valider qu'il s'agit d'une adresse email et pour l'utilisateur qu'il peut choisir un mail dans son carnet d'adresse personnel (quelque chose qu'il est impossible d'implémenter en Javascript).
Sera-t-il possible de style les nouveaux contrôles de formulaire avec du CSS ?
Il sera sans doute possible de le faire de la même façon qu'il est actuellement possible de le faire. L'icône dans le contrôle email est ajoutée par Opera quand le contrôle de formulaire est stylé d'une façon ou d'une autre (je style en général le fond en blanc pour la faire apparaître).
Peut-on styler ou modifier les messages d'erreur du formulaire ?
Je ne suis pas sûr que vous puissiez les styler, mais vous pouvez cependant en changer le texte avec Javascript ou réécrire le mécanisme qui signale l'erreur et créer le votre avec Javascript.
Est-il vrai que HTML 5 permettra l'utilisation de <font> ?
Non, les développeurs ne pourront pas utiliser <font>. Cependant, les éditeurs WYSIWYG seront autorisés à émettre des balises <font>. Ils devront s'identifier avec une balise <meta>. Cette problématique a reçu beaucoup de feedback et pourrait être modifiée.
Avez-vous besoin d'être compatible en ce qui concerne l'utilisation de /> ou > ?
Non
Si vous ne spécifiez pas quelle est la version d'un document HTML, comment pourrez-vous redéfinir le comportement d'un élément, plus tard, dans HTML 6 ?
Il n'y a pas besoin de préciser la version : les navigateurs traitent tous les documents HTML de la même façon, sans prêter attention à la version à laquelle ils déclarent appartenir. Un bon exemple de cela est la balise <plaintext>, qui a été dépréciée depuis la première version de HTML et qui est encore supportée dans tous les navigateurs, même si vous spécifiez une version HTML 4 par le DOCTYPE.
Est-ce que HTML 5 déprécie quelque chose ?
Rien n'est déprécié en fait, mais certaines choses sont totalement interdites. Par exemple, l'élément <u> n'est pas autorisé dans des documents HTML 5 conformes. Mais les navigateurs continueront cependant à le supporter.
Est-ce que html5lib peut parser n'importe quelle soupe de tags ?
Oui.
Est-ce que cela signifie que l'on peut convertir n'importe quel vieux document HTML en XML en la passant à la moulinette de html5lib ?
Oui.
Est-ce qu'on peut utiliser le tag <svg> dans HTML 5 ?
Non, vous ne pouvez pas utiliser les espaces de nom (namespaces) en HTML 5. Vous pouvez cependant inclure du SVG dans XHTML5 puisqu'il s'agit simplement de XML.

Posted in WHATWG | 1 Comment »

HTML contre XHTML (French)

Wednesday, August 15th, 2007

This is a French translation of HTML vs. XHTML.

L'un des problèmes prédominants soulevés dans un récent appel à commentaires était de parvenir à dépasser le débat HTML contre XHTML, car beaucoup de gens estimaient que nous devions chercher non pas à étendre HTML, mais à nous concentrer sur XHTML seulement.

Cependant, la chose que de nombreuses personnes n'ont pas saisi est que HTML 5 résoud ce problème : la spécification (X)HTML 5 se propose en fait d'étendre simultanément HTML et XHTML, et de ne pas faire dépendre ce choix sur le DOCTYPE.

De nombreux webmasters utilisent un DOCTYPE XHTML 1.0 et s'empressent ensuite d'annoncer qu'ils utilisent XHTML - mais les ce sont les navigateurs eux-mêmes qui font le choix ou non de traiter un document comme du HTML ou du XHTML en se basant sur ... le type MIME. (X)HTML 5 se propose de résoudre ce souci en se reposant exclusivement sur le type MIME - ainsi, si un document est servi comme text/html, il sera parsé comme du HTML ; mais s'il est servi avec un type MIME de type XML, comme application/xml ou application/xhtml+xml, il sera parsé comme du XHTML.

Sérialisation de document

HTML 5 introduit le concept de sérialisation pour un document HTML. Une sérialisation dans ce contexte fait référence à une représentation physique de l'essence même du document : son arborescence. (X)HTML 5 attend des agents utilisateurs qui supportent l'ajout de script qu'ils présentent l'arborescence du document en utilisant l'API DOM et le modèle de données. HTML 5 utilise la sérialisation HTML et XHTML 5 utilise la sérialisation XML. Grâce à cela, la distinction entre HTML et XHTML est réduite.

Dans la plupart des cas, chacun des deux types de sérialisation peut être employé pour représenter exactement le même document. Les différences principales sont que la sérialisation HTML, pour des raisons de compatibilité descendante, ne peut représenter de façon structurée des éléments de niveau "in-line" (alignés les uns à côté des autres, non-blocs) comme étant des enfants des enfants de l'élément <p> et que la sérialisation XML ne peut pas représenter la totalité des arborescences qui pourraient être le résultat d'un document généré à la suite d'une récupération d'erreur de l'algorithme du parseur HTML. De même, dans certains navigateurs, quelques fonctionalités particulières de l'API de scripting et quelques détails dans l'interprétation des styles CSS fonctionnent différemment suivant la sérialisation du document pour des raisons de compatibilité descendante.

La sérialisation XML utilisée par XHTML implique que le document soit bien formé (well-formed) au format XML 1.0. Cependant, contrairement au précédentes versions de HTML, la sérialisation n'est plus considérée comme une application de SGML mais définit à la place sa propre syntaxe. Cette dernière est inspirée par SGML, mais elle est définie d'une manière qui se rapproche plus de la façon dont les navigateurs gèrent HTML dans le monde réel - surtout en ce qui concerne la gestion des erreurs.

La sérialisation d'HTML 5 et les algorithmes de parsing qui l'accompagnent sont rendus nécessaire pour 3 raisons :

  1. Le navigateur qui a pour l'instant la plus forte part de marché ne supporte pas XHTML (du moins celui qui est effectivement servi et traité comme tel).
  2. L'ancien contenu text/html toujours présent sur le web a besoin d'un algorithme de traitement clairement défini - quelque chose que les spécifications HTML basées sur SGML n'ont pas été en mesure de fournir.
  3. Il existe des gestionnaires de contenu (CMS), des applications web et autres workflows qui ne sont pas basés sur des outils XML et sur qui on ne peut compter pour reproduire une sortie bien formée. Ces systèmes peuvent bénéficier des nouvelles fonctionnalités même s'ils ne fonctionnent nécessairement correctement avec la sérialisation XHTML.

D'un autre côté, grâce à la dualité HTML/XHTML, les nouveaux systèmes peuvent être directement conçus pour fonctionner avec des outils XML interne et convertir ensuite vers HTML 5 et à partir de HTML 5 lors des échanges de type entrée/sortie. Une fois que la base des navigateurs installés supportera correctement le type MIME application/xhtml+xml, ces systèmes pourront échanger le sérialiseur de sortie et utiliser des fonctionnalités autorisées seulement par XHTML telles que les listes placées dans des paragraphes.

Le nouveau DOCTYPE

Dans la pratique, le DOCTYPE sert à deux choses : la validation basée sur la DTD et (pour HTML seulement) la détection (sniffing) de DOCTYPE. Puisque HTML n'est plus considéré comme une application de SGML et qu'il y a de nombreuses limitations dans la validation basée sur les DTD, il n'y aura aucune DTD officielle pour (X)HTML 5.

Ainsi, lors de la sérialisation HTML, la seule raison pour laquelle on place un DOCTYPE est d'activer le mode "standard" dans les navigateurs. Du coup, puisqu'elle n'a plus besoin de faire référence à une DTD, la déclaration de type de document se trouve réduite à ceci : 

<!DOCTYPE html>

Vous conviendrez avec moi que cette syntaxe est aussi simple qu'elle est facile à retenir. Mais pour XHTML, c'est encore plus simple : il n'y en a pas besoin ! Puisque les navigateur n'ont pas introduit et n'introduiront pas de détection de DOCTYPE pour le XML, il n'y a pas réellement besoin d'un DOCTYPE.

Cependant, il me faut admettre que l'absence de DTD dans XML présente encore un problème technique mineur : les références aux entités qui sont déclarées dans la DTD XHTML 1.0 ne pourront plus être utilisées. Toutefois, puisque les browsers n'utilisent pas de parseurs de validation et ne lisent pas les DTD depuis le réseau de toutes façons, l'utilisation d'entités n'est [de toutes façons] pas recommandée. Il est préférable d'utiliser les références des caractères ou un bon encodage (comme l'utf8) qui supporte nativement les caractères.

Vérification de la conformité

Vous devez sûrement vous demander comment il sera possible de valider la conformité d'un document sans DTD. Eh bien, cela est tout simple : il existe en fait d'autres méthodes, plus robustes, qui sont disponibles pour s'assurer de la bonne formation d'un document. Plusieurs langages de schéma, dont RELAX NG et Schematron pourraient être utilisés. Cependant, même eux ne pourraient exprimer totalement les besoins de (X)HTML 5 en termes d'éléments de conformité qu'il est possible de vérifier avec une machine.

Henri Sivonen est en train de développer un vérificateur de conformité pour HTML 5 qui est conçu pour donner des messages d'erreur qui vont au-delà de ceux qu'il est possible de fournir en utilisant une approche basée sur les DTD. Par exemple, la vérification de l'intégrité d'un tableau est une fonctionnalité qu'il est impossible d'implémenter en utilisant simplement une approche basée sur les DTD.

(more…)

Posted in Conformance Checking, Syntax | 1 Comment »