See also: IRC log
<janina> agenda: this
<janina> scribe: John_Foliot
<janina> scribe: jf
<scribe> scribe: JF
<janina> scribe: John
JS - suggest we skip over Action items so that we can focus on heavy agenda
JS - will be brief on status updates
TPAC was very eventful, managed to move things forward
key thing was thursday meeting on media
Frank categorized the requirements into 4 different buckets
many were UX issues
others related to 'tracks' - the time text format issue
perhaps spin that off to another WG
or handle seperately
despite wide concern of user reqs prior to TPAC, things seem to be less of a concern
categorization helped to defuse this
JF - is the splitting off of time text format a done deal?
JS- not yet, is a priority discussion for this group
Judy - had had several assurances that there would be no pre-empting of this discussion/decision
the discussion was about modularizing how a11y / media is handled
however the decision has not been made
JS- providing a wiki of the discussions at TPAC
subtext of meetings showed a stron affinity for webSRT
number of reasons why some don't like TTML (XML issues)
however we should still do the gap analysis
need to do this soon - within the next week or 3
JS - 2 key decisions - are we comfortable with splitting off the discussion on time formats, and logistics around gap analysis
<janina> http://www.w3.org/html/wg/wiki/Minuteszakim, next item
<janina> http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0066.html
JS - review Franks report
take on the bigger issue first - how do people feel about splitting the time text format into a seperate group
SH - thinks it is a good idea
believes that Frank agrees - so can be taken as MS position
EC - I think it is a good idea as well
JB - think it may be good for development of the issue
one of the tricky things is whether the media format that is tied to HTML5 does end up being specified as a full feature baseline
if we don't have that, there are multiple risks for accessibility
not sure if they have all been documented
when we built out the user reqs we didn't consider spliting out at that time
if media format changes over time, we may have discontinuity
may be very good to have the flexibility to recognize multiple formats, but if we have a baseline we need to have additional care/caution in doing that
Judy notes there was some discussion of 'plugins' at a lunch-table discussionat TPAC
however plugins don't scale well for many users with a11y needs
EC - not all browsers support the same plugins
we are already in a situation where we don't have baseline for video and audio files (codec issue)
SP - this shouldn't stop us for trying for a baseline format for the text formats
see this as a goal to arrive at a baseline format
EC - agrees as well
<judy_> [judy notes that doesn't think that modularizing is a problem by itself, but that it requires extra consideration for a number of interoperability issues]
JF +1
JB: agree that this is an issue, but can we get out of that "well"
there was general agreement that modularization is a good way forward
SH: has already found instances of <track> in the wild, and using JavaScript to process it
JB: can we continue to discuss this? need to have a better understanding of this. how does this handle the interop issues?
SH: haven't done extensive research, but from what have seen there is an ability to detect events in the video and associate it to timestamp file
relies on JS to do the processing
+q
<silvia> +q
SP: concerned that the track element alone is sufficient
if it can read the files, and expose the cues
plan is to go beyond libraries to do the track implementation
since the browser is the only thing that can do the time alignment properly
and it should be implemented in the browser
so having an abstract JS API is good, we really need a baseline format that all browsers support
JF: +1
JS: seems that it is important as it's not just captions, especially given some of the other user requirements
<judy_> john: i would like to see more stable and predictable behavior than just relying on the javascript library
SH: clarification - not saying that browsers shouldn't have native support, but simply that with JS today we can do most of it now
JB: suggest that if we give feedback to larger WG, that we also note that we will be wanting to lookl very carefully at the interop issues
that we believe that the track element handles a lot of it, but we want to ensure that interop is handled correctly
SP: thinks it is simple. we need a sentence in the track element that states this is the baseline format for text-time format
EC: clarification - the things that Sean is talking about works now
+q
JS: the concern is not how/where the baseline time format is defined, but how it is included in the HTML5 spec
JB: learned today that possibly PF would take on the time-format/WebSRT WG
thinks that even though there seems to be a inference that WebSRT will be the baseline format, need to confirm that
thinks that while PF is a good place for this to happen, PF is already overloaded
important to ensure charter is done right, so that right people are included, and that it is done in accordance with IP rules, etc.
JB: suggests that we try to go through the where and who questions before we tackle the 'what' but at the same time the gap analysis on WebSRT should start
(discussion on timelines)
JS: next question is, did Frank get the 'buckets' right - are there any questions/concerns
do we need more specificity re: chapters
do we need to tweak this document
JB: has everyone had a chance to read through Franks note
EC - did a fairly quick read, happy to see it happened - seemed good
JS: my sense is that it is generally right
but we should take the time to ensure it is right
http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0066.html
SP: a few questions - do we have bugs in the bugtracker for all of these issues
there were a few questions
<judy_> +1 to silvia's suggestion to be sure to capture the user &/or tech requirements that are indeed directly needed in the spec
<silvia> http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0080.html
asks that others review and comment on her email
JS: with panning - if there is stereo sound it is very important not to have the description in the same pan location
SP: thinks that this should be handled by the a11y API
as long as the descriptive track is a separate track, it becomes an OS/user agent issue
SP: might be able to remove it from the html5 spec and into the operating system spec
there will be a lot of things coming from this work that will need to be addressed in the a11y API moving forward
perhaps we should be capturing this as well
SP: suggest that Franks matrix supersedes the checklist. suggest that we include Franks data into the checklist, and remove the technology column
EC - agrees with silvia
JB: would like to ask a different question
we've talked about gap analysis, but is this on the agenda
JS: are we agree to remove the technology column and replace with Franks work?
(seems to have objections)
correction - *no* objections
<janina> resolved: We will remove the technology column in our matrix, replacing it with Frank's categorizations.
<janina> ACTION: Silvia to replace the technology column in our matrix with Frank's categorizations [recorded in http://www.w3.org/2010/11/10-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-76 - Replace the technology column in our matrix with Frank's categorizations [on Silvia Pfeiffer - due 2010-11-18].
SP: belives that this is an ongoing discussion on email
different ideas
SP: have been working on the gap analysis on WebSRT - may be able to present on this next week
JB: thinks that this is a very good idea
suggest that a qualitative factor be considered: not only what is the gap, but are there any issues that the architecture would not be able to support a particular requirement
(or complexity issue)
SP: can have that readyby next week
SH: has already done the gap analysis on TTML, can discuss next week
as well
JS: mindful that we are in a rush to get this done, but don't want to unduly restrict time/discussion
<judy_> +1 to an interleafed session
SP: suggests we do this as an interleaved way, requirement by requirement, so that we all arrive at the same understanding
+1 to ath
SH: likes this approach as well, but do we also want a brief overview of each format?
JB: 2 weeks from now is US thanksgiving
and concerned that we lose an opportunity
SP: if we move the call 2 hours earlier than it makes it easier on the europeans
JB: could we do this in 2 hours next week?
+q
SP: if we move the call forward 2 hours next week, can we perhaps do a "workshop"?
and then make it longer
JS: inclined to say that those on the call have first call on time
SH: agrees that if we have a larger workshop, we should do it separately from what we want to achieve next week
JB: 2 issues - extending next weeks call, and having a broader discussion
JS: proposal is thta we not meet in 2 weeks (US Thanksgiving eve)
(no objections)
JS: is there any objection to starting 2 hours earlier and extending beyond 90 minutes to try and go through the entire gab analysis?
JB: thinks this is very good idea, but may be late
JS: with no objections, will make those arrangements for next week
SH: moving the meeting an hour earlier would be better, but 2 hours forward (on a regular basis would be less preferable)
JS: next week we will move the meeting 2 hours earlier, then after US Thanksgiving we will resume our 90 minute meetings 1 hour earlier
JB: will work on getting Geoff on the call next week
SP: hopes everyone is good for next week
JF to take the Action assigned to Silvia
JS: thanks to all. meeting adjourned
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/has had several assurances that there was/had had several assurances that there would be/ Found Scribe: John_Foliot Found Scribe: jf Inferring ScribeNick: JF Found Scribe: JF Found Scribe: John Scribes: John_Foliot, jf, John Default Present: Janina, Sean_Hayes, Eric_Carlson, John_Foliot, Judy, +61.2.801.2.aadd, silvia Present: Janina Sean_Hayes Eric_Carlson John_Foliot Judy +61.2.801.2.aadd silvia Got date from IRC log name: 10 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/10-html-a11y-minutes.html People with action items: silvia WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]