Re: Investigating the proposed alt attribute recommendations in HTML 5

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>:

[...]

> 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.

Indeed.

[...]

> However, perhaps you should explain how we possibly are disagreement? :-) I
>am not sure how/why the @ALT should not be descriptive

Well, look at a web page with an img that has alt text, without loading the
image. Good alt text is an equivalent of the image. meaning it conveys the
same thing that the author intends to convey through the image. @alt should
not decsribe the image.

Jon gave a couple of good examples earlier in this thread:
<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."').

If an image needs an elaborate description, @longdesc is appropriate.

> Š 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

Indeed. You could do that through @longdesc though.

> , unless, it e.g. deals with the architecture of the Whitehouse Š

Then still. The only thing that matters is what the author means to *convey*.
If he does so through an image, then proper equivalents (such as @alt, or
audio, or whatever) convey the exact same.

It's a mindest thing, I guess. Relatively simple, but you have to 'switch'
your mind to this approach. When you do, it gets easier to come up with the
right alt text. You onlly need to ask yourself "what am I tryingto convey
with this image?". And you can help yourself by looking at the page in a
browser, without the image loaded, and judging whether your alt text conveys
what you men to convey, and fits the flow of the surrounding content (again,
as Jon nicely explained).

> 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>

Sure, one can figure out what is meant, but it is tiring to have to always
distill meaning, instead of it just being fed to you ;) This would be so much
easier to digest:

<a href="/" rel="home"><img src"house.png" alt="Home"></a>

or this:

<a href="/" rel="home">Home <img src"icons/house.png" alt=""></a>

[...]

>> 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.

I think so, yes. (Although it might be necessary to actually test how wll
this actually works.) It would also be a demonstration that there are cases
where it's better to have no @alt, than @alt="".

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

Yes, sorry for the silly pharsing. That's what hanging with americans too
much does to your language :)

[... <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.)

> 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.

> 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 ;))

>>> 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 ...)

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".)

> There is actually nothing that prevents UAs from implementing this today ...

[Assuming you meant "authoring tools"]

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'?"

I hope the The Web Repair Initiative can help with these problems.

> 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.

[...]

> 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.

Yeah. I guess part of the rationale is that "missing image" is an error that
should be conveyed to the user. (I think I disagree. Users should have the
option to choose not to be bugged with error messages they don't care about:
"just give me the damned textual equivalent!". Whether that should be the
default I'm not sure yet though).

Or it might be just yet another inheritance of Netscape... Just like <h1>
being presented the way it is, and UA vendors fear that they may lose
customers when they change that. (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.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Tuesday, 4 September 2007 03:23:06 UTC