- From: John Foliot <john@foliot.ca>
- Date: Tue, 22 May 2012 09:11:16 -0700
- To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, "'Charles McCathieNevile'" <chaals@opera.com>, "'Edward O'Connor'" <eoconnor@apple.com>, "'Janina Sajka'" <janina@rednote.net>
- Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Silvia Pfeiffer wrote: > > In an effort to work towards a consensus Change Proposal on Issue 194, > we've had several media subgroup meetings, the result of which is the > following Change Proposal: > > http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement > > The media subgroup (those present at the meeting) agreed to post this > CP to the whole a11y TF for review over the next few days, and then go > forward with a call for consensus. > Some notes: 1) "Satisfying [UC1] linked transcripts" "Web browsers can render a menu on top of the video with the links off-page and the first line of text inside the transcript as a "label". (Or should we use an explicit label/legend element to provide this?)" If I can find 1 significant fault with this is that a) I don't recall discussing this, and b) we discussed (and I was quite vehement) that the "controlling switch" be rendered as such by the UI/User Agent as part of the video controls. >From my [private] recap email that I forwarded to you, Janina and Chaals: "I use [button] to mean an interactive control/switch which may change from device to device and platform to platform, but will always be a native browser control." (It was my understanding that we had consensus there) In this fashion, the semantics of [button] (http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON) and (http://www.w3.org/TR/wai-aria/roles#button) are conveyed to the end user (the consumption by choice piece), and yes it would have a label (aria-label), although at this point it could be "hard-wired" to the UI so that the author does not need to include the aria-label attribute. >From your response to that same earlier email: JF: > So a clear part of the change proposal is to capture this > requirement, perhaps along the lines of "User-agents MUST expose the > presence of @transcript and the ability to consume the transcript to all > users" - I am neither a wordsmith nor a tech writer but you get the idea > (and yes, that was RFC 2119 MUST <smile>). SP: There is basic agreement on the <transcript> element and a @transcript attribute. I'm not sure we can go as far as having a MUST requirement on the controls getting a visual exposure on the video element for transcripts, but we can certainly recommend there to be one and we can require the transcript availability to be announce by AT. Silvia, if MUST is too strong, then SHOULD would be acceptable. Having the trigger as a [button] aids significantly to the "announced by AT" requirement, as well as the "R2: Choice to consume - the option to consume or not consume the transcript remains in the control of the user" requirement. Failing to capture this more directly in this CP is a significant flaw and (potential) deal-breaker (for me). Can we discuss how to better capture this intent/requirment in the CP? ***************** 2) "Satisfying [UC3] interactive transcripts" & "Satisfying [UC4] transcript-only pages" <video transcript="t1" src=video.mp4></video> <transcript id=t1 width:200 height: 200> <track src=transcript1.vtt srclang=en default> <track src=transcript2.vtt srclang=de> </transcript> I'm not sure if this was simply a fat-finger issue, but I have concerns about the sizing syntax you are proposing here. If it is the 'old-school' HTML 4 sizing construct it should be: <transcript id=t1 width="200" height="200"> Conversely, if we do this in the CSS fashion, it should be: <transcript id=t1 style="width:200; height:200;"> ...or: transcript.t1 { width:200; height:200; } I suspect that either should be good, but our code example(s) should reflect either (or both) - what I see is something new again (unless something else has slipped my attention completely). I've not made any edits (yet) but happy to do so. ***************** 3) JF Edits to the Wiki: * Turned the "Satisfying" sections into level 3 headings for readability and improved (accessible) structural markup * Minor grammar edits (some spelling and some phrasing) * Added 2 examples of interactive transcripts for Section "Satisfying [UC3] interactive transcripts" (3PlayMedia and YouTube) * Removed "Is a better solution for long text alternatives than @longdesc or @aria-describedAt, since it also solves the interactive transcript need." Per comments/feedback from Chaals & Laura (I concur BTW) ***************** 4) Nits: a) "Author: Silvia Pfeiffer (Google) & the HTML Accessibility Task Force" I think that the contributions of Chaals, Janina and myself should be highlighted more, as at this time it was not the a11yTF that contributed here, but rather we 4 through close to 6 hours of teleconference. In particular, in the User Requirements section, you quoted from my recap email to Chaals almost verbatim <wink> ("Just a note for Charles that I am due to adapt my CP over the weekend with much of the below.") It also supports the final statements that I will be withdrawing my other Change Proposals to support this CP. If we can get the [button] issue worked out I will withdraw those CPs this week, in advance of the May 24th date. JF
Received on Tuesday, 22 May 2012 16:12:35 UTC