RE: Accessibility Task Force consensus on Issue-152, media multitrack

Likewise, based on the progress in the media a11y group:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposals_Summary 
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0218.html 

I am withdrawing my Audio Track Selection proposal (http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0363/CP_Issue152.htm) as the current Proposal 4 represents the same concept with consensus from the group.

Thanks
Frank Olivier

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Silvia Pfeiffer
Sent: Friday, April 22, 2011 12:19 AM
To: public-html; Paul Cotton; Sam Ruby; Maciej Stachowiak; Eric Carlson
Subject: Re: Accessibility Task Force consensus on Issue-152, media multitrack

This is a reply by Eric and myself.

Eric and I hereby confirm that we withdraw our change proposal 3 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal
since we are in amicable consensus with change proposal 4, even if the
5 changes listed below are not applied immediately, but registered as bugs on the spec and dealt with post LC.

Best Regards,
Silvia & Eric.


On Fri, Apr 22, 2011 at 5:18 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> (sending this on behalf of the accessibility task force)
>
> 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_Is
> sue152.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 with 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#Cl
> ear_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
>

Received on Friday, 22 April 2011 23:38:26 UTC