W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: Track kinds

From: David Singer <singer@apple.com>
Date: Fri, 29 Apr 2011 09:38:58 -0400
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-id: <2484D713-AF3F-4223-B26A-26014E8AD2A9@apple.com>
To: Mark Watson <watsonm@netflix.com>

On Apr 28, 2011, at 18:36 , Mark Watson wrote:

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

No, agreed.  I am merely suggesting that we leave the media type out of the labels, even if the anticipated first use, and only example, is for only one media type.

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

OK, but I have a hard time seeing a philosophical difference between
* this audio track is a 'clear audio' adjusted version of the normal audio track
* this audio track is a 'repetitive stimulus' adjusted version of the normal audio track

(by the way, we need to ask Judy Brewer what the best name for this is).

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 29 April 2011 13:39:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC