[Minutes] HTML-A11Y Media Subteam Teleconference on 8 June


The Minutes from today's teleconference call can be found here:

...or in plain text immediately after this announcement. As is always the
case, corrections and comments should be posted to this list.



HTML Accessibility Task Force Teleconference
08 Jun 2011

See also: IRC log (http://www.w3.org/2011/06/08-html-a11y-irc) 
+1.650.468.aaaa, JF, +44.844.800.aabb, Sean, Janina, silvia, [Microsoft],
Judy, Michael_Cooper, Plh
Paused Media: Updates? Browser Support?
Hierarchical Navigation: Progress Checkin
Texted Descriptions: Requirements on A11y APIs
3GPP Request Followup
Summary of Action Items

<trackbot> Date: 08 June 2011

<scribe> Meeting: HTML-A11Y telecon

<scribe> Scribe: John_Foliot

<scribe> agenda: this
Paused Media: Updates? Browser Support?

JS: question is, has there been any discussion with implementors?
... are we looking at the right thing here, will we get browser support or
should we be looking at other solutions?

SP: Jonas is putting in a proposal w.r.t. @longdesc that will impact on

JS: that is related, but by itself will not do the whole thing

SP: if that is possible then it should do most of it

there was also the introduction of the idea of @transcript

waiting to hear of outcome of @longdesc discussion

JS: we should not be waiting on other decision to move on our work

(Discussion on the browser issue of a) concatenating multiple
aria-describedby values, and b0 flattening of markup

<scribe> ACTION: JF should file bugs on this [recorded in

<trackbot> Created ACTION-130 - Should file bugs on this [on John Foliot -
due 2011-06-15].
Hierarchical Navigation: Progress Checkin

JS: lengthy discussion last week on hierarchical navigation would work

PS: sent a link to a demo from Google that showed how chapters worked

<silvia> http://www.html5videoguide.net/demos/google_io/3_navigation/

was also supposed to add some content to the wiki but has been backed up
with other issues

Geoff Freed provided some feedback on those demos that was valuable

<janina> accerciser

<Sean> theres a tool called acc-checker for UIA

Texted Descriptions: Requirements on A11y APIs

SP: there has been an active discussion around this

JS: notes that this has also shown up on related wikis and mailing lists
(i.e. Linux foundation)
... there are some existing holes in the Accessibility APIs

they are being reviewed to try to keep the APIs in sync


we should feed this information to others via members of this group to
related stakeholders

SH: believes the list discussion is productive, and should continue as is

JS: think we should do 2 things here

we have crossed several usedcases

we need to extract them and spell them out, as some of them will require
different solutions

JS: Cynthia and I will bring this up ion the API discussions as well

also ensure that the various media types are being mapped correctly
3GPP Request Followup

JS: Mark Watson unable to be with us today

he is also apparently a member of 3GPP

they might all be at WWDC

JS: we have a request from 3GPP that has some specificss that may be out
of scope at w3C

we should perhaps clarify goals and purposes, next steps, etc.

PLH: the request was sent to the accessibility task force, and the request
was that the HTML WG be included as well

the response can come back from Mike Smith, the chairs, we can figure that
out later

JS: my understanding is that we have an agreed upon taxonomy, a specific
way of naming all the media types that are in sync

so that we can be consistent whether it is machine read or human read

there are some differences (described video) where there is a difference
between text-based and human narrated

but the value is that everything is called the same thing across the board

so that the emergent technology will be accessing the same kind of media
as well_ consistancy

be it digital broadcasting, the web, etc.

there are mechanical questions, but should we first determine that we
understand what is being sought?

<plh> "We are therefore defining a small set of names, most of which do
not cover accessibility, and we hope that by the time a more complete
name-set is needed we will be able to refer to HTML5"

<plh> "we identify a specification, registration authority, or other
source by using a URI (normally expected to be a URN), and then provide
values from the set defined by that source."

JB: perhaps we need to jump to the next question, which is do we need a
registry, and where does that live?

PLH: their liaison statement is saying that they would like to use the
same nameset that we are defining in HTML5

the second statement, they are using a URN mechanism to define those terms

and would like the W3C to provide this

they didn't appear to ask for a registery

nor to make our list extensible

their only request is that they want to use the same things we are
defining, and could we provide a URN

They want to ensure the link remains between themselves and us

Registration Authority by URI

<paulc> http://dev.w3.org/html5/spec/Overview.html#the-track-element
identifies the values for the enumerated attribute but does not define
URIs for the keywords

<- even better

PC: want to speak dierctly to that

the track element identifies the keywords that are mapped to <track>

can we provide a link to those

PHL: providing a URI


SP: Provided a URI for track kinds






PHL: we have URI's for each in the spec

<paulc> Thank you, plh

JB: we have had conversations several weeks back, where these were

and that they needed to be referenced by more than the HTML5 spec

<paulc> Another piece of magic:

we perhaps need to have these captured in a more geneirc location

<paulc> What would happen if the semantics of the keyword changed? Would
the URI change?

we discussed capturing this in a PF space

JS: Part of the reason is that we will be unhappy if we do not have 2
additional pieces of information

10 internationalization support for the human-readable string and the
second is a clear definition

the spec might be able to give the definition, but likely not provide the
i18n support

SP: Just verified document, and they speak specifically of both types of
track - text tracks and media tracks

so we need to provide a link/url to both lists

both are in tables

or we can make a list of URLs pointing to individual values

which we already have

JS: important to note that we are not complete in defining the list

JB: agrees tht we are not finished, but believes we are close

the other issue is questioning the wisdom of pointing directly at HTML%
spec as it is far from finished

and believes the 3GPP is under a time crunch

so we likely need a list of these values external to the HTML5 spec

JS: believes we are close as well, but tweaks remain

JB: if there is follow on work, could that be changing these values as

PC: wants to partially answer Judy's question

if the URI's will be dated or not


the examples that PLH provided are not dated

poses the question or what happens if that URI changes

the heart of the question is stable URIs

PLH: believes we have a plan

we cannot give 'stable' versions until we are in Rec status

unless they lean to a dated version

so whether they point to a stable version in HTML5 or in an outside list,
if we need to change them in relationship to HTML5 we will change them

JS: wants to reask about what if new sork might change this list

don't actually believe thus will have a large impact

but we will likely continiue to better define and deliniate them

we have examples just in the last few days that show how things are

PLH: what is interesting is the list that the #GPP sent us that does not
match ours

have we ver considered using their values?

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

JS: don't recall looking at their list and saying is there anyhting

we also looked at the values used in OGG, 3GPP, suggestions from David
Singer, and others

we had a large list and did a consistant and thorough review

many of what 3GPP had suggested were already defined by us

JB: I think PLH is asking if we are already 'baked' on our terms, or is
there some of their terms that we could adopt

we did the mapping, but what does that mean moving forward

JS: believes we were more thorough

don't recall a large discussion on naming

we have tried to be very precise going back to when we were defining user

JB: in other words, we beleived our terms were more disambiguating than

JS: happy to coninue having further discussion

PLH: still not clear on how to answer the stability issue

JB: perhaps we just tel lthem where we are, and offer our projections

JS: Clarrify we are after the same goals

PLH: the other issue was that just pointing to the spec does not address
the i18n issue

we can keep the current list in the spec, and create a second duplicate
list (like a registery) that also provides the translations

we just need to ensure they remain in sync

the other is to extract that from the spec, and define it elsewhere and
pointing to it in the HTML5 spec

JB: wich resurfaces the question, and argues that they should reside
outside of the spec and be a reference

PLH: we need to bring this to the Working Group and be sure they
understand and agree

so before we can respond, we need to decide internally


JB: if it is clear that they will be used in other specs, then that argues
for external registery

JS: believes there is relevance to web on tv and real-time communications

PLH: don't think that web on TV is relevant, but real-time might be

JF: there is precedence in moving registries like this out of the spec
(ie: microdata/microformats)

JB: there are likely additional parties that care about this

SP: don't think that this is a good idea to have it outside of the spec

it means to lists to maintain

thinks that HTML5 should be the definitive text

JS: don't see a need for i18n

SP: they are just string identifiers

JS: think we want consistent taxonomies based on both machine and human
readable values

<paulc> +1 to Sylvia's point about the URIs being strings

PLH: agrees with SP on the string value issue

with no translation

JB: understands the concern about one authoritve list to maintain

but concerned to hear "and if we need to add something then we can"

if/when HTML5 is Rec there will be little appetite to reopen

JS: PF also had concerns that the strings could be consistantly


we are talking about a specification thta is written completel in english

so there is no difference between other values that we have in english
only that the i18n community already uses

PLH: can see the use-case of keeping this separate as well as integrated
... if we have an external list, then we need to define what happens when
a new value is introduced

PC: these are a numerated list of values, which means there is a finte set
in the spec

JS: this is a relatively new area, which means we can't be sure

JB: believes PLH's argument about browser support is compelling, but will
media players also be drawing upon these as well, and might be more nimble
in adoption

so are we only looking at browsers?

PLH: so we are talking about non-HTML use cases as well
... Not clear that 3GPP wants to use those values

any kind of HTML5 implementation?

JS: next steps?

JB: seems we are leaning towards inside of the HTML5 spec

and we've raised several questions against that

does it make sense to look at this more fully and try and reach a

JS: thinks there is a split between inside and outside of spec thoughts

JB: can we continue to discuss on list for another week?

PLH: perhaps we can have David Singer on the call next week

JS: should we respond with an update that we are not 'complete" yet but
under active discussion

JB: will PLH coordinate with Janina to advance an update to 3GPP?

PLH: is that ok with Paul as well? (Paul agrees)

JS: will return to this next week
... thanks and see you all next week

meeting concluded
Summary of Action Items
[NEW] ACTION: JF should file bugs on this [recorded in
[End of minutes]

Received on Wednesday, 8 June 2011 23:08:19 UTC