- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 6 Jan 2011 15:36:02 +0100
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: John Foliot <jfoliot@stanford.edu>, David Singer <singer@apple.com>, Eric Carlson <eric.carlson@apple.com>, Janina Sajka <janina@rednote.net>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Laura Carlson <laura.lee.carlson@gmail.com>
Hi Steve, Excellent, that's exactly the kind of discussion we should have. Since <video> is new, we can basically start from scratch and make sure browser vendors understand, too, what is required to implement. I think we should firstly discuss what needs we actually have - aside from time-synchronized alternative content on which we have already spent a lot of time. Do we e.g. need: 1. short text alternative 2. long text alternative 3. summary 4. caption (as in figure caption) 5. label (and anything else missing?) And then we should discuss how do we technically realize it, e.g.: 1. short text alternative: @title or @alt or <alt> element or something else? 2. long text alternative: would this be satisfied by a transcript? or do we need to distinguish long and full text alternatives? etc And finally we should discuss how that should be presented on Web pages and to AT, e.g.: 1. short text alternative: should @title be a tooltip? should @alt be the text to render to AT? etc. I thought Michael Cooper and the bug triage team did a good start at analysing the general situation. My personal interest is to solve it for <audio> and <video> and I don't think we had sufficient discussion on this yet. Cheers, Silvia. On Thu, Jan 6, 2011 at 2:52 PM, Steve Faulkner <faulkner.steve@gmail.com> wrote: > Hi Silvia, > > One comment: use of the title attribute to provide a short text alternative that is not available elsewhere is not practically accessible to keyboard only users on any browser and is highly unlikely it will be any time soon given that the browser vendors have had 10+ years to fix the issue with device independent title attribute content display. > > So any solution that relies upon it's use is not a good one. > > Sent from my iPhone > > On 6 Jan 2011, at 14:19, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > >> On Wed, Jan 5, 2011 at 8:51 PM, John Foliot <jfoliot@stanford.edu> wrote: >>> David Singer wrote: >>>> >>>> 1) I meant to say, if you wish to have a page that shows an image that >>>> is semantically distinct from the video which eventually replaces it >>>> when some event happens, you have all the tools you need in >>>> HTML/CSS/script already, and if you use these tools, then that image >>>> can be fully associated with alt text etc. as it is a normal HTML >>>> image. >>> >>> David, >>> >>> I think here, you have hit the nail squarely on the head. This is indeed >>> the use-case and problem scenario: sure, the tools to do this exist in the >>> toolbox already and, in fact, my buddy Faruk Ates coded up an example for >>> me as part of my efforts here: >>> >>> http://john.foliot.ca/experiments/video/poster2.html >>> >>> - not only does the placeholder image have an @alt value, I've also >>> petulantly added an @longdesc attribute to an otherwise valid HTML5 >>> document to make 2 points (1 - that using @longdesc in HTML5 documents >>> still works, and who cares about validation when accessibility wins? 2 - >>> We still need a means to link to a longer textual description of images >>> that is *user-controlled*) >>> >>> The larger problem however is to achieve this, there is a fair bit of >>> coding required, whilst *visually* it achieves the same effect as >>> "...poster="path to image"...", >>> >>> http://john.foliot.ca/experiments/video/poster.html >>> >>> ...and so what we will end up with is that many developers will take the >>> easier way out - it's simple human nature, and as you yourself have >>> pointed out, we have no way of 'policing' what developers will do. >> >> >> I don't think it's an "easy way out". I don't actually see the need as >> a developer to choose the difficult road. I cannot actually think of a >> use case where I would want to use this kind of markup when there is >> already the simpler markup available with the @poster attribute. While >> we didn't have the @preload attribute, there would have been a need - >> namely a Web page that has many video elements and wanting to avoid >> all the video elements downloading their setup information during page >> load time to avoid making the user wait or even breaking their Web >> browser with this load. But we now have @preload="none" so we don't >> need this any more. We can for example say: >> >> <video controls aria-describedby="kitten" poster="poster2.png" >> title="A perfectly valid html5 video example"> >> <source src="dizzy.webm" /> >> <source src="dizzy.mp4" /> >> <source src="dizzy.ogv" /> >> </video> >> >> <p><a href="videotranscript.html">Read the transcript for this video.</a></p> >> >> <p id="kitten" style="margin-top: 415px;">A short HTML5 video of a >> kitten chasing a flashlight. Original video created by Remy Sharp and >> found at <a href="http://html5demos.com/video">http://html5demos.com/video</a></p> >> >> This example includes all your accessibility needs for the >> video+poster and it is independent of whether the poster image is >> provided as a separate image or as the first frame of the video - in >> the latter case you just remove the poster attribute. >> >> We have all of the following: >> >> 1/ a short text alternative on the video element through @title (I >> don't know whether this is the right attribute, but it is available at >> this stage). The short text alternative has the same functionality as >> the preview image, namely to entice the user to start watching the >> video. >> >> 2/ a long text alternative on the video element in the form of @aria-describedby >> >> 3/ a full text alternative on the video element in the form of the transcript >> >> >> >>> We are already establishing a design pattern that places all of the >>> 'supporting' content that the multi-media resource of <video> requires as >>> children elements of <video> (notably, the <track> element). <track> is an >>> element rather than an attribute as this way we can also 'layer-on' >>> additional attributes (like @lang, ARIA attributes, etc.) - elements are >>> always "stronger" than attributes. >>> >>> So... let's create another child element of <video>: call it <poster> or >>> call it <firstframe>; call it whatever we need to call it, but it's 'role' >>> (hello ARIA) is to represent the placeholder image that will be removed >>> once the video is activated. >>> >> <..> >>> <video src="trailer.m4v"> >>> <firstframe src="mpaa_rating.png" alt="This video is rated G for >>> all audiences"> >>> </video> >>> >>> - or - >>> >>> <video src="trailer_with_mpaa_rating.m4v"> >>> <firstframe alt="This video is rated G for all audiences"> >>> </video> >> >> >> >> As you examples demonstrate, this creates a short text alternative on >> a subelement of the video element - a @alt attribute on the >> <firstframe>. The vision-impaired user that tabs through the elements >> on the page actually tabs onto the video element as a single entity. >> In your example, would the screen reader then read out this short text >> alternative from the <firstframe> element? If so, why would we not >> just use it on the <video> element directly? >> >> >> >>>> If, on the other hand, the image is a transient place- >>>> holder that has the same semantics as the video, and is predominantly >>>> there to avoid having blank space on the page, then the existing state >>>> is fine (provided we have good accessibility provisions for the video >>>> itself, which I currently am unsure about). >>> >>> This raises a related question: should <video> (sans an author declared >>> poster frame, and for argument offers the first frame, which is an empty >>> frame) require/take on a short textual description? >> >> >> That is indeed the much more important question to ask. In fact, I >> would suggest this group drop all discussions about text alternatives >> on poster attributes and focus on whether we have covered all text >> alternative requirements on the video element (and audio element for >> that matter). By solving that question we will also solve the question >> about text alternatives on poster. >> >> I would like to get back to some discussions started about this in the >> following thread: >> http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0246.html >> and in particular this link: >> http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0246/embeddedcontent.html >> >> There, the following text alternatives were listed that the <video> >> element currently supports >> 2. @title >> 3. embedded content (which one could argue provides everything >> required for long text alternatives) >> 5. @aria-labelledby >> 6. @aria-describedby >> >> What the email argues for <video> was that <video> needs only the following: >> 1. long text alternative - in the form of a transcript >> 2. label - in the form of @title >> 3. idiosyncratic direct accessibility - in the form of embedded content >> These are all possible at this stage. >> >> What it argues that <video> doesn't need is: >> 1. a short text alternative >> 2. a caption >> 3. a summary >> >> I personally think that we could need these three for videos, too, but >> wanted to have a discussion on this. >> >> The first could be satisfied through an @alt tag (that also thus >> covers the poster). >> The second already works through <figcaption>, so we don't need >> something special here (see the video example at >> http://dev.w3.org/html5/spec/Overview.html#the-figure-element ). >> And the third would work with @summary, though I don't really think >> that's necessary either. >> >> So, I am still curious what people think about all this? >> >> Cheers, >> Silvia. >> >
Received on Thursday, 6 January 2011 14:38:02 UTC