Re: Action-219: Draft Response to MSE on Bug 23661

Comments inline..

On Thu, Dec 12, 2013 at 10:28 AM, Paul Cotton <Paul.Cotton@microsoft.com>wrote:

>  See the extract from the A11Y TF IRC log below in which I made some of
> the points in your response during the A11Y TF discussion this morning:
>
> http://www.w3.org/2013/12/12-html-a11y-irc
>

Thanks. I appreciate this.


>
>
> > Does HTML5 have a similar note?
>
>
>
> The TF plans to open a bug on HTML5 to cause this to happen.
>

Ok. That seems like the proper path forward to me.


>
>
> > I object to adding this note to the MSE spec. This is an attempt to
> give weight to an accessiblity issue that should be solved by the spec that
> defines HTMLMediaElement behavior (ie HTML5 & HTML.next) and not an
> extension spec that is simply providing an alternate way to supply media to
> the HTMLMediaElement.
>
>
>
> Without arguing for the TF’s request I do want to point out they are only
> asking for the addition of a non-normative Note.
>

I understand, but I don't think we need to add an informative note in MSE
indicating how multiple tracks would be useful. In my opinion this is a
quality of implementation issue and if implementations want to make MSE
content accessible then they will support more than the minimal
requirements.

I think people are reading too much into the 1 audio track and 1 video
track requirements. The primary purpose of these 2 bullet points were to
make sure that both "multiple tracks per SourceBuffer" and "multiple
SourceBuffers with a single track" must be supported by implementations.
The 1 track requirement is simply a reflection of the fact that many
devices will only be able to support these 2 configurations. Obviously if a
UA was able to support sign language video tracks, then they would go
beyond the minimal requirements.

Aaron


>
>
> /paulc
>
>
>
> Paul Cotton, Microsoft Canada
>
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
>
>
>
> 16:34:20 [chaals]
>
> s/Topic: ARIA/Topic: Outstanding ARIA bugs on HTML 5
>
> 16:35:14 [chaals]
>
> JS: Anyone got comments re bug 19277?
>
> 16:35:42 [chaals]
>
> zakim, next item
>
> 16:35:42 [Zakim]
>
> agendum 6. "MSE Response
> http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0051.html"
> taken up [from janina]
>
> 16:35:50 [chaals]
>
> Topic: MSE response
>
> 16:36:17 [chaals]
>
> JS: Shortly trying to go to CR. I got suggested language out, and we have
> a CfC to check that we are happy with that.
>
> 16:36:19 [chaals]
>
> q+
>
> 16:36:30 [janina]
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0051.html
>
> 16:36:44 [chaals]
>
> s/http/-> http/
>
> 16:36:47 [plh]
>
> q+ plh
>
> 16:37:06 [chaals]
>
> s/html/html Janina's proposal/
>
> 16:37:20 [Zakim]
>
> -Cynthia_Shelly
>
> 16:37:22 [chaals]
>
> PLH: What is your expectation regarding timing and the outcome?
>
> 16:38:17 [paulc]
>
> q+
>
> 16:38:37 [plh]
>
> ack chaals
>
> 16:38:37 [paulc]
>
> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661#c2
>
> 16:38:40 [plh]
>
> ack plh
>
> 16:38:44 [plh]
>
> ack paul
>
> 16:39:26 [chaals]
>
> CMN: Timing is intended to allow us to request an editorial change, as the
> resolution of our comment.
>
> 16:39:39 [chaals]
>
> PC: Why make the comment on MSE not HTML5?
>
> 16:40:06 [chaals]
>
> CMN: Because in MSE it explicitly talks about 1 and we want to make it
> clear there are important accessibility cases for allowing more than 1
> video track.
>
> 16:40:23 [chaals]
>
> JS: MSE talks about audio tracks, but only 1 track.
>
> 16:40:24 [chaals]
>
> q+
>
> 16:40:41 [chaals]
>
> PC: The comment notes that HTML5 doesn't define the use case and it should
> be defined there first.
>
> 16:40:50 [chaals]
>
> s/comment/comment on the bug/
>
> 16:41:02 [paulc]
>
> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661#c2
>
> 16:42:12 [chaals]
>
> CMN: Fully agree that this should be done for HTML5 as well, but it seems
> that there is greater urgency for MSE.
>
> 16:42:32 [chaals]
>
> PC: Concerned that there will be pushback from the editors.
>
> 16:44:49 [chaals]
>
> CMN: Sure. We have attempted to provide a rational compromise, allowing
> MSE to go ahead of HTML5 - and not add formal requirements that makes
> people's lives harder.
>
> 16:45:18 [chaals]
>
> PC: I am concerned that the MSE task force will suggest we are targeting
> the wrong place.
>
> 16:45:25 [chaals]
>
> q+
>
> 16:45:44 [chaals]
>
> JS: We are only asking for an informative note - there is no request here
> fora formal requirement.
>
> 16:45:59 [chaals]
>
> PC: OK, I'll try to make sure the MSE task force gets that.
>
> 16:46:27 [janina]
>
> q?
>
> 16:46:27 [chaals]
>
> ACTION: chaals to raise a bug on HTML5 to clarify that sign language
> videos are an important accessibility use case for multiple video tracks.
>
> 16:46:28 [trackbot]
>
> Created ACTION-221 - Raise a bug on html5 to clarify that sign language
> videos are an important accessibility use case for multiple video tracks.
> [on Charles McCathie Nevile - due 2013-12-19].
>
> 16:46:54 [chaals]
>
> PC: How will this get communicated?
>
> 16:46:58 [Zakim]
>
> +Cynthia_Shelly
>
> 16:47:38 [Zakim]
>
> -chaals
>
> 16:47:56 [chaals]
>
> JS: The A11y TF has started a CfC that will resolve Tuesday (meeting
> process requirements but shorter than desirable)
>
> 16:48:01 [Zakim]
>
> +[IPcaller]
>
> 16:49:38 [MarkS]
>
> zakim, [IP is chaals
>
> 16:49:38 [Zakim]
>
> +chaals; got it
>
> 16:49:51 [chaals]
>
> CMN: I'll communicate the results as soon as our CfC closes, and will add
> a comment to the bug. I also took an action to raise a parallel issue on
> HTML5
>
> 16:50:29 [chaals]
>
> PC: MSE meets before the CfC closes, and may make decisions without taking
> teh result in account.
>
> 16:50:41 [chaals]
>
> PLH: @@@ 1 implementation
>
> 16:50:59 [chaals]
>
> JS: Sure, we need more implementations. But not all for a primary media
> resource.
>
> 16:51:35 [chaals]
>
> q+
>
> 16:52:13 [plh]
>
> s/@@@ 1 implementation/As I as I know, we only have only implementation of
> mediaGroup, so multi tracks support might be an issue in 2014/
>
> 16:52:56 [chaals]
>
> CMN: Sure. There are at least 2 implementations being built in Australia,
> one by AccessibleOz and one by the Australian Government.
>
> 16:53:17 [chaals]
>
> ST: In terms of looking for implementations are you also looking for
> content examples?
>
> 16:53:21 [chaals]
>
> [YES PLEASE]
>
> 16:53:53 [chaals]
>
> zakim, next item
>
> 16:53:53 [Zakim]
>
> I see a speaker queue remaining and respectfully decline to close this
> agendum, chaals
>
> 16:53:57 [chaals]
>
> q-
>
>
>
> *From:* Aaron Colwell [mailto:acolwell@google.com]
> *Sent:* Thursday, December 12, 2013 12:50 PM
> *To:* Paul Cotton
> *Cc:* Adrian Bateman; Mark Watson; public-html-media@w3.org
> *Subject:* Re: Action-219: Draft Response to MSE on Bug 23661
>
>
>
> Does HTML5 have a similar note? I feel like this is unfair to force MSE to
> include this if HTML5 does not already satisfy this and have a solution for
> these use cases. The extensions to AudioTrack and VideoTrack have nothing
> to do with enabling accessability. They were added to allow kind
> information present in a DASH manifest to be reflected by these objects in
> the case where the kind information was not present in the initialization
> segments. It is not intended to add extra functionality aside from allowing
> the string returned from the kind attribute to be changed programatically.
>
>
>
> I object to adding this note to the MSE spec. This is an attempt to give
> weight to an accessiblity issue that should be solved by the spec that
> defines HTMLMediaElement behavior (ie HTML5 & HTML.next) and not an
> extension spec that is simply providing an alternate way to supply media to
> the HTMLMediaElement. MSE allows multiple tracks to be supported and simply
> hooks into whatever multi-track functionality that is specified in HTML5. I
> don't believe MSE should be in the business of specifying/requiring extra
> multi-track behavior.
>
>
>
> Aaron
>
>
>
>
>
> On Thu, Dec 12, 2013 at 8:54 AM, Paul Cotton <Paul.Cotton@microsoft.com>
> wrote:
>
> FYI.    The original message on the A11Y TF list is:
> http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0051.html
>
> Basically the A11Y TF would like the Media TF to consider adding a
> non-normative note to MSE to cover the use case described in Bug 23661.
>  Note that the TF is also working on opening a bug on HTML5 to ensure this
> item is covered there as well.
>
> I will add this item to the Media TF agenda for Tue Dec 17 but I encourage
> the Editors to review this item ASAP.
>
> /paulc
>
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
> -----Original Message-----
> From: Janina Sajka [mailto:janina@rednote.net]
> Sent: Wednesday, December 11, 2013 11:49 PM
> To: HTML Accessibility Task Force
> Subject: Action-219: Draft Response to MSE on Bug 23661
>
> Colleagues:
>
> Herewith, a proposed response to the HTML-WG's Media Task Force and our
> comments on their MSE specification as provided in Bug 23661:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661
>
> MSE Specification:
>
> https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source-cr.html
>
> The HTML-A11Y Task Force has previously discussed our willingness to
> accept the Media Task Force assertion (in response to Bug 23661) that the
> javascript approach detailed in the MSE specification is sufficient to meet
> accessibility requirements for alternative media, and especially for
> simultaneous video streams as is required to support Sign Language
> Translation
> http://www.w3.org/TR/media-accessibility-reqs/#sign-translation
>
> The HTML-A11Y Task Force believes it important, however, that the core
> technical specification implementing media support in HTML 5 explicitly
> acknowledge both the alternative media requirements and the sufficiency of
> its specification to successfully deploy multiple media streams, especially
> multiple video streams, to users who require alternative media.
>
> We propose, therefore, a brief note in the introductory section of the MSE
> specification stating:
>
>         "NOTE: This specification directly supports multiple tracks. It
>         explicitly extends the AudioTrack and VideoTrack interfaces to
>         allow programmatic control of track kind to enable ,a
>         href="http://www.w3.org/TR/media-accessibility-reqs/">Alternative
>         Media</a> scenarios, including simultaneous multiple video
>         tracks in support of <a
>         href="
> http://www.w3.org/TR/media-accessibility-reqs/#sign-translation">Sign
>         Language Translation video tracks</a>."
>
> The Task Force recalls that our requirements for alternative media support
> were conveyed to the wider HTML-WG in 2010:
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0327.html
>
> Janina
>
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                         sip:janina@asterisk.rednote.net
>                 Email:  janina@rednote.net
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,  Protocols & Formats     http://www.w3.org/wai/pf
>         Indie UI                        http://www.w3.org/WAI/IndieUI/
>
>
>