Re: Please Read (was RE: Survey on Media Accessibility Requirements)

All -

  I haven't responded to the WBS survey yet, but here is my feedback. 

  I think there are enough issues with the document that it would be helpful for the task force to have a discussion via email to sort it all out.

eric


Audio Description

This content type will be very difficult or impossible to support on some resource constrained devices because it requires the media engine to decode and play more than one audio stream simultaneously. For example, with the audio chips used in many modern cell phones  it is impossible to decode and play more than one stream of digital audio data at a time.

• (AD-4) Any digital audio format should be able to handle "real human speech", it doesn't need to be called out. Synchronizing audio and video loaded from  different files can be very difficult to do well.

• (AD-5) and (AD-6) These require multiple audio streams to play simultaneously. This is not possible on all devices.

• (AD-7) What does "The degree and speed of volume change should be under provider control" mean? Is it really crucial for this feature?

• (AD-9) We have not been able agree on required audio and video codecs, what makes you think we will be able to agree on a code specialized for speech? Is it really required?

• (AD-11) This requires multiple audio streams to play simultaneously. See above.

• (AD-12) What does this mean? What are programs and channels?

• (AD-13) I have no idea what this means.

• (AD-14) What does "support metadata" mean? Digital media files can already carry metadata, is the requirement to expose it to the DOM?


Texted Audio Description

If we want people to be able to create interoperable pages, this requirement must specify a TAD file format.

(TAD-1), (TAD-2),  (TAD-4), and (TAD-5) Aren't these all requirements for the TAD file format?

(TAD-3) This won't be possible on all platforms, for example devices that only allow one mode of audio output.


Extended audio description

This is impossible to evaluate without a specification for an EAD file format. WCAG2 recommends using SMIL 1 or 2, which would be an *enormous* implementation burden an a UA.


Clear audio

(CA-1) - (CA-3) These require a UA to play multiple tracks of audio simultaneously. As previously noted, this is not possible on all devices.


Content Navigation by Content Structure

This will require a mandated CN file format if we want interoperable content. The two formats mentioned are quite complex and will require enormous implementation effort. Do we actually *require* that level of sophistication?

(CN-2) - This may not be possible with all CN formats as not all are self-contained.
(CN-3) - (CN-5) These are functions of a CN file format.
(CB-8) - (CN-10) I don't know what these mean.


Captioning

(CC-1) Not all media files have audio.
(CC-17) Does this mean that captions are rendered from more than one external caption file simultaneously?
(CC-25) What must a UA do differently for edited vs full verbatim captions?


Extended Captioning

(ECC-1) What does this mean? What is the format of "metadata markup"?
(ECC-2) What are "other activation mechanisms"?
(ECC-4) How does this work? Who decides if "overlap is OK ..."?


Sign Translation

Decoding and rendering multiple streams is even more difficult with video than with audio. Video decoding hardware used in many mobile devices is not able to decode more than one video stream simultaneously.

(SL-1) and (SL-3) Playing multiple media files in sync is not currently supported by HTML5, and will be a significant amount of work for some UAs.


Transcripts

(T-2) Does this affect page layout, eg. does change the size of the <video> element or appear above other page content? 

How will this work on a device with a small screen or a device that only allows fullscreen playback,?

I don't understand "If the author chose to create a new interface using scripting, that interface MUST map to the native controls in the user agent". Controls implemented with scripting should *use* the same interface to control a media file, but they do not use the native controls. Like Philip, I suggest we add a requirement that it must be possible to enable native controls even if a page has custom controls.


Granularity Level Control for Structural Navigation

I don't understand this requirement at all.


Time Scale Modification

(TSM-2) As I have noted before, it is not possible to change speed without changing pitch on all devices that are capable of playing digital audio.
(TSM-3) - (TSM-5) These are already required by the HTML5 spec.


Production practice and resulting requirements

This is advice for people authoring media, not HTML. It isn't something the HTML WG needs to consider.


Discovery and activation/deactivation of available alternative content by the user

(DAC-1) - (DAC-1) How will the user control reflow and layout?

(DAC-4) Isn't this fundamental to the concept of an alternative? If it needs to be mentioned at all, it should be in the section(s) about specific alternatives.

(DAC-5) This needs to be fully specified, eg. what happens when alternative content doesn't fit into the <video> region, etc.

(DAC-7) This should be mentioned in the section(s) about alternative content.

(DAC-8) This changes behavior of 'autoplay' and 'preload', say so.


Requirements on making properties available to the accessibility interface

(API-4) Why is this an issue for the HTML WG?


Requirements on the use of the viewport

(VP-3) Need details about how this is supposed to work, eg. does the video pop up over the page content or does the rest of the page reflow? Is page zoom enough? "with the ability to preserve aspect ratio" - when would the user ever not want to preserve aspect ratio?

(VP-5) All existing browser, and many stand-alone media player applications, place controls along the bottom edge of the movie. Where should they go instead?


Requirements on the parallel use of alternate content on potentially multiple devices in parallel

(MD-3) I don't understand this, an example would be helpful.

(MD-4) "This assumes the video element will write to the DOM" - does this mean the media element's properties are accessible via the DOM?

(MD-5) "e.g., by checking a box ..." because this document is about *media* accessibility, the example should be about a media element

(MD-7) I don't understand this.


On May 27, 2010, at 9:58 PM, John Foliot wrote:

> Hello All,
>  
> I just wanted to send out a quick note about this very important survey (scheduled to close Wednesday, 2 June 2010), which is envisioned as much as a straw poll as anything else.
>  
> It is important that this document be *very* right, as it will become the basis for a number of critical decisions moving forward, and having a complete Requirements Document will be hugely beneficial when it comes to some differing views down the road, as it will contribute significantly in removing 'emotion' from the discussion (and having broad consensus within the Task Force will be important).
>  
> Even if you really don't think you have much to contribute here, please take a few minutes to review what we have... maybe we *do* have it right, but this really is a "many eyes" work effort at this time, and if one extra requirement or equivalent feedback comes back that improves what we have then it has been a worthwhile exercise. As well, if you know individuals or organizations in your locality that might have something to contribute, feel free to solicit their feedback as well.
>  
> Survey:
> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/
> (Note the Draft Requirements are listed in the survey)
>  
> Requirements:
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements
> (for those not part of the TF, but may have feedback)
>  
> (If you know of any such individual or group, but require more time for their feedback, please ping me.)
>  
> Thanks in advance for your participation!
>  
> JF
>  
> **************
>  
> A survey on media accessibility requirements is available:
> 
> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/
> 
> The media sub-group discussed this survey 26 May 2010 and it was announced to the general task force 27 May 2010. This survey is to gather opinions on Media Accessibility Requirements. Each of the Alternative Content Technologies and System Requirements are separately presented for feedback.
> 
> As a point of interest, there are 110 numbered requirements, with a lot of related explanatory material. In the survey this is presented as 17 separate questions for input. Please allocate enough time to complete this survey. ;) The survey is currently scheduled to close Wednesday, 2 June 2010, at the end of the day Boston time.
> 
> If you need to work on this in multiple sessions, you can always enter as many answers as you can, submit them, and return to the survey later. It will still have your original answers and will allow you to modify them and enter new answers. Just remember to submit your work at the end of each session.
> 
> Michael
> 
>