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

Media Subteam Minutes for 18 April

From: Janina Sajka <janina@rednote.net>
Date: Mon, 18 Apr 2011 23:23:38 +0000
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20110418232338.GA10812@opera.rednote.net>
Minutes from the HTML-A11Y Task Force Media Subteam teleconference on 18 April are provided below in text. They're also available as hypertext at:



                                                           - DRAFT -

                                                       HTML-A11Y telecon

18 Apr 2011

   See also: IRC log


          janina, Sean, Bob_Lund, Eric_Carlson, Judy, Frank, silvia




     * Topics
     * Summary of Action Items

   <scribe> agenda: this

   Janina reports no complaint to our desire to restore sourcing text tracks of any media type. These were unintentionally
   removed when WebSRT was removed from the spec. We will have a change proposal to restore this week.

   <scribe> scribe: janina

   Sean: We seem to be on track coalescing on #4 with the changes we need. Not all points clear yet, though.

   <judy> here is the link from the start of silvia's post summarizing status of issue 132

   <judy> http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0142.html

   Bob: I think it's important that we have simoultaneous video, though understand we may not want it in a single
   ... So multiple video tags?

   Eric: Definitely possible. Seems a silly prescription though, if a user agent can support multiple videos in a single
   ... Doesn't seem important to push just because Safari can.

   Bob: So, if multiple video tracks in an inband, it's not clear to me how to display that.

   Eric: You cannot do a single element. You need multiple elements and to use media fragments

   Sean: We need to be able to discover how video is laid out, and we don't have that yet as far as I know.

   Eric: Definitely the case

   Sean: Are these always rectangular? Or can we have a traveling mat?
   ... If we eventually want to support alpha blending, then we need to add that to css or adopt what video support has.

   Eric: Can do with fragment urls, but there's a bigger issue. Not all compression support alpha.
   ... So not something we can rely on CSS for, as it depends on compression.

   <Sean> Its not an issue then to only have one video per element

   <Sean> because transparency and composition of fragments should work

   Eric: Looking through last week's minutes, we didn't follow up whether Bob had any issues?

   Bob: Don't think so, a question, though ...
   ... So a separate video element for multiple tracks, that's OK
   ... What about the case where there's not ml and we want to discover via js

   Eric: Not currently at a computer, but there's an attrib 'exclusive' and believe you'd use that
   ... That doesn't provide size or positioning

   Sean: Also not sure media fragment can be constructed sufficiently from that data ...

   Eric: Using index?

   Sean: Not sure. Don't know fragment syntax sufficiently

   Eric: You might be right. There may not be sufficient data.

   Judy: Can we take up a tangent for the moment?
   ... I'm trying to map our recent discussion against various usre requirements ...
   ... Thinking of a video with audio content that's captioned, but also there's a sign translation stream
   ... Covered, yes?

   Sean: Yes, covered. The ml will be multiple elements, but these can come from a single resource.

   Judy: OK, thanks.
   ... I know some people following our discussion, who aren't directly participating in it, have been confused about

   Sean: Yes, that's what I was getting at earlier--the picture in picture overlay for the signing track.

   Judy: Also, one other ...

   <Sean> Silvia are you joining by phone?

   Judy: So my other question, how do we allow for someone who may need text descriptions?

   Sean: We think the transcript may be best for deaf-blind user. But, if needed with the same timing, then you'd have a
   text description track and a text caption track, both enabled.
   ... Reviewing for Silvia, is there enough data to create media fragment URI via js

   Eric: From single video element

   Sean: So, if you want to play two, where you don't know them in advance, is there enough info in the 'exclusive'
   attribute to create the URI?

   Silvia: Checking ...

   Eric: Index won't work, because don't know whether there are other tracks

   Silvia: For fragment we need the name which is available via audio tracks list or video tracks list

   Eric: Name is required? Not every track will have a way to list, nor are they necessarily unique.

   Silvia: That's why I was asking for ID

   Eric: Both mp4 and qt tracks guaranteed to have unique ID

   Sean: And that ID can be used to construct the fragment URI?

   Silvia: Yes.
   ... For slave tracks--which won't have more than one ID
   ... So a video with multiple audio dubs, we'd need also to look at getkind and getlang. From these you can decide and
   do getid

   Eric: Why create different elements for inband audio?

   Silvia: Just making something up where more info would be necessary.

   Sean: Think one more would be needed, as elements aren't exclusive. To swithc on/off, would need to be in a slave
   element, no?
   ... Can you switch on a subset? Or is it all or nothing?

   Silvia: You can switch on a subset with fragments?

   Sean: Mean js
   ... So, can just switch on/;'off tracks

   Silvia: Yes
   ... Yes also to retrieving data for fragments.

   janina and judy expressing happiness at better multilingual support for pwds.

   Eric: Any reply on the changes we need to your email, Silvia?

   Silvia: Still hoping we get a positive response.
   ... Philip's reply had some thing about track list for Eric? May be what Ian is waiting on.

   Eric: Safari won't stand in the way--we want interoperable behavior.

   Silvia: Would be good for you to reply on that.
   ... What's the opinion on loop and autoplay.

   Sean: Autoplay should go away.

   Eric: Strongly disagree. If not attrib, then will always be done from js

   Frank: Rationale?

   Sean: To not bombard the user, if there were a way to querry ua in script.
   ... It's dangerous unless ua can reliablbly disable autoplay.

   Silvia: Should be setable in ua a11y settings.

   judy: Not sure that disabling it everywhere is the optimal solution.

   Sean: Mechanism for switching play from script would be the same.
   ... Not sure the suggested solution works.

   Silvia: So, step by step ...
   ... Think it's good to have an autplay attrib as it encourages its use rather than using js to achieve the same result,
   ... Provides a mechanism for AT/UA to turn the behavior off.
   ... So we should also have this on the combined multitrack element.
   ... Suggesting the union be the state. So, if one slaves has autoplay, all slaves will be on autoplay. Though we could
   do the opposite?

   Sean: Not given this sufficient thought yet to know the best approach.
   ... Presumably autoplay is honored only if element is selected
   ... Need to think through all the issues.
   ... Wondering if all shouldn't be the preferred way.

   Silvia: Yes, that's the alternative but more problematical for authoring.
   ... Autoplay only affects the beginning of presentation.
   ... Suggests another issue, though, where someone constructs a js where some autplay, and others don't
   ... Seems we need to address this thoroughly and resolve correct behavior.

   Sean: Controller hasn't an autoplay; but autoplay on elements sets controller to playing--or not. So the last one
   creates the actual condition.

   SSean: only the element that creates the controller can determin play or not

   Silvia: Suggest more discussion on list

   Eric: Not sure--need also ml

   Sean: This is how I understand the proposal.

   Silvia: Yes
   ... Different behavior for stand alone and combined

   Sean: Dangerous

   Eric: Just because first element--with autoplay on--insufficient to play if others not sufficiently loaded

   Sean: Yes, but that is the decision point

   Eric: Yes, we need to hash this out better

   Silvia: Reading from spec on if blocked condition ....

   [general agreement to add need to control autoplay to Sec 4.1 of our User Requirements]

   Silvia: And looping?

   Sean: Think it's the same issue
   ... Looking at it, I don't think autoplay works as currently spec'd

   Janina: Concerned about Easter related hollidays?

   Sean: I'm out Thursday through Monday

   Silvia: I'll be working through

   <judy> [judy was asking about tonight as well]

   Discussion of ready state

   Silvia: Also a question if it exposes too much of inner workings
   ... Each browser may have different state with the same amount of loaded data

   Eric: Events are not consistent across browsers
   ... If a script doesn't register before event is fired, there's no way to determine whether it should play or not

   Silvia: Isn't 'canplay' telling that

   [general agreement we want ready state]

   Eric: Controller firing events on state very important

   Frank Concur

   Frank: Similar behavior as possible is a good idea

   Sean: No problem in principle, but perhaps in implementation ...

   Eric: Minimum value

   Sean: Always incrementing?

   Eric: Can go backwards

   Silvia: But not hard to calculate minimum
   ... Simple for browser, not easy for js developer

   Sean: And, if you don't have it, you're in worse shape because you have to listen to all events

   Eric: Fundamentally, one never knows, but it is much less work and very convenient to have the events and states

   Silvia: I don't have additional issues--nothing new today except autoplay
   ... Will post, please all contribute to the discussion

   Sean: If Ian's proposal not modified by deadline, we still have jultiple proposals

   Eric: If we don't agree with his version, whether modified or not, we create a CP against it

Summary of Action Items

   [End of minutes]


Janina Sajka,	Phone:	+1.443.300.2200

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Received on Monday, 18 April 2011 23:24:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC