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=12544http://www.w3.org/Bugs/Public/show_bug.cgi?id=12545http://www.w3.org/Bugs/Public/show_bug.cgi?id=12546http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547http://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]