HTML Accessibility Task Force Teleconference

27 Apr 2011

See also: IRC log


John_Foliot, Janina, silvia, mark, Judy, Frank, +54558aaaa, Sean, Eric_Carlson


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






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


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.


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


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


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


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?


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

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/04/27 23:05:01 $

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/SF/SP/
Succeeded: s/JSD/JS/
Succeeded: s/DSAH/DASH/
Found Scribe: JF
Inferring ScribeNick: JF
Default Present: John_Foliot, Janina, silvia, mark, Judy, Frank, +54558aaaa, Sean, Eric_Carlson
Present: John_Foliot Janina silvia mark Judy Frank +54558aaaa Sean Eric_Carlson

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 27 Apr 2011
Guessing minutes URL: http://www.w3.org/2011/04/27-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]