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

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

Received on Sunday, 30 May 2010 01:03:57 UTC