W3C home > Mailing lists > Public > public-html-a11y@w3.org > November 2010

[Minutes] HTML-A11Y media sub-team telecon Nov. 10, 2010

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>
Message-ID: <025a01cb81ee$520c79e0$f6256da0$@edu>
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:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:23 GMT