Re: [html4all] 5 gears in reverse - anne v k enters the alt attributedebate

On Sat, 22 Sep 2007 01:51:15 +0200, John Foliot <foliot@wats.ca> wrote:
> This might be your justification, but it does not address *any*
> accessibility issues - it only makes your life easier.

It's a question of alternatives. If it's a given that the author can't  
provide accurate replacement text, what should be put on the <img>? <img  
alt=""> or simply leave it <img> so user agents can do image analyzing. Or  
maybe there's some better construct? (At some point a product from  
Microsoft was pointed out that does this, but I can't find the reference  
to it.)

Something that's given is that authors will make it inaccessible if  
conformance requires that. If for conformance the alt attribute is  
required authors will simply do <img alt=""> and be done with it, which  
doesn't really seem to help anyone. I made this point a few times, and you  
seem to on ignoring it assuming WYSIWYG editors will solve this. I don't  
really buy that, they haven't for the past 10 years and them suddenly  
making their application harder to use for the average end user is  
unlikely. (Yes, I've heard of one that asks users whether it's a content  
or presentational image and then requires alt= in case of a content image.)

The point you seem to try to make is that this problem, that we've been  
having for over 10 years, will suddenly solve itself by WYSIWYG editors  
and the like requiring replacement text to be provided. I don't really buy  
that. There's also evidence that such content producers will harm end  
users solely to make their pages conforming to HTML. So given that, what's  
the best solution for the end users given those content providers?


> How can a group that wants to dismiss LONGDESC because it is flawed at  
> the same time condone authoring tools that are flawed and seek to write  
> a SPEC to forgive those flaws?

It's not a flaw in authoring tools, they won't solve this problem. Once an  
authoring tool starts to require it I would expect users to simply switch  
to one that doesn't. We're trying to have a realistic specification, that  
doesn't expect authoring tools to solve problems which they haven't done  
in the past 10 years.


> The spec should insist that inline images (as opposed to CSS supplied
> "decorative" images) have alternative text, and preferably something  
> that is user friendly - full stop.  The author group needs to stop  
> trying to
> determine what is user friendly... You can no more decide what works for  
> any given user than you can ascertain what flavor of ice-cream they  
> prefer (or even if they eat ice-cream...)

And you somehow can?


> JF (trying *very* hard to remain rational, on topic, and respectful)

Right, "AND ANNE, THAT RIGHT THERE IS EXACTLY THE WHOLE POINT!", "poor  
workman", etc.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Saturday, 22 September 2007 10:18:45 UTC