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

Re: Investigating the proposed alt attribute recommendations in HTML 5

From: Sander Tekelenburg <st@isoc.nl>
Date: Tue, 4 Sep 2007 20:22:04 +0200
Message-Id: <p0624067ec30349d981a0@[192.168.0.101]>
To: public-html@w3.org

At 13:30 +0200 UTC, on 2007-09-04, Leif Halvard Silli wrote:

I like your new quoting technique :)

> 2007-09-04 05:19:46 +0200 Sander Tekelenburg <st@isoc.nl>:
>
> [ Š Jon/the draft's example Š ]
>
>>
>><http://www.w3.org/mid/bde87dd20708311223l6a855926h243bbad726214099@mail.gmail.com>

[...]

>> <a href="/"><img src"house.png" alt="white house with a red, pointed
>> roof'></a>
>
> Please note that Jon's/the draft's example in the draft is _not_ compared
>with «white house with a red, pointed roof», but with a whole and full
>sentence where the difference between the good and the «bad» sentence is
>just definite and indefinite form - so to say. An author might well choose
>the "bad" example, here. It would be better if the bad example was rewritten
>to become as clearly bad as your excellent bad example above!

Yes, I'm glad that the spec now tries to give @alt examples, but there seems
plenty of room for improvement. But erm, we're all free to provide better
examples... ;) There's probably a good place for that somewhere in the wiki.

[... proposed <alt> element]

> But why is ALT needed inside OBJECT?

Not needed, but it's possible and allows authors to support pre-HTML5 UAs
through <alt>:

Authors wanting to make use of <alt> would otherwise have to either ignore
UAs that don't support it yet, or provide the exact same equivalent twice --
both through <alt> and as the content of <object>. That's extra authoring
work, (which also increases the chances of authoring mistakes). Because HTML5
UAs would have to support pre-HTML5 content, the result would also be that
HTML5 UAs would present both <alt> and the content of <object>. So the user
of a HTML5 UA would be bugged with each equivalent twice. (Which no doubt
would in turn make authors not want to use <alt> at all.)

Thanks to <object>'s simple fallback mechanism, authors can choose to place
<alt> inside <object> if they want to make use of cuttingedge HTML5
"accessibility" while still support pre-HTML5 UAs.

(Btw, the same story applies to @alt and @longdesc of course, which is why
the current <alt> proposal says they would have to be deprecated. (Because
there is no way that <alt> can be authored for both HTML5 and pre-HTML5 UAs
when it comes to <img @alt @longdesc>.))

> The fallback content can just be inside the OBJECT. And that is also how it
>is designed, except for some obstacles (see below).

A serious obstacle with <object>'s fallback model is that it is just that:
simple fallback. It requires authors to decide in which order the fallback
will occur. That works fine for simple cases where just one single text
equivalent is provided. But when video, audio, captioned video, Powerpint
slideshows, etc. are being provided as equivalents, thus model fails. In such
cases the author cannot know which equivalent will be most useful for a given
user in a given situation, so we shouldn't force the author to make such
decisions.

That's one of the rationales for <alt>.

[... <http://www.w3.org/mid/op.txzov6s8idj3kv@hp-a0a83fcd39d2.palace.opera.no>]

> Just the thing that currently OBJECT is not really designed to serve
>alternative content. Perhaps it is more working in the graceful degradation
>spirit: if it doesn't work, then would you like this insetead? OBJECT
>currently in some browsers requires faulty embedded content URIs in order to
>deliver the "alternative" content.

Are you referring to the 404 mention? I think that's a bug in the spec.
<object> should present its contents, no matter what the reason is that it
cannot present the 'intended' object. I don't know if the current mention
only of 404s is intentional, or just waiting for the editor to find time to
describe this in more general terms.

> It would have been better, and probably more accessible, if OBJECT was
>designed not to fullfil graceful degradation requirements  but rather
>according to a «augmentative authoring» idea [1]. That, in itself, should
>lead to the effects that Simon Pieters took up as desired, namely that users
>should be able to pick the best variant of the OBJECT element content based
>upon preferences and not upon what fails or not in the UA.

Right. That appears to be the same idea as <alt>:
<http://esw.w3.org/topic/HTML/ABetterAlt>.

[... authoring tools's possible behaviour to encourage 'better' HTML]

> Let's hope such a thing that you suggest would not be something that could
>make authors switch authoring tool Š

Well, I do hope they *will* swtich to authoring tools that generate more
accessible sites ;) (Or not switch, but have their favourite authoring tool
upgraded to do better.)

[...]


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Tuesday, 4 September 2007 18:31:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:49 UTC