RE: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]

David Singer wrote:
> 
> OK, there is the problem, it doesn't.  It has one object, the video;
> you are entrenched in a confused position caused by the unfortunate
> choice of the word 'poster'.  Everything else you say is founded on
> this misapprehension.
> 
David,

I am not confused. There are 2 visual assets - one is a "moving" picture and
the other is a static picture. While they are certainly related (as salt is
to pepper) they are also - or can be - different, especially if the image
contains embedded text, which needs to be surfaced to the non-sighted user. 

Continuing to argue that salt is pepper will not change the fact that one is
not the other.

Sean Hayes wrote:
> 
> So either we change that note to be normative text, replacing "intended
> to be" with "must be" in which case I would concede Dave's point
> (although in such a case we should also require that the video
> description needs to convey a detailed description of the frame in
> question); or we concede John's point that there currently exists the
> possibility that the image is not deployed as *intended*, but rather as
> *allowed*, and is carrying other interesting information which is not
> in the video that a person who can't see is entitled to be able to
> perceive.

This is exactly what I am arguing. Since the author can specify *ANY* image,
there exists the possibility that the image will require its own means of
being expressed in a textual way.

At any rate, as I previously noted, this went nowhere at the HTML-WG, and so
I approached the ARIA-WG, who understood the need and user-requirement
without too much difficulty. So, like the aria-describedat Unofficial Draft
that Rich Schwerdtfeger announced today
(http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/describedat.html) there
is also a proposal (even less fleshed out) to create an aria-mechanism to
address this need. It will probably bear a striking resemblance to
aria-describedat except that it will be a mechanism that can describe, not a
visual element, but rather a visual property of an element (that "attribute
of an attribute" problem). I think that not only would it solve the @poster
issue, but could be further extended to cover other complex images rendered
(for example) as CSS backgrounds.  Stand by for more details.

JF