See also: IRC log
<trackbot> Date: 08 June 2011
<scribe> Meeting: HTML-A11Y telecon
<scribe> Scribe: John_Foliot
<scribe> agenda: this
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].
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-13AccessibilityToolsPR.mspx
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
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-categories
<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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JF Found Scribe: John_Foliot Default Present: +1.650.468.aaaa, JF, +44.844.800.aabb, Sean, Janina, silvia, [Microsoft], Judy, Michael_Cooper, Plh Present: +1.650.468.aaaa JF +44.844.800.aabb Sean Janina silvia [Microsoft] Judy Michael_Cooper Plh Found Date: 08 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/08-html-a11y-minutes.html People with action items: jf WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]