- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 22 Mar 2012 07:24:32 +1100
- To: David Singer <singer@apple.com>
- Cc: Sean Hayes <Sean.Hayes@microsoft.com>, John Foliot <john@foliot.ca>, "janina@rednote.net" <janina@rednote.net>, "'xn--mlform-iua@målform.no'" <xn--mlform-iua@xn--mlform-iua.no>, "rubys@intertwingly.net" <rubys@intertwingly.net>, "laura.lee.carlson@gmail.com" <laura.lee.carlson@gmail.com>, "mjs@apple.com" <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "public-html@w3.org" <public-html@w3.org>
On Thu, Mar 22, 2012 at 6:48 AM, David Singer <singer@apple.com> wrote: > > On Mar 21, 2012, at 12:13 , Sean Hayes wrote: > >>>> 1) The <video> element, when containing both a media asset and an >>>> image, now has 2 objects that require a longer textual description. >> >>> 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. >> >> >> Well let us look at what the spec actually says. I think we have to admit that regardless of its name there is definitely the possibility of an image: >> >> <quote>The poster attribute gives the address of an image file that the user agent can show while no video data is available. The attribute, if present, must contain a valid non-empty URL potentially surrounded by spaces. </quote> >> >> I see nothing in that (normative) text that constrains that image to be a frame of the video. >> >> We do have the following (informative) note >> >> <quote>The image given by the poster attribute, the poster frame, is intended to be a representative frame of the video (typically one of the first non-blank frames) that gives the user an idea of what the video is like. </quote> >> >> 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. >> > > > Or we simply say the obvious "If the image is not a representative frame of the video, or conveys information in addition to the content of the video, then a description of that information must also be included with the description(s) of the video that are supplied for accessibility (e.g. alt, longdesc, transcript, etc.)." I agree with this sentence - in particular if it solves the deadlock. However, we don't currently have alt, longdesc or transcript attributes defined for video. We could say "... (e.g. aria attributes)." and then clarify this part of the sentence as we add other accessibility attributes to <video>. Cheers, Silvia.
Received on Wednesday, 21 March 2012 20:25:25 UTC