HTML Media A11y Subteam -- 02 Nov 2010

<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

<oedipus> 92743

<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 ...

<oedipus> JF aasking about time of thursday meeting

<JF> will there be anoher call on thurs?

<oedipus> laura, minutes from today's HTML5 discussion at http://www.w3.org/2010/11/02-html-a11y.html

<Laura> oedipus: Thanks Gregory, I get a "Sorry, Not Found." message for that URI.

<oedipus> s/oedipus: Thanks Gregory, I get a "Sorry, Not Found." message for that URI/ /

<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

- DRAFT -

HTML Media A11y Subteam

02 Nov 2010

Attendees

Contents

Metadata

Summary of Action Items

Scribe.perl diagnostic output