- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 12 May 2011 10:26:16 +1000
- To: John Foliot <jfoliot@stanford.edu>
- Cc: David Singer <singer@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, James Craig <jcraig@apple.com>, Michael Cooper <cooper@w3.org>
On Thu, May 12, 2011 at 9:29 AM, John Foliot <jfoliot@stanford.edu> wrote: > David Singer wrote: >> >> I think the point is that the poster and the aria-label are both about >> the video (they are peers) > > Exactly. That's exactly the kind of impression that I am trying to avoid. There is no need to provide a label on the video - @id does that perfectly well. There is also no need to provide an alternative description of the video content: @alt is not there to provide a summary of the video content. Text alternatives are about providing text alternatives to what only a sighted user sees and we are talking about the pause situation here, so the video and the poster are identical in this situation. >> so it might be better to say >> >> <video poster="media/ClockworkOrangetrailer.jpg" controls >> aria-label="A Clockwork Orange movie trailer"> >> <source src="media/ClockworkOrangetrailer.mp4"> >> <source src="media/ClockworkOrangetrailer.webm"> >> <source src="media/ClockworkOrangetrailer.ogv"> >> </video> > > For accessibility API mapping, naming the <video> object as "A Clockwork > Orange movie trailer" would be acceptable, No, it's not acceptable - it provides more information than the placeholder frame provides, which is not what text alternatives are about. > although I still do not believe > that it solves the broader problem statement: what is the 'textual > alternative' to this resource, for users and user-agents that do not > support/consume graphical objects? Aria-label is not text that is intended > to render on screen, it is more akin to an ID, in that it names the object > but does not display onscreen text. > > I am leery as well of making a one-time exception to aria-label when used > with <video>, as this adds additional complexity to the authoring stage > (and perhaps also to the browser/user agents). Fair enough. > The <video> element can take aria-label today with no change to the > specification - re-envisioning aria-label to provide alternative text > however is incorrect. Is that really the case? IIUC, neither aria-label nor alt are conforming attributes on media elements and screen readers ignore them. A test with ChromeVox confirms this, though I cannot test any other screenreader on my mac. Silvia.
Received on Thursday, 12 May 2011 00:35:05 UTC