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

<janina> scribeNick: janina

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

<scribe> scribeNick: 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

Eric: would be nice to have in media player, but unlikely to happen w/out a requirement like this
... there will continue to be volume control on media element

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

Janina: yup

john: indep streams nd indep controls

eric: unrealistic expect api w undefined limits
... expose diff api for balance, unrealistic

sean: why.

eric: nd to define api.
... design api that defs how you set the bal.

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

eric: diff api for stereo, 7.1, something other

sean: stereo common element?

john: sure
... baseline api -- may be stereo

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

eric: yes

janina: we don't dev, we id the gaps
... it's the wgs right to take up question first (of how to address the issues we've id'd)
... time-scale modification

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

sean: break up sound into spectral bands

eric: where UA sits in stack
... no access to that level in safari

janina: may drop this requ at this level
... your hearing aid may do this for you

<kenny_j> I can take a shot Judy.

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

eric: we're all in violent agreement

<scribe> scribeNick: kenny_j

jf: a tool outside the browser could manage the audio filtering.
... moving on to next and previous, and granularity control.
... Last week, we were talking about a document that would contain timescale information for all media assets.

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.

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.
... I don't want us to be constrained by resource availability. Extra resources can be mobilised.

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

Janina: There's not one way to do it in the technology available right now.
... there are several ways of doing this.

eric: we need to come up with a solution that we are confident that we can implement in an interoperable and robust way.
... An edge case like extended audio will add a lot of complexity to implementation.

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.

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

janina: is there a question around granularity adjustment?

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

Janina: yes.

jf: moving on to content selection ...

sean: there is author level styling, then producer level styling that overwrites it.
... my concern with css is cross domain issues.

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

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

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

eric: people will do what they want to do.

Janina: the benefits we offer may change that.

jf: I think we are saying that we need a stylesheet of some sort. we are not defining the technical solution as yet though.
... we need to allow users to do things like positioning text, foreground/background color ...

eric: Somethings may be quite complex to implement e.g. moving a video around the page; issues such as other elements rescaling ...
... there is no document anywhere that sayys that a user should be able to restyle an image.
... 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 ...

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.

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

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.

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 should be able to find expedient solutions from there.

eric: temporal content may be quite challenging too.

jf: Moving on to extended descriptions.

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 ...
... The questions i is about the handling of ancillary content by users.

jf: moving on to 3.8

janina: there is now increasing capability in operating systems to control resources across lans, wans...
... I am thinnking about one user with availability of multiple things.
... I want to be able to choose audio descriptions from other ancillary content available.
... I want the audio descriptions to be able to be routable to headphones ...

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

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

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

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

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.

eric: even doing a high level api is going to be very complex.
... implementing this in platforms like webkit may be dificult but still possible; its going to be very onerous for custom control authors.

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

eric: it would take someone with knowledge of hardware.

judy: we might like to divide the work required into stages.
... by last call we could define problems that would need to be solved by cr.

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

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.
... Many of the things we have talked about have not been technically commplicated.
... we could spend our time further exploring the priority of the most dificult issues.

eric: dificulty means different things to different people.
... Several browser vendors have stated on the list that synchronising two streams is onerous.
... we should take that into consideration.

judy: We could pull in a couple of resources to deal with the dificult issues.

jf: I think we should identify some clear next steps and milestones.
... do we need a technnical requirements document?

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

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?

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

judy: I will touch base with silvia about this.

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

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

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.

judy: We need to continue to give the larger group information on our next steps.
... We can offer them a stable set of user reqs by monday afternoon.
... It would take another few weeks to go through the associated technical issues.
... In a couple of weeks we should have a reasonable idea on the scope of work.
... janina, had another point which placed technical questions in the hands of the larger group for them to resolve.

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

judy: I would expect that we would keep making proggress that would require weekly meetings.
... janina and I want to have a short meeting with you after the call John.