[Bug 10455] Mint a describedby attribute for the img element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455





--- Comment #42 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-08-30 23:15:40 ---
(In reply to comment #39)
> (In reply to comment #37)
> > (1) The example above represent millions of images. Is it smart to let a
> > substantially less common usecase stand in the way of the most common usecase?
> 
> When the less common use case represents a fundamental feature of hypertext?
> Yeah, kinda.

Reading your comment at the bottom, I understand that you simply dismisses the
entire usecase. (See bottom.)

As for "represents a fundamental feature of hypertext", then what do you mean?
Does @longdesc (and @cite also, then, I assume) represent a fundamental
hypertext feature? They are links, so in that way yes. Not sure if I catched

Just for the record: I am in favour of @longdesc. I want it. But my mission
here is to gather support for @rel="longdesc". Users deserve something that
work. I understand that you see no value in @rel="longdesc" - could sound as
you only see problems with it, even.

> I think all of the proposals presented so far are complicating the creation of
> long descriptions

I suppose @longdesc is supposed to provide something for the user? At least,
that is why I am enganging in this debate, coming up with alternatives - as
well as with defence!  Of course, @longdesc is much simpler to author. But
"simple to author" is not as important as "actually works".

> to the point that just reverting to visible D-links will be
> the standard case. I doubt that any assistive technology will implement support
> for markup so complex that it's likely to be broken in many cases.

So, I suppose you are against image map solution together with <canvas> also
then? It is too complex? The coding problems that can bee seen from my test
case (http://malform.no/testing/longdesc/ARIA+anchor@rel=longdesc.html) has to
do with lack of unified image map support. It is also related to ARIA - perhaps
HTML5's native sematics will solve some of those problems. Also, the
complicated code is due to the fact that I attempted to make it compatible with
user agents and AT which do not support @longdesc
(http://malform.no/testing/longdesc/index.html) - I don't know if you took that
into account, before letting us here you negative view?

When you dismiss <a href="*"><q cite="cite"><img src="*" alt="*"></q></a> as a
solution to some use cases, then I feel that you dismisses your own point,
because @cite and @longdesc are the same kind of features. (Again, I support
both @longdesc and @cite - see Comment #15.)

> > I want to point out that for the code example above, the only link text
> > is the @alt text. Thus the alt text has to serve a double cause: as link
> > text and as @alt text.
> 
> That's the common case for alt text today. 

Can you show me concrete examples which shows that the @alt text is authored in
such a way that it can function well both as link text and as "textual
substitute" for the image?

>I don't know what problem this solves.

It establishes a microformat, which solves the exact same use case as
@longdesc. It is possible to give concrete advice to the author that they, when
they use this microformat, should consentrate on writing a good "textual
substitute" for the image rather than focusing on the fact that the @alt text
also serves as link text. The link text will instead by provided by the user
agent - the same way that JAWS presents @longdesc today. It is one-to-one the
same as @longdesc, except that it works for more users. If, in reality, authors
will not use this method, because of desing prettyness considerations ... OK.
But I'm pretty sure that some authors *will* use it.

> If there's alternate content that's not expressed in @alt, I believe it
> should still be bound within the element, not in an <a> wrapper. 

Perhaps this was not so easy to understand, but I meant exactly this
microformat:

<a href="link" rel="longdesc"><!-- no text here! --><img src="s"
alt="Lorem"><!--no text here! --></a>

Thus, every text must be inside the @alt attribute, in this microformat - no
text is permited outside the <img> element. Every text between the <img> and
the <a> wrapper, is forbidden.

> Anchors are an
> already well-defined semantic, and I don't like the idea of telling authors
> that you can either link an image or provide a long description simply in the
> name of expediency.

I don't understand what, in this context, you mean by "link an image" (??) and
"provide a long description" (do you mean "provide longdesc linnk"?).  But in a
preceding comment, I made it very clear that, to provide a @longdesc URL does
not free you from writing a proper @alt text. Also see this comment, to
CSSquirren's Comic #72, which fails that test, by providing virtually an empty
@alt together with a @longdesc:
http://twitter.com/komputist#status_star_22556395542
The same goes if you use rel="Longdesc" instead of @longdesc: you must have
proper @alt. I don't know if that cleared up anything.

Regarding what to tell authors: it *impossible* today to tell author to use
@longdesc, unless you know that their audience use some very specific user
agents. In addition you have learn them some kind of workaround - duplication
of @longdesc link in a anchor element, something like that.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Monday, 30 August 2010 23:15:44 UTC