[media] Minutes - sub-team conference call 27 April 2011

All, 

Please find the HTML version of today's Media sub-team teleconference at:
http://www.w3.org/2011/04/27-html-a11y-minutes.html 

Or as plain text below:

*****************

HTML Accessibility Task Force Teleconference
27 Apr 2011

See also: IRC log
Attendees
Present
John_Foliot, Janina, silvia, mark, Judy, Frank, +54558aaaa, Sean,
Eric_Carlson
Regrets
Chair
SV_MEETING_CHAIR
Scribe
JF
Contents
Topics 
Identify Scribe
Summary of Action Items



<trackbot> Date: 27 April 2011

<silvia> :)
Identify Scribe

<scribe> scribe: JF

<Sean> its telling me its not valid

JS: thinks we should have a post-mortem on issue 152, what happened and
where are we now?
... believe we are still on track...

SP: the chairs decided what we were trying to do was not possible based on
WG rules

everyone else pulled back their change proposals

so that ian's work moved forward uncontested

and now we even have some of the bugs resolved

JS: does anyone have anything to add to that?

JB: were we not at some point relying on ian's proposal?

JS: maybe that would be an introduction to where we are now?

EC: what happened was when we returned from F2F, ian had a CP. Based on
email with many, he incorporated those changes into WHAT WG

based on feedback, he was updating running spec at WHAT WG, but not his
original CP

thus his CP was out of date

so ian withdrew his CP, as did others, and so the WHAT WG text moved into
the W3C spec, and John added the 5 bugs against the revised W3C spec text

JB: thanks for the overview - added clarrity

we need to be careful on watching where text is evolving

with a goal to avoid this confusion again

MW: was watching process, and wanted to be sure his concerns were included
into one of the CP's

and what ended up was that was not what happened

conclusion - always have a valid Change proposal in hand

JB: this was unusual for w3C process

this was atypical

JS: many found this quite confusing

EC: to be fair, our problem was that we did not have a valid change
proposal

JB: that may be part of the problem/issue, but that was not 100% clear -
there was a missed understanding

the concensus process was lost

MW: the problem was there was no CP last Friday

SP: not unhappy with the process, we got what we needed, and the bugs are
being pursued. In essence we got what we needed

EC: Agree with Silvia - in the end we resolved a contentious issue by
amicable resolution

JS: generally good. So we now have those 5 bugs, some of which appear to
be resolved. Do we expect this all to be resolved before LC?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12544

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12545

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12546

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12548

JB, can we get a status check

Bug 12544 - MEDIA CONTROLLER requires track kind for in-band tracks

SP: this has been applied

we now have a get @kind function in the spec

MW: there remains an outstanding question about what @kind values can be
gotten back

how do we decide - not in concurrance with ian's perspective, woulod
prefer that W3C define the list

should be independant of the container formats

so there should be a single place where these are define

JS: the fact that they are marked resolved may not be sufficient for this
group
... what can be retrieved is more important than how for some

we should be looking to ensure that our concerns (user requirements) is
fully met

EC: I sympathize with both perspectives. None of the existing container
formats have support for most of these @kind values yet - they don't exist

defining them in W3C is an interesting thought exercise, but if they are
never implemented it is simply a thought exercise

MW: is a chicken and eg problem - do we wait for all the media formats to
define the same values with different meanings/names?

Seems a more productive way forward is to define a small number of values
so that others can reference

+q

MW: if we put the stake in the ground, we show leadership

JS: sounds like there is more discussion on this issue

SP: let's continuing discussing - this is something basically new

happy to continue the dialog

Bug 12545 - MEDIA CONTROLLER requires loop attribute for grouped
multitrack

SP: both Philip and ian are asking for the use-case, and Eric and Silvia
are attempting to explain

both ian and Philip believe there is another way forward, but silvia
believes is a dangerous way forward

but is not a deal-breaker. would like things to be consistent, but not a
do or die issue

Bug 12546 - MEDIA CONTROLLER requires autoplay attribute for grouped
multitrack

SP: ian is also asking for a use-case

discussion is happening, but this is not quite clear yet

perhpas the first implementation will help resolve this as well

doesn't believe this is a blocker, nor a fundemental a11y issue

EC: disagree that it is not a a11y issue

we *do* need to discuss this more, but email discussion to date is that
Eric was unclear on one aspect of the media controller API

believed that if 1 played, all played, so this might change things in the
discussion

JB: also believes that this is important for a11y

SP: maybe we need to put the a11y keyword to this bugs

Bug 12547 - MEDIA CONTROLLER requires readyState for grouped multitrack

SP: is a disucssion tath Eric should summeraize

EC: if we don't have it then a script has no way of determining a ready
state

eg; if you have a js controller that is attached after the group is
created, then there is no way of knowing what the state is

JS: sounds like it needs additional work

Bug 12548 - MEDIA CONTROLLER requires onended event

SP: believe this has been added

JS: so our change for 12548 has been accepted?

JF: status still reads new

JS: we should verify

<silvia> HTML5 spec has:

<silvia> A http://dev.w3.org/html5/spec/video.html#mediacontroller has a
most recently reported readiness state, which is a number from 0 to 4
derived from the numbers used for the
http://dev.w3.org/html5/spec/video.html#media-element readyStateattribute,
and a most recently reported playback state, which is either playing,
waiting, or ended.

http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0307.html

EEC: I think there may be an issue with the script thta pushes the SVN
text from one location to the other

JS: considering the other 4, where do we start?

suspect mark would like to go back to the @kind discussion

<silvia> http://dev.w3.org/html5/spec/video.html#dom-tracklist-getkind

EC: also have a proposal on how to handle that issue
... it is useful for us to come up with a list of the @kind values, but we
need to go further and ensure that those @kinds are added to the container
formats

silvia can do this for OGG, David Singer can likely do for MP4

this is likely the right way forward

MW: this would be great

if we write down a list then 3gpp and mpeg will reference that list as
well

SP: Ogg already has a list

ian based upon what OGG already had defined, but understand that MPEG has
some definitions from DASH

<silvia> http://wiki.xiph.org/SkeletonHeaders#Role <- ogg's list

but 3gpp is waiting on W3C

SP: full list from OGG

but may not have everything that 3gpp are expecting

EC: seems that these groups are all waiting to hear what we propose
... we should add a section to the reference documents

MW: is this a normative document?

JB: not sure

seems this should be a normative reference from elsewhere, not internal to
HTML5

JB: a PFWG might be the place to do this - would need a minor charter mod
for that

SP: we should agree/assure that this can be modified in the future

+Q

since it is just a string

might see new values emerge over time

wouldn't want to see a fintie list

MW: for clarification - in external discussions 3gpp and MPEG DASH are not
interested in defining these values

they are waiting for W3C to define the URN for the track kinds

just like has already been done for text @kinds - why is this any
different?

SP: from OGG's container format, they are all the same

EC: seems that having the definition in the HTML spec is a bit backwards -
these are not specific to html

MW: not specific to media container formats as well

EC: my point exactly

SH: We can create a wiki like the microformats did

JB: another approach would be to define a collection of these and post
them at W3C.

SH: wanted to make the point that whether wikis are an issue or not, the
chairs have already made the decision that the spec can reference wikis

so if it is a problem for our list, then it would be a problem for other
lists as well

MW: this is not specific to html, even less for container formats

however anyone writing html will want to know what these values are

so there is an html need to define this

EC: don't disagree that the spec needs to define the labels, but the list
and definitions need to come from somewher else

JS: do we agree that a canonical list needs to be defined, and that W3c is
the place that this should happen?

(appears there is no disagreement)

Is there also consensus that the html5 spec is not the right place for
this document?

SP: not necessary a good approach

this should be in one place

+q

SP: what html does is places a normative list in the spec

but other groups would need to replicate this list

but they shouldn't be restricted by an html list

JF: disagrees with Silvia's proposal - should be in one location so that
all ca nreferrence one document

JB: this might take too long for HTML5's timeline

SP: doesn't fundmentally disagree with JF, but container formats may need
more than HTML5 requires

JS:

on the list of what a container can do, we can suggest that this list is a
set of know values that container should support

but we should not lock it down

however if there are new requirments, there are W3c processes for adding
to canonical requirements

JS: comment 2 - why not let w3C figure out where and how to register these
values. Our groups purpose could be to come up with an initial list, and
not worry exactly where to house that list

MW: nobody is suggesting that container formats be constrained by this

MPEG has defined a flexible method for defining an URN for specific set of
values

there appears to be a small set of use-case now

that could be used in multiple use-case

JS: so, are we in agreement that a) W3C should define the canonical list,
b) that W3C figure out where this would happen and live?

<mark> http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds

JB: how much of this specifically is related to a11y and not a larger
container format issue? If it is primarily for a11y use then it may change
the quesstion

JS: there seems to be a fair bit of a11y and i18n issues

EC: there *Is* a need for a list of a11y terms

and it should be in a document that comes from thta group. but in HTML5
the labels can apply to those terms. in the container format, it is those
terms that get mapped to the container formats

so the canonical definition should be what a11y NEEDS

JB: so this makes it appear that this is PF territory

SP: looking at mark's list, there are 2 or 3 that would make sense to add

supplementary, commentary, and clear audio

SP; as eric suggests, we should focus on the a11y reqs here. David singer
also had some suggestions

MW: to add one to that list, there are situations where the only place to
get captions is when they are burned into the video itself

so it would be nice to be able to label the video with captions/subtitles
there

SP: would that actually be supplied as a seperate track in the resource,
or is it simply a description of what is already burned into the video
file

is @kind then the correct way to define/describe this/

MW: what we have today is some instances with caption burned into the
video

JS: this is going to exist for smoe time due to legacy content

MW: if we can extract that in any way, then we would extract the text and
store it seperately

or offer 2 versions of video, one with burned in, one without (Mark is
this correct?)

SP: agree, to offer this to the end user as an undefined alternative

MW: there is a usecase for machine understandable extraction however

for example, always show captions

EC: agree 100% - the right thing is that to have an @kind that says there
are captions

if it is applied to an audio track, then it is an error, but if it is
included then it is up to the user-agents to intelligently do something
with this

so a new label for 'captions' for burned in captions

MW: there appears to already be some duplication from different groups. if
everyone agrees we can narrow down to one term and common definitions

SP: suggestion - make 2 tables: one like you have, and then a second that
contains the ones we have agreed to

MW: OK, agrees to that
... do we assume that the initial five values have agreement?

JB: in the status section, in addition to reflecting what is in the page,
might be useful to also show who is involved in the current discussion

JS: 2 questions - we are looking here only at binary formats? is this
correct?

(yes)

<mark> I added "This page is a work-in-progress and is being actively
studied by the HTML a11y working group"

we were trying to be very careful of terms - so it should be audio
description, not video description

SP: 'description' is in the spec.

JS: there is some confusion, and in the user reqs we took pains to
delineate the difference between binary descriptions and text descriptions

as long as the taxonomy is clear and precise

JF: is description for both audio and text be a problem?

MW: we need to define needs and then word terms

as I undertand in the spec, there is a list of names, but with no
definition

JS: we do need to do that, to define the terms. this is why we were very
careful with the usage of names

SP: it is the mime type that does the definition

so the generic term of description makes more sense, as it is the @type
that defines the type of @kind resource

SJ: go around the table for the values to take consensus

so on initial five: alternative, description, main, sign, translation -
are there any concerns here?

JF: are there any disagreements that those 5 values required for a11y

JS: there was some discussion earlier about defining "main" versus
"primary"

JF: propose we continue on this discussion on the mailing list

JS: do we want to continue with 2 calls a week?

(we will remain with once-weekly calls)

JS: are there any other hightlihgs on the reamins bugs that we should be
discussin today?
... thanks for the good work - it appears we are actually in a good way
despite last weeks confusion

next call is next wednesday
Summary of Action Items
[End of minutes]

Received on Wednesday, 27 April 2011 23:20:50 UTC