- From: John Foliot <jfoliot@stanford.edu>
- Date: Thu, 11 Nov 2010 14:18:08 -0800 (PST)
- To: "'HTML WG'" <public-html@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
The HTML-A11Y Media Sub Team telecom minutes may be found at: http://www.w3.org/2010/11/10-html-a11y-minutes.html A transcript follows: **************** HTML-A11Y telecon 10 Nov 2010 See also: IRC log Attendees Present Janina, Sean_Hayes, Eric_Carlson, John_Foliot, Judy, +61.2.801.2.aadd, silvia Regrets Chair Janina_Sajka Scribe John_Foliot, jf, John Contents * Topics 1. Identify Scribe 2. Actions Review 3. Status Updates & Brief Reports: TPAC; User Reqs; 4. Categorization of Media A11y Requirements 5. Technical Requirements Prioritizations and Dependencies * Summary of Action Items <janina> agenda: this Identify Scribe <janina> scribe: John_Foliot <janina> scribe: jf <scribe> scribe: JF <janina> scribe: John Actions Review JS - suggest we skip over Action items so that we can focus on heavy agenda Status Updates & Brief Reports: TPAC; User Reqs; 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 - has had several assurances that there was 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 Categorization of Media A11y Requirements <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]. Technical Requirements Prioritizations and Dependencies 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 Summary of Action Items [NEW] 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] ============================ John Foliot Program Manager Stanford Online Accessibility Program http://soap.stanford.edu Stanford University Tel: 650-468-5785 Soap Is a program directed by the Vice Provost for Student Affairs ============================
Received on Thursday, 11 November 2010 22:18:43 UTC