RE: transcript="" proposal (ACTION-211 for ISSUE-194)

Frank Olivier wrote:
> 
> I agree - I'd also prefer that we take our time to come up with a
> proper solution to this problem rather than rushing it - especially if
> the problem we're trying to solve is larger now ("we can't ignore
> interactive transcripts ").
> 
> CP http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange seems most
> appropriate for the HTML5 timeframe.

Thanks for your feedback Frank.

At issue is that from an accessibility perspective we cannot go past Last
Call with a known defect, and we've stated since the summer of 2010 that a
requirement for a programmatic linkage of the transcript to the media
elements was required:

	"[T-1] Support the provisioning of a full text transcript for the
media asset in a separate but linked resource, where the linkage is
programmatically accessible to AT."
http://www.w3.org/WAI/PF/media-accessibility-reqs/#transcripts 

In our working draft Checklist[1] (established at the same time as the
user-requirements document), we further mapped this requirement to a current
WCAG 2 "A" level requirement (along with an RFC 2119 "SHOULD"):

	"1.2.1 Prerecorded Video-only: Either an alternative for time-based
media or an audio track is provided that presents equivalent information for
prerecorded video-only content."
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#media-equiv-av-only-alt 

1.
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Check
list#t


For these reasons, a No Change (a.k.a. no solution) Change Proposal at this
time is simply not acceptable.  Given that there is at last count at least 6
other attempts to find a solution to this Issue in the Last Call timeframe,
I think there is a demonstration and willingness already to look at multiple
possibilities to serve the need - further weakening the "do nothing"
response.



With regard to "interactive transcripts", that same User-Requirements
document states:
	"[T-2] Support the provisioning of both scrolling and static display
of a full text transcript with the media resource, e.g., in a area next to
the video or underneath the video, which is also AT accessible."

While this requirement does not map back directly to a specific WCAG
requirement, in our checklist we none-the-less noted that this was a SHOULD
requirement as well.

********

<Personal Opinion>

The introduction of the <transcript> element, while significantly useful for
future interactivity, also serves a second and equally important function:
it is where the actual link to the Transcript resides.

One  significant concern that surfaced during our discussions was the
'orphaning' of the link to the transcript due to the fact that it could not
be authored inside the opening and closing <video> tags.  By placing that
link inside a newly minted landmark element (<transcript>) it made things a
lot easier to find and copy over in the copy & paste scenario, and seriously
mitigated that possible harm - it didn't totally eliminate it, but it made
it a lot harder to mess up. Given the concern expressed in other fora around
the topic of "link rot", I would think that copying a <video> with an
@transcript IDREF that points to nothing would elicit similar concerns: a
broken linkage is a broken linkage, whether it's to an URI or an ID.

As well, the other @transcript/IDREF CP
(http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B) does not
adequately address the use-case of the author not wanting to place a
<del>D-link</del><ins>visible on-screen link</ins> in a predictable fashion:
we're left with the numerous good and not so good author techniques that
sometimes work and sometimes don't for hiding content from some users and
not others.  

Relying on an ID as a sole means of tracking down a link to the transcript
seems fairly weak and brittle to me - there are just so many IDs on any
given page, and given that IDs can take any value string the author chooses,
I remain concerned that orphaning will be of significant concern without
some other means of signaling to authors that *THIS RIGHT HERE* is the
transcript link. ALWAYS placing that link inside of the <transcript> element
goes a long way in achieving that.  This point is frankly what got *me* to
agree to abandon my initial proposal to introduce @transcript pointing to a
URL directly.

</Personal Opinion>

********

There is another Accessibility Task Force media sub-team conference call
scheduled for next Tuesday, June 5th at 3:30 Pacific Time (tentative) where
we will look at existing concerns with regard to the CP we are seeking to
endorse. I hope you can join us!

Cheers!

JF

Received on Friday, 1 June 2012 21:09:20 UTC