- From: John Foliot <john@foliot.ca>
- Date: Wed, 21 Mar 2012 14:24:43 -0700
- To: "'David Singer'" <singer@apple.com>
- Cc: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, <janina@rednote.net>, '"'xn--mlform-iua@målform.no'"' <xn--mlform-iua@xn--mlform-iua.no>, <rubys@intertwingly.net>, <laura.lee.carlson@gmail.com>, <mjs@apple.com>, <paul.cotton@microsoft.com>, <public-html-a11y@w3.org>, <public-html@w3.org>
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:23 UTC