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

Received on Wednesday, 21 March 2012 21:25:26 UTC