W3C home > Mailing lists > Public > www-archive@w3.org > September 2007

Re: [html4all] the alt attribute debate

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 25 Sep 2007 18:06:20 +0300
Message-Id: <1BB2F545-40A7-47CB-8A5A-817DF2D1F7A7@iki.fi>
Cc: "advocate group" <list@html4all.org>, "John Foliot - WATS. ca" <foliot@wats.ca>, "Anne van Kesteren" <annevk@opera.com>, www-archive@w3.org
To: Steven Faulkner <faulkner.steve@gmail.com>

Hi,

On Sep 25, 2007, at 17:33, Steven Faulkner wrote:

> >At least with alt text, unlike with spam, most uncooperative data
> >sources aren't wanting to hurt you. They just aren't going to help
> >you. It doesn't make sense to ask those who won't help you to hurt
> >you if you have the option of asking them to neither help nor hurt.
>
> from my perspective you are beginning to babble here, i am unsure  
> of your point.

The point is that if you say that there *must* be alt text, you are  
going to get alt text: non-bogus (help) and bogus (hurt). You can't  
easily tell which is which, so the bogus text dilutes the value of  
alt text as a whole (hurt). The absence of alt text does not help the  
way non-bogus alt text helps, but at least it doesn't dilute the  
trustworthiness of alt text in general.

> >No, I don't think we have yet come to the conclusion that the absence
> >of data will continue to be worse than bogus data. This should be
> >trivially true: If a consumer prefer bogus data over absent data,
> >bogus data can (by definition) be generated out of thin air. OTOH, if
> >a consumer prefers absent data over bogus data, telling bogus and  
> non-
> >bogus data apart is harder.
>
> lost me here too I am afraid.

You have less noisy information to draw from if you have (mostly) non- 
bogus data and absent data than if you have non-bogus and bogus data  
in one mix.

It is easy to take non-bogus data and absent data and produce a mix  
of non-bogus and bogus data. Every time you get non-bogus data, you  
pass it on as such. Every time you get absent data, you pass on some  
bogus data (e.g. the empty string or a random number).

If you get a mix of non-bogus and bogus data and want to separate the  
two, you need to do more work less reliably.

Therefore, if there's a choice of former and the latter, you should  
want to choose the former.

Only getting non-bogus data is not a real option.


The anomalous part in this case is that notable AT generates bogus  
data in a way that is easily worse than the bogus data a server-side  
programmer might dare to generate. It doesn't make sense that this  
should be the permanent state of affairs.

> >AT UAs need to deal with those cases, too, though. The question is,
> >really, whether explicit flagging as "critical" has enough value
> >compared to falling in the same bucket with lack of alt for unknown
> >reason.
>
> It is the spec that is making this distinction of certain images  
> without alt attributes being "critical content" it makes the  
> assumption that these can somehow be differentiated from all other  
> altless images, this distinction is reliant upon authors following  
> the other recommendations in the spec about how to mark up images,  
> without them doing this (which as we know is the likely case), then  
> these magical critical content images will become just more  
> meaningless noise for the AT UA to filter out as they curently do  
> (most of the time).

Yeah, that aspect of the spec is questionable *if* there is value in  
explicitly flagging "critical" images. Is there?

> Your arguments also appears to rest on the assumption that  
> automated software that outputs images to html is providing the alt  
> text because the current spec says so, i find this rather hard to  
> believe as they don't appear to be bothered about many other  
> aspects of the spec.

Can you speculate why it is done if not for the requirement to have  
an alt attribute with *some* value?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 25 September 2007 15:06:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:14 UTC