Re: Track kinds

On Apr 28, 2011, at 2:13 PM, David Singer wrote:

Thanks Mark

a few quick comments:

* I think that clearAudio is probably the same as what I had called highContrast audio (where the primary content is much easier to hear against background noise/music); maybe 'clear' is a better label

If only because there is a precise definition in the requirements: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Clear_audio

* in the interests of minimizing labels, let's try to define them media-type independent (not use video, audio etc. in the name or definition unless absolutely needed).  so, 'clear' video would have less distraction behind the narrative important visual elements, for example; (which is not the same as highContrast)
* similarly, commentary video for an audio program should be possible as well as commentary audio for a video program (think about slides that explain a complex piece of music as it plays)

I am not sure about the last two. Just because we have a term which has a well-defined instantiation for one media type doesn't mean we should invent an instantiation for another media type even if we can imagine what it would be.

It's possible that there is soon-to-be-invented something similar to but different from our invented instantiation that is more useful and actually deployed: we should wait for that to happen and then apply the term to that.

* I think we ought to be able to offer in both DASH and HTML:
  a) an alternative video, audio, or multiplex that is repetitive stimulus safe
  b) main content which is so safe, and labeled as such
* maybe repetitiveStimulusSafe is a specialization of 'alternate', I am not sure

Well, as Eric pointed out on an earlier call, this could be an attribute of any track rather than a "kind". Now we could
(a) add some other way to signal accessibility attributes like this
(b) allow multiple kinds on one track (e.g. getKind returns a whitespace separated list)
(c) define new kinds just for for the kind combinations that make sense (main-repetitiveStimulusSafe and alternate-repetitiveStimulusSafe).

* the others I mention I do not see as early candidates; I just mention them to show that I think there will be other candidates in future.  I may be wrong on both counts...


On Apr 28, 2011, at 16:52 , Mark Watson wrote:

All,

I updated the wiki page (http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds) based on our discussion yesterday. There are now three tables, the kinds in the current spec, the kinds that have been suggested and the subset that we have agreed should be added to the spec (currently just "captions").

If I understand rightly, the general idea is that we should provide precise, container-independent definitions for all the kinds we agree on in a W3C document other than the HTML specification and propose that the HTML specification just define the text labels to be used with HTML.

In parallel, various people will work on introducing the same kinds to various container specifications.

We decided to continue the discussion of which ones to propose should be added to the specification on the list. To that end the three that Sylvia suggested yesterday were:
- supplementary
- commentary
- clear audio

Comments ?

...Mark

David Singer
Multimedia and Software Standards, Apple Inc.