minutes: HTML A11y TF Media Subteam TPAC2010 Face2Face meeting [draft]

aloha!

during a break-out session, members of the PFWG and the HTML WG discussed
media accessibility and concerns -- since this was a TF meeting, the
discussion was held in the #html-a11y chat room so that the minutes of
the procedings could be world-viewable

the minutes are available as hypertext at:

http://www.w3.org/2010/11/02-html-a11y-irc

as an IRC log at:

http://www.w3.org/2010/11/02-html-a11y-irc

and as plain text following this introduction

thanks to josh for scribing -- please report any errors, omissions, 
clarifications, corrections, mis-attributions and the like by 
replying-to this announcement on list...

note that there may be another meeting with HTML WG members on 
thursday, time to be announced, so please check the public-html-a11y 
list for updates, gregory.
    _________________________________________________________

                             - DRAFT -

                       HTML Media A11y Subteam

02 Nov 2010

  See also: IRC log - http://www.w3.org/2010/11/02-html-a11y-irc

Attendees

  Present
         Janina_Sajka, Stefan_Schnabel, Michael_Cooper, Henri_Sivonen,
         Joshue_O'Connor, Artur_Ortega, Frank_Olivier,
         Gregory_Rosmaita, John_Foliot, Philip_Jägenstedt,
         Silvia_Pfeiffer

  Regrets
         Kenny_Johar

  Chair
         Janina_Sajka

  Scribe
         Stefan

Contents

    * Topics
        1. Metadata
    * Summary of Action Items
    _________________________________________________________

  <foolip> Zakim: conferences?

  <foolip> foolip is on phone, is Philip Jägenstedt from Opera
  Software

  <inserted> scribenick: Joshue

  JS: The subteam has created a doc called user requirements.
  ... I am really happy we have discussion, it was needed.
  ... General history and background.

  <foolip> We are talking about
  http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements

  <JF> morning silvia

  JS: John, Sylvia any comments?

  JF: Good summary..

  JS: So how do we move forward?

  HS: I objected to adopting the requirements.

  <oedipus>
  http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements

  HS: The req doc has stuff that is not a11y requirements IMO.
  ... There is also the issue of what it means to adopt the reqs.
  ... We are concerned about objections that relate to features that
  are not a11y related.g. Codecs, copyright meta data.
  ... The details of the Codecs are not related to a11y.

  <oedipus> silvia, i mis-typed -- the actual passcode is 92473#
  (WAIPF#)

  HS: The HTML 5 Wg has not come to a general concensus on what codec
  to require. I am concerned that unrelated a11y issues are included
  in a doc as a11y requirements.
  ... Who will be affected by not including copyright meta data?

  <JF> +q

  JS: This can effect people with disabilities as captioning was not
  happening if the meta data was not there, as of the source material
  did not have copyrighting meta data, then the captioning may not
  happen.

  JF: We need to have a means of including a way to get at this meta
  data.. its only one type, there is also Dublin Core.. adding meta
  data to transcipts is not overly complex..etc

  <oedipus> closed-captioning is thought of as a real-time
  transcription of what is said and indications of ambient sounds, and
  historically has been viewed as repllicating the content of the
  captioned item

  JS: HS asked a good question, I don't know if there is a diff
  whether in band or in meta data.

  <oedipus> audio description goes off-script to provide descriptions
  that are essential to an understanding of the content

  JS: Don't want to get hung up on definition.Our issue is that
  copyright data gets carried effectively.
  ... We need an effective mechanism.

  HS: My problem is that the doc states MUST requirements.

  JS: Could you give us some examples?

  HS: You could take out the requiements to add copyright meta data,
  take out the entire requirement?

  JS: No.

  HS: Specific implementation requirements mean that, if the
  requirements change in the future, I hope we don't fail to meet
  future requirements if things are currently over specified.
  ... It should not be presented as it is. If its an inventory thats
  fine, it doesn't read like this.

  JS: Is there a problem about carrying copyright data?

  <JF> We shouldn't be designing HTML (a language that will be with us
  for

  <JF> decades) around the short-term solutions. Problems in the
  platform should be fixed correctly, not using band-aid techniques.

  HS: No, I don't object to that. My concern is overspecifiying in the
  spec.
  ... I would like to remove the requirement.

  <oedipus> we have to provide the tools to make the information
  understandable -- all the tools need to be in the toolbox, authors
  can use items from that toolbox

  JS: We need to include it.

  HS: I have a problem with must requirements in the detail.

  JS: Can you help us with the wording?

  HS: Requiring usage rights data is a problem.
  ... A place for copyright notices is fine, but meta data is a rat
  hole. RDF issues etc.

  JF: I object to calling RDF crazyness.

  <oedipus> plus 1 to JF

  JS: This may be unintentional, in terms of implementation specifics.
  ... We are talking about education environments in particular.

  MC: We are saying we need to require this info if available.

  <JF> +1 to (Michael Cooper)

  MC: It may be less problematic than you think.

  HS: If you say you must support meta data, then it brings in RDF
  etc. I don't have a problem with inventorying everything, I have a
  prob about the docs presentation - what it says and its presentation
  are different.

  JS: Lets talk about what it says.

Metadata

  JS: Overview on what metadata is..

  General discussion on metadata, captioning, multiple content
  versions, resource retrieval, implementations, suitable mechanisms
  etc

  AO: When watching TV, I can get my preferences for audio description
  etc. I would like this functionality in HTML 5.

  SP: Two questions, 1) Copyright 2) RDFa were mentioned.

  <hsivonen> (I mentioned RDF--not RDFa today)

  <hsivonen> *mentioned

  SP: Is there a fundamental problem, where a piece of content needs
  to be tracked and rights associated?
  ... What is the problem?

  HS: The data needed for a resource, a generic data mechanism is a
  rat hole. We should not commit to it..

  SS: It seems to me that the term meta data does not specify how it
  relates to a11y.

  <JF> can't pretend that metadata doesn't exist because some people
  think it is a rat hole

  <hsivonen> should *NOT* commit to a generic metadata mechanism

  <oedipus> plus 1 to JF - not looking for rat holes, nor courting
  bubonic plague

  JS: We are looking for a mechanism to support a11y. How can we fix
  this?

  HS: By enumerating the data that is required for choosing the
  resource.
  ... More detailed overview..

  <JF> dublin core metadata? http://dublincore.org/groups/access/

  JS: Any problems with this SP, JF?

  SP: By making it a finite list?
  ... I don't understand, are we too detailed? What elements and
  datafields etc this needs to be analysed.
  ... Would it be helpful to start on this?

  <stefan> scribe: Stefan

  MC: we need that list but with priorities

  JS: we need to iterate that list, too

  HS: we need concerns, what is needed to adopt requirements? That's
  th question.

  FO: what is exact req. to provide e.g. copyright info? What is the
  User Agent Requirement?

  <hsivonen> The question is what happens if the WG adopts the
  requirements and some of them aren't met?

  <hsivonen> *if the WG adopts

  JS: that depends, in an authoring tool eg. it can be maintained

  AO (explains about regulations in different countries for suppying
  metadata info)

  Silvia: explains metadata situation with img example

  (discussion continues)

  <Zakim> MichaelC, you wanted to talk about contingency engineering;
  not meeting requirements

  MC: we needs to get to some process
  ... (explains engeneer view vs. spec. view is root cause of issue
  debating)

  <Joshue> +q

  <JF> +q

  HS: what to do with metadata? HOW to show it? How to expose to User
  Agent?

  Joshue: having metadata as part of data source is vital

  <JF> +1 to silvia

  JS: (reports on inportance of exposing metadata for corporight
  reasons)

  <oedipus> plus 1 to silvia who said "a JS API to metadata in a11y
  resources just like a JS API to metadata in video/audio resources
  would actually be really nice"

  <hsivonen> silvia, is "would be nice" something you'd stall HTML5
  for?

  JF: is metadata not supposed to be machine-readable?

  <oedipus> extractable metadata can only be extracted if it exists

  <silvia> hsivonen, probably not on HTML5, but definitely on the
  baseline caption format

  HS: microdata in captions in cue text: what you have done? yo've
  required the metadada to be coded in markup - this will require
  lotta time to stall HTML5 for that

  <foolip> hsivonen is saying "cue text", not qtext

  <Zakim> foolip, you wanted to talk about what "adopting" the
  document

  JS: we can debate what should be machine-readable and what's not

  <silvia> I agree with foolip on that we need to define what to do
  with the document

  PH: we need to be more specific in the document

  <Zakim> MichaelC, you wanted to say we want to stall HTML if
  necessary to get requirements met, but don't want to do so
  unreasonably with excessive or open-ended requirements and to

  <silvia> I think the question of what of these requirements should
  stall HTML5 from going to LC is a different question to what are the
  user requirements - the document only answers the latter one

  MC: we gotta be reasonable about spec: we don't want open ended
  requirements, concerned about req. for HTML5 language

  <Leonie_Watson> +1 to Michael on stall spec if nesc, but only where
  reasonable.

  <foolip> Requirements in HTML5 *are* requirements on
  implementations.

  <JF> +1 to MC

  MC: we should make req. that can be addressed in HTML5

  <oedipus> plus 1 to MC on stall spec if necessary

  <JF> +1 to High Level concept. this is where we are today

  FO: (talks about req. fileformat, content etc.) this is high level,
  more specifics are described in document, now to sit down on
  implementers site and discuss how this can be done
  ... this is all not rocket science, it is much easier to implement,
  but we need common understanding

  HS: is it okay stalling the spec because one requirement is not met?
  What can we do?

  FO: we're takling about abstract concepts .. we're chasing with that
  what we try to do here

  <JF> +q

  FO: which format to specify? which one is baseline? these ar the
  questions to answer

  HS: req have predestination about this

  JS: how to resolve without going item by item

  FO: we should discuss req. based on CONCRETE proposals
  ... next steps: gonna creating the "Implementers Guide"
  ... with list of items inside ...

  q

  <oedipus> JF aasking about time of thursday meeting

  <JF> will there be anoher call on thurs?

  <oedipus> there will most probably be another meeting with HTML WG
  on thursday, time to be announced -- check the public-html-a11y list
  for updates

Summary of Action Items

  [End of minutes]
    _________________________________________________________