- From: John Foliot <jfoliot@stanford.edu>
- Date: Wed, 8 Jun 2011 16:07:40 -0700 (PDT)
- To: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
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]
Received on Wednesday, 8 June 2011 23:08:19 UTC