- 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