HTML-A11Y telecon

10 Nov 2010

See also: IRC log


Janina, Sean_Hayes, Eric_Carlson, John_Foliot, Judy, +61.2.801.2.aadd, silvia
John_Foliot, jf, John


<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 - 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

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


<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


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


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?


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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/11/11 00:41:55 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]