Re: Investigating the proposed alt attribute recommendations in HTML 5

2007-09-04 05:19:46 +0200 Sander Tekelenburg <st@isoc.nl>:
> At 03:50 +0200 UTC, on 2007-09-03, Leif Halvard Silli wrote:
>> 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>:

[ … Jon/the draft's example … ]

> <http://www.w3.org/mid/bde87dd20708311223l6a855926h243bbad726214099@mail.gmail.com>
> (where he says 'An aural UA can announce "You are standing in an open
> field west of a house. The house is white, with a boarded front door.
> There is a small mailbox here."').

[ … ]
>> Is it a (real) problem that authors think they have to describe things in
>> order to bring a textual equivalent of the image?
> 
> Depends per case, I suppose. But personallyt I would very quickly get very
> tired if I'd have to consume stuff like this:
> 
> <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!

> [... <alt>]
> 
>> 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?
> 
> Excellent question :) I don't think we've talked about that yet. (I haven't
> really thought about it yet myself. Maybe you should start a new thread for
> this. See if people have ideas about it.)

Yes. It really seems there are some serious issues relating to alternative/equal content when it comes to OBJECT.

>> 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?
> 
> Not really. the idea of <alt> (as currently described in the wiki), would be
> that it can live anywhere in the document. (Thanks to its @for attribute
> making clear for what it is an equivalent.) However, to support pre-HTML5
> UAs, authors could indeed embed <alt> inside <object>. I think that would
> provide nice and easy backwards compatibility.

It has some advantage as well - keeping things together in the code. But why is ALT needed inside OBJECT? The fallback content can just be inside the OBJECT. And that is also how it is designed, except for some obstacles (see below).

>> 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)»
> 
> Not sure what exactly you mean. (I know the thread, but not about exactly
> which issue you wonder exactly what ;))

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. 

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.

[ … author with noALT … ]

>> 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 ...)
> 
> Yeah, that could be too much. Maybe "bug the author at least once before
> initial publication" would be a more realistic requirement. (But still always
> allowing the author to 'request an accessibility report', which in my mind
> can very well simply mean: "act as if I'm publishing this document for the
> first time".)

Could be possible. I just wonder: UA vendors do want to be so purist that they make users switch to other UAs. Let's hope such a thing that you suggest would not be something that could make authors switch authoring tool …

>> There is actually nothing that prevents UAs from implementing this today ...
> 
> [Assuming you meant "authoring tools"]

Thanks!

> Well, one threshod is that few people request such functionality from their
> authoring tool. So there is little incentive to bother to implement such
> qualities. Another issue is probably plain and simple marketing: when an
> authoring tool does offer such qualities, how will it be found by those who
> want it? Also, there are the tough questions like you asked: "just what
> amount of user bugging 'works'?"

When we run a page without DOCTYPE or charset info in the W3 markup validator, we will get at 'tentatively valid' document report, if I remember. It seems to me that even @ALT content could be subject to tentatively validation. The valdiator could bug the author about @ALT, much like you said that a tool should do.

[ … key content … ]

>> Do you link this to the 'key content' debate at all? Who are we benefiting
>> this way?
> 
> Sorry, I can't follow.
> 
>> 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?
> 
> I've seen those terms used before, but I'm having trouble understanding what
> people mean with them.

I think they try to discuss with those that introduced those terms. 'Key content' is also in the draft.

[ … 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 […]

> [… ] (The growing diversity of browsing
> situations that people use might change that though. For instance, it sucks
> double when your small screen handheld wastes screen space to indicate a
> missing image. If people get used to handhelds presenting things somewhat
> differently, yet entirely or even more usable, they might slowly get more
> comfortable with such variance in other browsing situations too.)

A good point!

[1] <http://www.cs.tut.fi/~jkorpela/html/augm.html>
-- 
leif halvard silli

Received on Tuesday, 4 September 2007 11:31:28 UTC