Re: Adopting the media accessibility requirements

Based on discussion so far, I can imagine a couple of potential steps forward:

(1) Clarify the intent of the requirements document - it identifies a comprehensive set of needs, but in further review only some of these will be considered MUST-level for the HTML5 spec itself.

(2) Continue review of the document, particularly by implementors who have not followed the TF discussion, since we have identified some important points of disconnect in the discussion so far.

(3) Consider revising the document to remove requirements that are not directly related to accessibility (if there is consensus on that).

(4) Instead of officially adopting the requirements as representing consensus of the HTMLgroup, perhaps we can just accept it as one piece of input into the broader conversation. For other ISSUEs, we haven't officially adopted a requirements document, and that has been ok. Still, evaluating proposed solutions against this document could provide a useful piece of information.

I would strongly urge anyone involved in implementing HTML5 media elements, or authoring content using HTML5 media elements, to read over this requirements document and comment, so we can discuss the best path forward.

Regards,
Maciej


On Oct 28, 2010, at 6:38 PM, John Foliot wrote:

> Philip Jägenstedt wrote:
>> 
>> 
>>  (DV-9) Allow the author to use a codec which is optimised for voice
>> only,
>> rather than requiring the same codec as the original soundtrack.
> 
> Philip,
> 
> On the companion Check List document we are still working on 
> (http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist), this 
> requirement is listed as a *May*
> 
> 
>> 
>>  (CA-4) Support pre-emphasis filters, pitch-shifting, and other
>> audio-processing algorithms.
> 
> This is also listed as a *May*, although UAAG has it as an AA or AAA 
> requirement:
> 
> 3.8.2 Speech Pitch and Range: The user can set all of the following 
> synthesized speech characteristics, overriding any values specified by the 
> author (Level AA):
> (a) pitch ("pitch" refers to the average frequency of the speaking voice), 
> and
> (b) pitch range ("pitch range" specifies a variation in average frequency),
> 
> 3.8.3 Advanced Speech Characteristics: The user can set all of the speech 
> characteristics offered by the speech synthesizer, according to the full 
> range of values available, overriding any values specified by the author. 
> (Level AAA)
> http://www.w3.org/TR/UAAG20/#gl-speech-config
> 
> 
>> 
>>  (DV-14) Support metadata, such as copyright information, usage
>> rights,
>> language, etc.
> 
> This is listed as a *Should* right now.
> 
> Both Eric Carlson (WebKit) and Frank Olivier (Internet Explorer) have 
> referenced the use/need for metadata, however I agree that this needs 
> further clarification, and asked Frank Olivier about this yesterday: 
> http://lists.w3.org/Archives/Public/public-html-a11y/2010Oct/0615.html
> 
> 
>> 
>>  (CN-6) Support direct access to any structural element, possibly
>> through
>> URIs.
> 
> This has been listed as a *Should*.
> 
> There has been a fair bit of discussion to date about the need to be able to 
> navigate longer media pieces using a more structured method than just time 
> off-sets; that richer transcripts could provide a means of navigating a 
> longer work, such as a play in three acts, or an Opera or Symphony in 4 
> movements, etc. This type of functionality is already available in other 
> Alt-format delivery mechanisms (such as Daisy), and so while this might 
> require some thinking and fiddling about, it is neither a pie-in-the-sky 
> suggestion nor something that could not be implemented as far as I can tell 
> (and I have not been left with that impression from any of the other 
> engineers involved in the sub-team). If the time-stamp format we arrive at 
> can support <h> headings, then for example we could likely use that as a 
> means of navigation.
> 
> Thinking outside of the box for a minute, it is not beyond the realm of 
> feasibility to have hyperlinks embedded into sub-titles and caption files, 
> which users could then use to navigate to enhanced content inside or outside 
> of the media asset. (Think also along the lines of DVD's 'alternative 
> viewpoint' feature - being able to click to view alternative content, etc. 
> As well, while clicking on an educational video could link to any number of 
> other multi-modal learning mechanisms - items that could assist people with 
> cognitive disabilities, etc. - the very same functionality could also be 
> used for monetization of other types of video content: like the way this 
> widget wobbles on the video? - click and off you go to an online order-form: 
> Universal Design at it's max!)
> 
> This might likely also feed nicely into initiatives such as 
> http://lists.w3.org/Archives/Public/public-web-and-tv/2010Sep/0002.html as 
> well as:
> 
> http://www.opera.com/press/releases/2010/09/10/,
> http://www.opera.com/business/solutions/devices/tv/,
> http://dev.opera.com/articles/view/creating-web-content-for-tv/
> 
> JF
> 
> 
>

Received on Friday, 29 October 2010 01:53:19 UTC