W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: Investigating the proposed alt attribute recommendations in HTML 5

From: Leif Halvard Silli <lhs@malform.no>
Date: Mon, 03 Sep 2007 03:50:28 +0200
Message-ID: <291a129dd036e377b70917c423ee78d2@10013.local>
To: public-html@w3.org

2007-09-01 18:20:32 +0200 Sander Tekelenburg <st@isoc.nl>:
> At 04:09 +0200 UTC, on 2007-09-01, Leif Halvard Silli wrote:
>> 2007-08-31 21:23:11 +0200 "Jon Barnett" <jonbarnett@gmail.com>:

> [...]
>> I spoke up against the argument that poor alt is worse than anything else.
>>> or a "descriptive" @alt
>> I especially feel the 'descriptive' argument thin. Simply because an
>> «alternative text is a replacement», it must often be descriptive.
> Could you provide an example? Because I disagree, but in general I tend to
> agree with you -- so I might be misunderstanding what you mean.

Let's  say I meant it the way you interpreted what I said about «independent text» for photoalbums pictures, below. ;-) Anyway - and relating this to the other e-mail, were we discussed the (possible) lack of connection/relationship between @TITLE and @ALT, I feel that when we say that the @ALT text should be descriptive, then we are linking the issue to @TITLE, thinking, «oh, no, descriptions should be in @TITLE» - and then we have made a (false) connection between TITLE and ALT anyhow. We should look at the requirements of the @ALT at bit more independently. 

However, perhaps you should explain how we possibly are disagreement? :-) I am not sure how/why the @ALT should not be descriptive … But, of course in an article about a certian subject, if there is an image of the US Whitehouse, then to go on describing how it looks like ... would normally not be the thing, unless, it e.g. deals with the architecture of the Whitehouse … Is it a (real) problem that authors think they have to describe things in order to bring a textual equivalent of the image? 

> [...]
>>>   I suggested omitting @alt and using @title instead
>>> because it gives accessible text without changing the semantics of
>>> @alt (from "alternative text" to "descriptive text")
>> Alternative text is equivalent content. You can even write the @ALT text
>> first and find the image thenafter.
> Indeed. (In fact, I suspect that how it works in most cases. Even though most
> authors may not be aware, nor take that step explitly.)
>> [...] One should not simply look at the image and try to describe it,
>> without fitting the description/the alt text into the flow of the rest of
>> the text. But when we have a photo album, then we should indeed try to make
>> the descripions a bit independent - as there is no story to tell per se.
> Ah, maybe I'm beginning to understand what you mean with "description".
> Actually, my feeling is that for photo albums, where 'the image is the
> content', it may often well be appropriate to not provide @alt, and provide a
> detailed description through @longdesc.

That might be a good idea.

> Note though that I think <img>, @alt, and @longdesc should be flushed, in

dropped from HTML5?

> favour of <object id=> (or <picture>) with <alt for=idref>. That would make
> this entire point moot.

I guess I generally support this.

But then, currently, @ALT is a required part of IMG. Would <alt for=idref> then be a required element if one use <OBJECT id=> or how? Currently OBJECT have equal content/fallback content just inside the OBJECT element itself. So perhaps you are thinking about a solution where one either used the fallback conent from inside the OBJECT or else, then <alt for=idref> would be required?

Also, I wonders about the issues that Simon Pieters took up in the thread «Re: What <object> represents in different views (detailed review of Semantics)»

> [...]
>> How would you, if you designed an author tool, present to authors the
>> choice between noALT and ALT=""?
> Possibly assume noalt by default, and allow the author to either define the
> image as meaningless/decorative, or to provide a textual equivalent. Bug the
> author at least *once* before publication, listing all instances of noalt
> (explaining why), and always allow the author to generate such a report later.

Oh, that would be many "buggings" - if you publish many times. So, if <IMG noALT>, then IMG are in «neutral» state? (Which is why the author must be bugged, over and over ...) There is actually nothing that prevents UAs from implementing this today ...

Do you link this to the 'key content' debate at all? Who are we benefiting this way?
Do you actually think this is possible - even from an equal content point of view? (I generally agree with you - but now I am in doubt ;-)  The problem for me is what noALT should say. Is it the «highest level» - the «irreplaceble» key conten image kind of thing? (Let me guess: your thinking could be that the IMG has been «replaced» outside the IMG element - and therefore needs no @ALT - but isn't purely decorative either - and hence isn't - as such - an ALT=""? But that would not be irreplacable «key content» then ...? )

If we consider current UA behaviour, then the only thing we know is that an noALT image is _not_ considered "ignorable". When the SRC URI is wrong, most UAs still make the user aware of the presence of images even when they do lack the ALT attribute entirely: JAWS [for JAWS, a SRC is always «wrong»], iCab, Opera, Safari and Internet Explorer. The only one which doesn't is Firefox (released version).  (Perhaps I don't understand what Lachlan says in the WHATwg blog [1], but he seems to say that Opera and Lynx are unique in how they discern between images with noALT and with ALT="" - but that is not true, then.)

[ ... ]
> […] No reason to actively bug the user for an @title value.

Agree. That was a speculating paragraph of mine ...

[1] «… Lynx and Opera already …» <http://blog.whatwg.org/omit-alt>
leif halvard silli
Received on Monday, 3 September 2007 01:50:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:26 UTC