W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 21 Apr 2011 21:47:37 -0700
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, Eric Carlson <eric.carlson@apple.com>
Message-id: <7FDF2CD0-E163-43B3-8D65-8BE1D4C600D8@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

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 04:48:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC