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

Ow... sorry - that went totally to the wrong list!
Thanks for noticing!
Silvia.

On Fri, Apr 22, 2011 at 2:47 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> Hi Silvia,
>
> Could you please also post these messages to public-html so the whole WG is aware?
>
> Thanks,
> Maciej
>
> On Apr 21, 2011, at 9:20 PM, Silvia Pfeiffer wrote:
>
>> 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 2:12 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_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 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#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
>>>
>>
>
>

Received on Friday, 22 April 2011 07:17:37 UTC