- From: Janina Sajka <janina@rednote.net>
 - Date: Wed, 2 Jun 2010 19:24:59 -0400
 - To: HTML Accessibility Task Force <public-html-a11y@w3.org>
 
Minutes from todays' HTML-A11Y Media Subteam teleconference are provided
below in text and are posted as HTML at:
http://www.w3.org/2010/06/02-html-a11y-minutes.html
   W3C
                                                           - DRAFT -
                                          HTML Accessibility Task Force Teleconference
02 Jun 2010
   Agenda
   See also: IRC log
Attendees
   Present
          +1.650.862.aaaa, Janina, +1.408.307.aabb, Michael_Cooper, John_Foliot, Eric_Carlson, +0154558aacc, Judy,
          Sean_Hayes, MikeSmith, +61.3.986.4.aadd, Kenny_Johar
   Regrets
          Markku_Hakkinen, Geoff_Freed, Laura_Carlson
   Chair
          John_Foliot
   Scribe
          janina
Contents
     * Topics
         1. requirements document review
     * Summary of Action Items
     __________________________________________________________________________________________________________________
   <trackbot> Date: 02 June 2010
   <scribe> scribe: janina
   john: let's start with open actions review
   ... judy's actions?
   judy: have been working on a comparison to iso, seems orthogonal
   ... will post my conclusions
   ... so complete on iso comparison, but not on checking with other key individuals
   ... also unsure how to engage external people effectively without overwhelming them
   ... while action wasn't recroded, i did some work on the disability language in the doc, and will still complete that
   john: is frank here?
   [silence]
requirements document review
   john: john: not sure how to break our log jam and move forward
   ... much media will be pushed via the net, whether via specialized ua, or a general browser, our doc is important
   ... we don't have the luxury to continue debating the doc, though
   ... our survey was to make sure our doc is complete
   ... think going through the doc detail by detail is premature
   eric: perhaps i misunderstood what our purpose was in these requirements
   ... i understood that these would be required of any ua that implemented html5 media
   john: my understanding, from the a11y side, is to fully participate in consumption of this media
   q!
   <MikeSmith> I think other implementors are liking to view requirements in the same way that Eric just described -- as
   implementation requirements
   john: for instance, sign-language differs from country to country
   ... it'll be a tricky balancing
   shawn: i think a lot of our requirements aren't technically difficult
   eric: not so sure
   ... hard to decode on small platform
   shawn: but there are other ways to achieve this
   janina: we need it in the spec so that it can be covered
   eric: but, even on the desktop smil2 is lots of work
   ... so not necessarily easy to do
   ... are these rfc2119 musts?
   shawn: not necessarily that we need smil, but that we need the ability to do these things
   judy: we specifically separated user needs to avoid this conundrum
   eric: but we need to discuss what is required
   judy: absolutely agree
   eric: my concern is that 'requirement' rfc2119 'must' on the user agent
   john: i think everyone here is realistic
   ... we should remember the concept of "graceful degradation"
   ... yes, going back to the described video example, it's a balancing thing here too
   ... some kind of switching mechanism may be needed between a generalized broser and a more specialized player ua
   janina: it's a question of what html5 wants to be, if a rich media platform, all these requirements will be needed
   somewhere, though probably almost never on any individual content item
   <Zakim> Judy, you wanted to say that's why we separated out what the user needs vs how they can be technically
   achieved, so we wouldn't go into that
   judy: we keep hearing the question of whether we need to prioritize these
   ... should we discuss prioritization?
   john: also my question in some ways
   ... a bit disappointed in so few responses
   <Zakim> MikeSmith, you wanted to say what we ultimately need in regard to the spec is a specific (sub)set of
   requirements for HTML UAs
   mike: i think eric's response will be typical of browser developers
   ... the spec provides conformance criteria
   ... if there are requirements on something other than browsers, then it's not about html
   janina: i can support rfc2119 should, but the spec needs to comprehend most of these because the intent seems to be a
   full gammut of media hosted via html
   john: so our experience to date has been that addons and plugins may play something launched from the browser
   ... expect the browser will be more limited janina: not sure that browser may need to drive it all
   judy: want to raise a different point ...
   ... want to come back to the question of what will help move forward
   ... only one person on this call has filled out the survey, so can we ask a new deadline for survey?
   john: so, is this a wrong understanding of where we're headed?
   eric: what?
   john: html
   ... is should language overly onorous
   eric: seems we want interoperable content on the web, so a spec that all user agents that most people use will
   implement
   eric; so description of any feature in the spec needs to be so well described that it will be implemented consistently
   shawn: but it's about how we capture author intent, not how user agents provide it
   ... roughly the same way sounds ok, but not exactly the same way my competitor does
   eric: so spec doesn't say how to do some thing, but what it should do
   ... so external file format needs specification
   john: so, eric, you mentioned multiple audio streams unsupportable on some devices today
   ... so maybe not today, but who knows about a year from now? I recall touch interfaces were experimental just a few
   years ago
   ... we just don't want today's device limitations constrain our specification of what's needed
   shawn: so there's an issue of balance between providing the data in a form that something can be done with it
   ... so that's authoring--give the data in a usable way
   ... the must of what the content supports
   ... and the should of what the ua does
   ... we need to capture the musts
   john: agree
   janina well said
   john: do we have agreement of where to go with this?
   silence -- taken as ascent
   john: so, judy ...
   judy: i expect so few have completed the form because there's so much to do in completing it
   shawn: will do, but want weekend
   janina: ditto
   kenny: end of today
   john: by monday
   mike: don't plan to respond
   michael: don't feel qualified on this
   judy: monday is better for me
   john: so can we extend this until monday?
   ... and we need to send around another explanation that we want to capture user requirements
   <Judy> +1 to accept input via email as well
   janina: extend to 23:59 boston time monday
   john: so we should have more complete results next wednesday
   <Judy> janina: not sure that's the correct breakdown
   <Judy> ...Sean Hayes helped us understand constaints around the authored requirements
   <Judy> ...the must part might be on what the spec provides
   <Judy> ...maybe the should are what the user agent can do
   <Judy> ...if this is going to be a media platform, then we don't want the breakdown to be 'we can do text descriptions
   but we can't provide for audio description tracks"
   <Judy> Janina: if you don't have a way to support how you implement something in the spec then you're nowhere
   janina: i'm not clear that prioritizing these is the right way to go
   <JF> Janina: if HTML5 is to become the platform for media, then we need to ensure that we have a means to capture all
   of these requirements, alternatives and requirements specified
   john: don't disagree, but wonder whether we should start with author or 'must and should'
   ... think the latter because of what the engineers are saying
   ... think we should start with user agent requirements
   ... if our user reqs doc is more or less complete, i suggest our next discussion is ua requirements
   <JF> Sean: next step is to turn user requirements to tech requirements
   <JF> Eric: next step is to get clarification of some of the user requirements
   <JF> Sean: agrees with Eric
   shawn: next step is to turn these into tech reqs, then to decide what's on content and what's on ua
   eric: think we first need to agree on the user reqs
   john: so that should be our agenda for next week--item by item discussion and sign off
   ... any other business, questions for now?
   ... thanks to everyone!
Summary of Action Items
   [End of minutes]
     __________________________________________________________________________________________________________________
-- 
Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net
Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org
Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Received on Wednesday, 2 June 2010 23:25:33 UTC