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

While a wishlist is useful on the long-term and as a primer for people  
like me on what accessibility folks think is important, I get the feeling  
that some of the requirements are more important than others. For example,  
I would imagine it is absolutely critical that captions be delivered in a  
text format as opposed to bitmaps, while it is not nearly as important  
that one can direct a particular soundtrack to headphones only.

I would like to see a list of requirements which are truly critical for  
accessibility, avoids trivial requirements which are going to be fulfilled  
regardless (e.g. that a text format be used) and avoids things which are  
already required by the spec. I would also really like to see more direct  
feedback on the actual direction the spec is going with <track>, WebSRT,  
etc. After browsers start implementing and shipping, it may already be too  
late.

Philip

On Sun, 30 May 2010 09:03:04 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> Hi Eric, and also Philip,
>
> I agree that there are many details that we need to address in the
> requirements document and it will be great to start a detailed
> discussion about every single topic brought up in the requirements
> document. I also think that some of the requirements may well go
> beyond what is technically possible now. However, I do not think that
> it is the aim of the document to only specify what should actually go
> into HTML5 now. Instead, I look at the requirements document simply as
> a wishlist created by folks with an accessibility background of things
> that would be awesome to have around audio and video on the Web. And I
> think it is good to capture this, even if some of it can not (yet)
> technically be realised.
>
> It is also important, though, for accessibility folks to understand
> that this is a wishlist and may not result in all of this technology
> actually being available in HTML5 in the near future. Thus, it is good
> to flag this early.
>
> Maybe we need to make a general addition to the document stating this
> clearly? John, Janina, what do you think?
>
> Also, we need to take on board the points where Eric and Philip have
> directly pointed out that sentences/requirements are not
> comprehensible and explain these better.
>
> I suggest what we do with your inputs is the following:
> 1/ add an explanation at the top that this is a list for what should
> be made available in a perfect world and that this may result in a
> long-term work-plan with some more important dimensions solved earlier
> than others. Maybe we can even come to an agreement on what is of
> higher priority?
> 2/ go through and fix up the requirements that are not understood.
> 3/ start discussions on the mailing list for every single section to
> get closer towards technical recommendations on how it could be done
> in HTML5.
>
> Cheers,
> Silvia.
>
>
> On Sat, May 29, 2010 at 9:38 AM, Eric Carlson <eric.carlson@apple.com>  
> wrote:
>> 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
>>
>>
>>
>


-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Sunday, 30 May 2010 06:06:57 UTC