Minutes from the Media sub wg call at 2200 UTC on 21 July 2010.

Hi All,

Minutes from this call are now available at:
http://www.w3.org/2010/07/21-html-a11y-minutes.html

A text version of the minutes follows:

Attendees

Present
Janina, Judy, sean, John_Foliot, Eric, Kenny_Johar

Regrets

Chair
John

Scribe
janina

<scribe> scribe: janina

<JF> 
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0047.html

OK

jf: Checking in on User Requirements edits due this week ...

<Judy> sean: some connectivity problems here, still trying to wrap up w/ Sylvia

<JF> 
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0047.html

<JF> An API providing access to:

<JF> Stop/Start

<JF> Pause

<JF> Fast Forward and Rewind (time based)

<JF> time-scale modification control

<JF> volume (for each available audio track)

<JF> pan location (for each available audio track)

<JF> pitch-shift control

<JF> audio filters

<JF> Next and Previous (structural navigation)

<JF> Granularity Adjustment Control (Structural Navigation)

<JF> Viewport content selection, on screen location and sizing control

<JF> Font selection, foreground/background color, bold, etc configuration/selection

<JF> Extended descriptions and extended captions configuration/control

<JF> Ancillary content configuration/control

<Judy> Eric: would be nice to have in media player, but unlikely to happen w/out a requirement like this

<Judy> ...there will continue to be volume control on media element

<Judy> John: need sep vol and orientation widget on each ... element as well

<Judy> Janina: yup

<Judy> john: indep streams nd indep controls

<Judy> eric: unrealistic expect api w undefined limits

<Judy> ...expose diff api for balance, unrealistic

<Judy> sean: why.

<Judy> eric: nd to define api.

<Judy> ...design api that defs how you set the bal.

<Judy> sean: just a bunch of interfaces, query what's avail

<Judy> eric: diff api for stereo, 7.1, something other

<Judy> sean: stereo common element?

<Judy> john: sure

<Judy> ...baseline api -- may be stereo

<Judy> janina: you're missing the point, you need a common api

<Judy> eric: yes

<Judy> janina: we don't dev, we id the gaps

<Judy> ...it's the wgs right to take up question first (of how to address the issues we've id'd)

<Judy> janina: time-scale modification

<Judy> [janina gives graphic audio examples of time-scale mod vs pitch control]

<Judy> sean: break up sound into spectral bands

<Judy> eric: where UA sits in stack

<Judy> ...no access to that level in safari

<Judy> janina: may drop this requ at this level

<Judy> janina: your hearing aid may do this for you

<kenny_j> I can take a shot Judy.

<Judy> john: shift,control etc, post-production process... control switch for audio track

<Judy> eric: we're all in violent agreement

<kenny_j> jf: a tool outside the browser could manage the audio filtering.

<kenny_j> jf: moving on to next and previous, and granularity control.

<kenny_j> jf: Last week, we were talking about a document that would contain timescale information for all media assets.

<kenny_j> eric: As soon as the orthogonal resources have a different time scale than the primary resource, we can't manage without a document that manages
the time scale across the media asset.

<kenny_j> Judy: If the media sub wg identifies that extra work needs to be done to get media accessibility right by the last call stage, extra resources
can be mobilised.

<kenny_j> judy: I don't want us to be constrained by resource availability. Extra resources can be mobilised.

<kenny_j> jf: Does the daisy concept of a director solve this problem?

<kenny_j> Janina: There's not one way to do it in the technology available right now.

<kenny_j> janina: there are several ways of doing this.

<kenny_j> eric: we need to come up with a solution that we are confident that we can implement in an interoperable and robust way.

<kenny_j> eric: An edge case like extended audio will add a lot of complexity to implementation.

<kenny_j> judy: I support an exploration of prioritisation of requirements.

<Judy> ...but want to make sure that we select a model that encompasses the requirements range that we will need to support.

<kenny_j> jf: We have already captured some key requirements. This particular requirement seems to be the most major one.

<kenny_j> janina: is there a question around granularity adjustment?

<kenny_j> eric: I think I have a good handle on it. A granularity control presupposes that a common structure is available.

<kenny_j> Janina: yes.

<kenny_j> jf: moving on to content selection ...

<kenny_j> sean: there is author level styling, then producer level styling that overwrites it.

<kenny_j> sean: my concern with css is cross domain issues.

<kenny_j> jf: I am hearing that this is technically not going to be very complex.

<kenny_j> eric: There will be issues such as the children of an element are rendered inside the bounds of a parent.

<kenny_j> Janina: I think we are assuming that things like sign language tracks are not burnt into the primary resource.

<kenny_j> eric: people will do what they want to do.

<kenny_j> Janina: the benefits we offer may change that.

<kenny_j> jf: I think we are saying that we need a stylesheet of some sort. we are not defining the technical solution as yet though.

<kenny_j> jf: we need to allow users to do things like positioning text, foreground/background color ...

<kenny_j> eric: Somethings may be quite complex to implement e.g. moving a video around the page; issues such as other elements rescaling ...

<kenny_j> Eric: there is no document anywhere that sayys that a user should be able to restyle an image.

<kenny_j> eric: I think this is the first time that there will be a document that will say that a user needs to be able to restyle an image ...

<kenny_j> judy: I am hoping that our definition of the requirements in this sub wg will impact some of the push back on the patterns and scenarios identified
in these requirements.

<kenny_j> jf: we absolutely should enable end users to enlarge text and images, modify foreground/background colors ...

<kenny_j> eric: the point that I am trying to make is that enabling thinngs like this will cause issues as these have not been done before.

<kenny_j> judy: there will be areas where there are performance tradeoffs. having the discussions will help us figure out things that are tricky for the
users, and we should be able to find expedient solutions from there.

<kenny_j> eric: temporal content may be quite challenging too.

<kenny_j> jf: Moving on to extended descriptions.

<kenny_j> janina: What we are saying here is that the user should have realtime control over things like extended descriptions e.g. primary resource pausing
when extended descriptions are played ...

<kenny_j> janina: The question is about the handling of ancillary content by users.

<kenny_j> jf: moving on to 3.8

<kenny_j> janina: there is now increasing capability in operating systems to control resources across lans, wans...

<kenny_j> janina: I am thinnking about one user with availability of multiple things.

<kenny_j> janina: I want to be able to choose audio descriptions from other ancillary content available.

<kenny_j> janina: I want the audio descriptions to be able to be routable to headphones ...

<kenny_j> eric: do you expect this to be in the browser?

<kenny_j> sean: one idea was to have multiple browser windows showing different screens.

<kenny_j> janina: the browser could interface with the operating system and offer the user a choice from the devices supported by the operating system.

<kenny_j> eric: this is very complicated to do in an api.

<kenny_j> judy: One of the approaches that the w3c and other entities have come up with is generic apis + apis specific to operating systems to support
such requirements.

<kenny_j> eric: even doing a high level api is going to be very complex.

<kenny_j> eric: implementing this in platforms like webkit may be difficult but still possible; its going to be very onerous for custom control authors.

<kenny_j> judy: How about providing an outline of the issues that will be encountered in different platforms when implementing such a requirement.

<kenny_j> eric: it would take someone with knowledge of hardware.

<kenny_j> judy: we might like to divide the work required into stages.

<kenny_j> judy: by last call we could define problems that would need to be solved by cr.

<kenny_j> eric: I don't thinkk this issue is important enough to consume a lot of resources when there are other issues on the bench.

<kenny_j> judy: We are making good progress. We should capture the priority questions on the wiki. this will help us figure out the time frames that need
to be dedicated to each of the issues.

<kenny_j> judy: Many of the things we have talked about have not been technically commplicated.

<kenny_j> judy: we could spend our time further exploring the priority of the most difficult issues.

<kenny_j> eric: difficulty means different things to different people.

<kenny_j> eric: Several browser vendors have stated on the list that synchronising two streams is onerous.

<kenny_j> eric: we should take that into consideration.

<kenny_j> judy: We could pull in a couple of resources to deal with the difficult issues.

<kenny_j> jf: I think we should identify some clear next steps and milestones.

<kenny_j> jf: do we need a technnical requirements document?

<kenny_j> judy: We need all the three steps that were defined, and a 48 hour period for folks to look at it.

<kenny_j> jf: I have had problems logging on to the wiki yesterday. can get our stuff done by tomorrow morning after the task force call.

<JF> is silvia on IRC right now?

<kenny_j> sean: I am not going to have any internet connectivity, so I can't get the summaries done.

<kenny_j> judy: I will touch base with silvia about this.

<kenny_j> jf: We need to decide an approach forward for user reqs/technical reqs in the wiki.

<kenny_j> eric: I see Janina's technical implications as a clarification of the user reqs and not the technical reqs.

<kenny_j> jf: I think we are all on the same page on what we need, and what we need to do. should we go to the larger group now on technical reqs.

<kenny_j> judy: We need to continue to give the larger group information on our next steps.

<kenny_j> Judy: We can offer them a stable set of user reqs by monday afternoon.

<kenny_j> Judy: It would take another few weeks to go through the associated technical issues.

<kenny_j> Judy: In a couple of weeks we should have a reasonable idea on the scope of work.

<kenny_j> judy: janina had another point which placed technical questions in the hands of the larger group for them to resolve.

<kenny_j> jf: By monday, we will finalise the user reqs. what are the next steps after.

<kenny_j> judy: I would expect that we would keep making progress that would require weekly meetings.

<kenny_j> judy: janina and I want to have a short meeting with you after the call John.