Re: Categorization of media a11y requirements

On Fri, Nov 5, 2010 at 8:25 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>
> On Nov 5, 2010, at 8:50 AM, Maciej Stachowiak wrote:
>
>>
>> (1) What are the kinds of changes needed to the HTML5 spec to support this requirement?
>
> Here is my attempt to answer this question for the following items, based on our discussions yesterday:
>
>>
>> On Nov 4, 2010, at 5:55 PM, Frank Olivier wrote:
>>
>>> SPECNEW, SPECCED: (SL-1) Support sign-language video either as a track as part of a media resource or as an external file.
>
> The <track> element currently only supports textual formats; would need to support video format and an appropriate value for the kind attribute. Another possibility is a mechanism to associate two <video> elements to play in sync.


We have bug 9452 for that:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9452



>>> SPECNEW, SPECCED: (SL-2) Support the synchronized playback of the sign-language video with the media resource.
>
> Ditto above.


Ditto bug 9452.


>>> SPECNEW, TRACK: (CC-5) Support positioning in all parts of the screen - either inside the media viewport but also possibly in a determined space next to the media viewport. This is particularly important when multiple captions are on screen at the same time and relate to different speakers, or when in-picture text is avoided.
>
> Timed track rendering section does not seem to have provision for positioning timed text outside the media element or its controls.


Doesn't look like we've got a bug for this yet, but I have raised it
in discussion threads on WHATWG.


>>> SPECNEW, TRACK: (CN-1) Provide a means to structure media resources so that users can navigate them by semantic content structure.
>
> We were not sure whether this is provided for, however, using a <track> element with kind=chapters seems to address this requirement.


Yes, it does, but not hierarchically. We can, however, introduce some
sort of level marker into the chapter tracks to make them hierarchical
with time-overlapping cues. I've been thinking about proposing that.


>>> SPECNEW, UX: (CC-25) Support edited and verbatim captions, if available.
>
> We thought the <track> element lacked a way to distinguish verbatim and edited captions in the same language, however, it seems like the label attribute may be sufficient to identify caption tracks as edited or verbatim.


The @label is just a user-readable string. Do we need a
machine-readable means to distinguish between edited and verbatim
copies or just user readable? If the latter, then it will indeed be
sufficient. (I'd be happy with that, btw.)


>>> SPECNEW, UX: (DV-8) Allow the author to provide fade and pan controls to be accurately synchronized with the original soundtrack.
>
> HTML5 does have volume control, but not the ability to pan a soundtrack.


This was identified as a "should" level requirement. My suggestion
would be to not solve this within HTML5 LC, but keep this for a future
version.


>>> SPECNEW: (DAC-5) Non-synchronized alternatives (e.g., short text alternatives, long descriptions) can be rendered as replacements for the original rendered content (UAAG 2.0 3.1.3).
>
> HTML5 spec doesn't seem to have specific provision for a textual alternative (as opposed to captions or a transcript) for a video.


I think a simple text or hyperlink to a longer text right next to the
video or audio element will be sufficient to fulfill this need - it's
what WCAG suggests, too. I don't actually think we need some new
markup for this.


> Also, looking closer at the spec, I believe the following items marked SPECCED are actually *not* yet provided for:
>
>>> SPECCED: (CA-1) Support clear audio as a separate, alternative audio track from other audio-based alternative media resources.
>
>
> There is no provision for the <track> element to reference audio, nor is there an appropriate kind value for clear audio.


No, but this could be solved with the same multitrack solution as
earlier and bug 9452. If we are careful, we will introduce a means to
directly change the volume on different audio tracks through
JavaScript, so we can satisfy this.


>>> SPECCED: (DV-4) Support recordings of real human speech as a track of the media resource, or as an external file.
>
>
> The HTML5 draft has no provision for a video description track in the form of audio rather than text in the <track> element.


Agreed. And again, this can be solved with the same multitrack support
that bug 9452 is asking for.


> And I believe the following 4 items may not actually have HTML5 spec impact:
>
>>> SPECNEW: (CN-6) Support direct access to any structural element, possibly through URIs. [Media fragment-like issue]
>
> Seems addressable through Media Fragments URI: <http://www.w3.org/TR/media-frags/>
> Does HTML5 need any changes to adopt this?


There is some recommendation necessary around the visual display of a
media fragment in a video or audio element's @src, possibly the
introduction of some new controls (e.g. loop fragment / loop whole, or
rewind fragment / rewind whole). And then there is the whole question
of addressing named fragments over timed fragments. The media
fragments WG is looking into these issues and preparing a
recommendation. This is all part of bug 10723
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723.


>>> SPECNEW: (CN-3) Support both global navigation by the larger structural elements of a media work, and also the most localized atomic structures of that work, even though authors may not have marked-up all levels of navigational granularity.
>
> (I don't fully understand this requirement; sounds like maybe it should be in the UX category.)


I'm not sure how navigation is possible without having marked-up
navigation points. Other that that, it is clearly related to the above
discussion of CN-1 and chapter cues.


>>> SPECNEW: (CNS-1) All identified structures, including ancillary content as defined in "Content Navigation" above, must be accessible with the use of "next" and "previous," as refined by the granularity control. [May be handled with cue ranges]
>
> (I don't recall why this is a spec requirement rather than UX)


It's more an accessibility API requirement than anything else, really.


>>> SPECNEW: (DAC-2) The user has a global option to specify which types of alternative content by default and, in cases where the alternative content has different dimensions than the original content, how the layout/reflow of the document should be handled. (UAAG 2.0 3.1.2). [Probably minimal spec text required: Media queries would work nicely here; also UX issue (user sets media query to match)]
>
> Seems like this would be an issue for a spec to extend Media Queries; not clear if there is actual HTML5 impact.


I almost think this is a case for user preferences, so UX. I'm not
clear how media queries can help here.


Cheers,
Silvia.

Received on Friday, 5 November 2010 12:17:56 UTC