- From: Matthew Paul Thomas <mpt@myrealbox.com>
- Date: Sun, 22 Jan 2006 13:03:43 +1300
On 22 Jan, 2006, at 3:20 AM, Jonny Axelsson wrote: > > On Sat, 21 Jan 2006 13:54:34 +0100, James Graham <jg307 at cam.ac.uk> > wrote: > ... >> People seem to have passed this point by. the current specification >> of alt as required makes it almost impossible to design a conforming >> HTML editor that doesn't mess up the semantics of the attribute. >> Since many (the majority?) of HTML pages are produced using some form >> of graphical editor (often implemented using contentEditable or some >> other HTML+js solution as part of a CMS), the spec should at least >> consider the needs of editors as well as UAs. I don't think that can achieve anything -- ceteris paribus, a graphical editor's ease of use will be inversely proportional to how well it encourages accessible and semantic use of images, no matter how they're represented in markup. At one end of the scale, you have software where an image is inserted by dragging and dropping, and there is no interface for alt= text at all (such as most graphical mail clients). At the other end, you have a two-paned editor where the top pane shows the normal WYSIroughlyWIG presentation, and the bottom shows the page with no CSS and with editable inline alt text instead of images (nice for a dedicated Web author, but utterly unreasonable for rich-text e-mail or Web applications). In the middle, you have an 'Alt text" field buried in a dialog somewhere, with long-running disputes over how insistent it should be (as in Mozilla Composer). For those using text editors, however, there is a way of encouraging suitable fallback content: encourage use of <object> and discourage use of <img>. It is much more obvious that <object></object> should perhaps have something inside it than that <img src="foo"> is missing an alt= attribute. And for those few who read the spec, you can define <img> tongue-in-cheek as "a piece of text with an alternate graphical representation", as Ian has already done; and provide guidance on the use of alt=, as I did at the start of this thread. > ... > The danger with making an aspect of a markup language mandatory, like > the mandatory 'alt' attribute for 'img' and the mandatory 'title' > element in 'head' is that the editor/author will need to use filler > content that may reduce the quality of the attribute/element in > question. With 'alt' this has the consequence 'alt=""' means either > that this image has no alternate representation (and presumably > semantic content) or that it has been automatically been filled in to > make the document validate. It is fairly acceptable, but it would have > been better that no 'alt' attribute at all had been used in the latter > case. The guess the W3C seem to have made is that the benefit from people who add alt= appropriately solely because it's a validity requirement is greater than the harm from people who add alt= inappropriately solely because it's a validity requirement. This may well be true, though a usability test of this would be fascinating. People who care about validity in the first place are more likely to care about appropriate alt= text (though they still often do a terrible job at it). However, people using graphical authoring tools are *not* likely to care about appropriate alt= text, so it is better for the Web if such tools omit alt= than if they force it to some default value to generate valid documents and avoid persecution by the Web Standards Project. Bizarre but serious conclusion: alt= should be optional for <img> in documents where a <meta name="generator"...> element is present. -- Matthew Paul Thomas http://mpt.net.nz/
Received on Saturday, 21 January 2006 16:03:43 UTC