- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Fri, 22 Apr 2011 21:23:35 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
- CC: Paul Cotton <Paul.Cotton@microsoft.com>, "Sam Ruby (rubys@intertwingly.net)" <rubys@intertwingly.net>, "Maciej Stachowiak (mjs@apple.com)" <mjs@apple.com>
I am formally withdrawing my CP. -----Original Message----- From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Silvia Pfeiffer Sent: 22 April 2011 05:15 To: HTML Accessibility Task Force Subject: Re: [media] proposed a11y TF letter on issue-152 Note that I have sent the letter with the small change that Mark proposed. I suggest individuals who have put forward change proposals follow up on the email to state if they are prepared to withdraw their change proposal even if the 5 outstanding issues are not immediately included and will continue to be worked on through the bug tracker. Eric and I will do that with ours. Regards, Silvia. On Thu, Apr 21, 2011 at 11:00 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Hi all, > > in today's call we discussed outstanding issues on the media > multitrack change proposals, which we would like to see addressed as > part of accepting proposal 4 on our summary list, see > http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposals_Summary#Proposal_4:_Controller_proposal > . > > Below is a draft letter of consensus to be sent to the HTML Working > Group to help resolve issue-152. > > DEADLINE: this letter will be sent in 24 hours from now, so if you > disagree with anything stated below, please speak up. > > IMPORTANT: as part of the letter, the individual change proposals 1-3 > on issue-152 are withdrawn, so check if that is in your interest. > > (Note that Ian just added a getID() function, so I was able to remove > this from our list of discussed changes form today's call.) > > Cheers, > Silvia. > > > Here is the proposed letter: > > --- > Subject: Accessibility Task Force consensus on Issue-152, media multitrack > > Dear HTML WG chairs, > > The undersigned members of the media subgroup of the accessibility > task force have come to a consensus on ISSUE-152, which we'd like to > share with the larger group through this email. > > We appreciate the extra time provided to us by the chairs to further > discuss the submitted four change proposals and come to an agreement. > There have indeed been lengthy discussions during the provided time > frame and we have made great progress. > > The group has come to a consensus on which proposal to support. While > some of our feedback on that change proposal has already been taken on > board, there is still a list of 5 outstanding changes that need to be > addressed for the specification text to be complete. > > The four proposals on the table are as follows: > > 1. Audio Track Selecction for Media Element > submitted by: Frank Olivier > http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0363/CP_Issue152.htm > > 2. Media Multitrack Change Proposal 2: Synchronize separate media > elements through attributes > submitted by: Sean Hayes > http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal_2 > > 3. Media Multitrack Change Proposal: Synchronize separate media > elements through attributes > submitted by: Silvia Pfeiffer and Eric Carlson > http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal > > 4. Proposal for Audio and Video Track Selection and Synchronisation > for Media Elements > submitted by: Ian Hickson > http://lists.w3.org/Archives/Public/public-html/2011Mar/0436.html > > > CONSENSUS > The undersigned members of the media subgroup of the accessibility > task force have agreed to withdraw proposals 1-3 in favor of proposal > 4. > > However, we request the following additions to be made to the proposal: > > (1) track kind for in-band tracks: > > At this point, it is also not possible to discover the functionality > that a in-band track provides through script. A similar problem was > solved for the TextTrack object by introduction of a kind attribute. > This is also necessary for the TrackList object, in particular to > introduce a standard naming scheme across different media container > formats for exposing the kind of data that their tracks provide. > > Therefore, we request addition of a getKind(in unsigned long index) > function to the TrackList object, or something of equivalent > functionality. > > The proposed list of values that kind should understand are: > for video: > * sign language video (in different sign languages as provided through > getLanguage()) > * captions (as in: burnt-in video that may just be overlays) > * different camera angles > * video mosaic > for audio: > * audio descriptions > * language dub > * commentary (such as director's commentary) > * clear audio (see > http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Clear_audio) > > > (2) loop attribute for grouped multitrack: > > The MediaController object currently does not allow for looping of the > grouped resource. This is inconsistent with what is possible on > individual media elements and also inconsistent with what is possible > on in-band multitrack media resources. The same behavior that an > in-band multitrack resource exposes on looping needs to also be > possible on a grouped multitrack resource. > > Therefore, we request addition of a loop IDL attribute on the > MediaController object. > When it is set to true, playback on the grouped multitrack must > restart after all slave elements have ended. > > It is set to true when at least one of the media elements in the group > have a loop IDL attribute that is set to true, false otherwise. > Alternatively, it would also be acceptable to set it to true only when > all of the media elements in the group have a loop IDL attribute that > is set to true, though that seems overly verbose. > > > (3) autoplay attribute for grouped multitrack: > > The MediaController object currently always autoplay without a means > to control this autoplay behaviour and without consistent autoplay > across all the slave elements. This is inconsistent with in-band > multitrack media resources. One of the main use cases for the > introduction of autoplay attributes was that this allows the UA to > expose a user setting that disables autoplay behaviour, which is > particularly useful to vision-impaired users who cannot easily locate > autoplaying media elements. > > Therefore, we request addition of a autoplay IDL attribute on the > MediaController object. > When it is set to true, playback of the grouped multitrack must start > once all slave elements have reached a readyState of HAVE_ENOUGH_DATA > and can play through. > > It is set to true when at least one of the media elements in the group > have a autoplay IDL attribute that is set to true, false otherwise. > Alternatively, it would also be acceptable to set it to true only when > all of the media elements in the group have a autoplay IDL attribute > that is set to true, though that seems overly verbose. > > > (4) readyState for grouped multitrack: > > The MediaController object currently does not expose an aggregate view > of the readyState of the slave media elements. It is, however, > impossible for a developer to reliably aggregate the readyState from > the individual slave media elements, since their states may continue > to change. The media framework inside the UA is the only place where > such aggregation is sensibly possible. > > Therefore, we request addition of a readyState IDL attribute on the > MediaController object. > It must represent the minimum state that all the slave media elements > have achieved. > > > (5) onended event: > > The MediaController object currently does not expose an onended event. > This is inconsistent with in-band multitrack media resources and a > convenience event that is useful when reacting to the situation of all > slave elements being finished. This would for example be the case for > a grouped multitrack resource with an ordinary video track and a sign > language track, where the ordinary video track should get a display of > further related videos once all tracks have finished playing. It would > e.g. wait until the sign language track is finished before it > displayed further information. > > Therefore, we request addition of a onended event to the MediaController object. > > > Best Regards, > > Media Subgroup of the Accessibility Task force > > Judy Brewer > Janina Sajka > John Foliot > Sean Hayes > Frank Olivier > Eric Carlson > Mark Watson > Bob Lund > Silvia Pfeiffer > (is there anyone I've missed or wants to be on that list?) >
Received on Friday, 22 April 2011 21:24:09 UTC