The WHATWG Blog

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

Archive for the ‘Elements’ Category

Major content model changes in HTML5 (and Validator.nu)

Sunday, January 13th, 2008

The HTML5 content models became more lax in December in response to feedback from various people who found the stricter content model—especially the bimorphic content model of div—unhelpful. The notions “strictly inline content”, “structured inline content”, “block content” and “block or inline content but not both” (aka. bimorphic) are now gone.

The elements formerly known as inline are now phrasing elements in order to make a distinction with the display: inline; CSS property. Content models that previously accepted only block content or either block or inline but not both now accept both. Phrasing content and content formerly known as block content are now prose content when taken together. The practical effect is that the conformance requirements became closer to HTML 4.01 Transitional than Strict; the former requirement for strictness turned out to be hard to justify in face of actual authoring patterns and browser support for those authoring patterns.

The content model changes are now also reflected in Validator.nu. There are some known differences from the spec, though:

Posted in Conformance Checking, Elements, Syntax | No Comments »

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

The longdesc lottery

Friday, September 14th, 2007

Let's talk about the longdesc attribute. In HTML 4, it's defined as a pointer to a long description for a complex image. Anyone can learn how to write a good long description. There's only one problem: virtually no one bothers, and virtually everyone who does bother gets it wrong.

Let's quantify that. In August 2007, Ian Hickson analyzed a sample of 1 billion <img> elements in Google's index. Approximately 1.3 million (0.13%) had a longdesc attribute. That's OK, you say, not every image needs a longdesc attribute. And you would be right. But regardless of whether it's needed or not, it's not being used that often: just over one in a thousand images.

Now let's look at how often the longdesc attribute is actually used correctly. Of course this is a more subjective question, but we can spot some obvious errors. Out of those 1.3 million images with a longdesc attribute, let's subtract the ones where the longdesc attribute...

That knocks out a whopping 1.25 million (about 96%) right off the bat. That's not 96% of all the images on the web; that's 96% of the 0.13% of images that included a longdesc attribute in the first place. And when you take a closer look at the remaining 50,000 (4% of 1.3 million), the results get even worse: links to other images, links gone 404, links to one-line text descriptions identical to the alt attribute, and links to pages that describe the image size but not its contents (Wikipedia, I'm looking at you). Extrapolating back to 1.3 million, that 50,000 shrinks to about 10,000. That means that less than 1% of images that provide a longdesc attribute are actually useful. No more than one in a hundred get it right, of one in a thousand that even try.

Meanwhile, the very people advocating for keeping the longdesc attribute have recently conducted some user testing. That is, testing how well an actual blind person with an actual screen reader can read actual web pages. It turned out that the test subject didn't know that longdesc even existed before the tester told him about it. Can you blame him? 99.87% of the images he'd ever encountered had no longdesc attribute at all. Even if he had known about it, and he had actually stumbled across one, he would still be up against 99 to 1 odds that following it would be worth his time. He has a better chance of winning the lottery.

I'm not saying there isn't a real problem to be solved here. There is. People can publish complex images that require complex text alternatives. Charts, graphs, detailed photographs. Whatever. "A picture is worth 1000 words," and all that. The longdesc attribute is, theoretically, a solution to this problem. But that doesn't mean it's a good solution, and it's certainly not the only solution. We've been living with longdesc for 10 years now, and let me tell you, it's not working out. So can we please get past the grandstanding and start talking about a better solution?

Posted in Elements | 40 Comments »

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 »

Why the Alt Attribute May Be Omitted

Thursday, August 23rd, 2007

The specification of the alt attribute was recently worked on to thoroughly improve its definition, including an in depth explanation of how to provide appropriate alternate text, with clear authoring requirements.

The requirements describe situations where alternate text must be provided, where an empty alt attribute must be used and, most controversially, where the alt attribute may be omitted entirely. This is controversial because at first glance, it seems like an attempt to endorse the bad and inaccessible practice of omitting the alt attribute, and thus yet another slap in the face for accessibility. That is an unfortunate misconception that needs to be carefully examined to settle any concerns people have. Although it may seem backwards, the situation is actually much more positive.

There are many observed cases where alternate text is simply unavailable and there’s little that can be done about it. For example, most users of photo sharing sites like Flickr wouldn’t have a clue how or why to provide alternate text, even if Flickr provided the ability. While everyone agrees that it would be wonderful if all users did – indeed, the spec strongly encourages that – most users simply won’t.

The problem being addressed is what should be done in those cases where no alt text has been provided and is virtually impossible to acquire. With the current requirement for including the alt attribute in HTML4, it has been observed that many systems will attempt to fulfil the requirement by generating alternate text from the images metadata.

Flickr, for example, repeats the images title; Photobucket appears to combine the image’s filename, title and the author’s username; and Wikipedia redundantly repeats the image caption. The problem with these approaches is that using such values does not provide any additional or useful information about the image and, in some cases, this is worse than providing no alternate text at all.

The benefit of requiring the alt attribute to be omitted, rather than simply requiring the empty value, is that it makes a clear distinction between an image that has no alternate text (such as an iconic or graphical representation of the surrounding text) and an image that is a critical part of the content, but for which not alt text is available. It has been claimed that Lynx and Opera already use this distinction. For images without alt attributes Lynx shows the filename and Opera displays "Image", but neither show anything for images with empty alt attributes. It is still somewhat questionable whether this distinction is actually useful and whether or not browsers can realistically make such a distinction with real world content, and that is certainly open to debate if you have further evidence to provide.

It has been suggested that taking away the unconditional requirement for the alt attribute will affect the ability of validators to notify authors of their mistakes and take away a useful tool for promoting accessibility. However, using validation errors as an accessibility evangelism tool is not necessarily the only, nor the best, way to address the issue.

While it is indeed very useful for authors to know when they have mistakenly omitted an alt attribute, attempting to unconditionally enforce their use, using a tool as blunt as a validator, is counter productive since it encourages the use of poor quality, automatically generated text. Besides, nothing will prevent conformance checkers and authoring tools from notifying authors, if they so desire.

No practical accessibility benefits are lost by conceding the fact that you cannot force everyone to provide alternate text and making the alt attribute optional for the purpose of document conformance. No-one is claiming that conformance to HTML5 equates to conformance with accessibility requirements. There are lots of things that are considered technically conforming in HTML, yet still inaccessible if used poorly. Making alt technically optional doesn't stand in the way of accessibility requirements, nor greatly impact upon accessibility evangelism. It just acknowledges the reality of the situation in the hope of reducing the prevalence of poor quality, automatically generated alt text.

Posted in Browsers, Elements, Processing Model | 46 Comments »