Friends,
The Minutes from today's teleconference call can be found here:
http://www.w3.org/2011/06/08-html-a11y-minutes.html
...or in plain text immediately after this announcement. As is always the
case, corrections and comments should be posted to this list.
JF
*********
- DRAFT -
HTML Accessibility Task Force Teleconference
08 Jun 2011
See also: IRC log (http://www.w3.org/2011/06/08-html-a11y-irc)
Attendees
Present
+1.650.468.aaaa, JF, +44.844.800.aabb, Sean, Janina, silvia, [Microsoft],
Judy, Michael_Cooper, Plh
Regrets
Chair
Janina_Sajka
Scribe
John_Foliot
Contents
Topics
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
this
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
http://www.w3.org/2011/06/08-html-a11y-minutes.html#action01]
<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
<Sean>
http://www.microsoft.com/Presspass/press/2008/mar08/03-13AccessibilityTool
sPR.mspx
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
<silvia>
https://wiki.mozilla.org/Accessibility/IA2_1.3#IAccessibleMedia_interface
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
progressing
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
<silvia>
http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getkind
<- 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
<plh>
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-subtitles
SP: Provided a URI for track kinds
<plh>
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-captions
<plh>
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-descriptions
<silvia>
http://www.w3.org/TR/html5/the-iframe-element.html#dom-TrackList-getKind-c
ategories
<plh>
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-chapters
<plh>
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-metadata
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
discussed
and that they needed to be referenced by more than the HTML5 spec
<paulc> Another piece of magic:
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-subtitles
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
well
PC: wants to partially answer Judy's question
if the URI's will be dated or not
<paulc>
http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
-subtitles
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
changing
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
missing?
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
requirements
JB: in other words, we beleived our terms were more disambiguating than
theirs
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
+q
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
interested
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
translatable
PLH:
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
consensus
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
http://www.w3.org/2011/06/08-html-a11y-minutes.html#action01]
[End of minutes]