W3C home > Mailing lists > Public > public-html@w3.org > June 2012

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

From: John Foliot <john@foliot.ca>
Date: Fri, 1 Jun 2012 17:33:04 -0700
To: "'Edward O'Connor'" <eoconnor@apple.com>, <public-html@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Cc: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, "'Charles McCathieNevile'" <chaals@opera.com>
Message-ID: <031801cd4057$4850f510$d8f2df30$@ca>
Edward O'Connor wrote:
> 
> Awesome. In that case, could we drop both the nonzero-change proposals
> and proceed with a CfC on the zero-edit CP?
> 

No! (Emphatically, and with zero hesitation.)


As I previously outlined to Frank Olivier today, this is simply not
acceptable for accessibility considerations.

>From an accessibility perspective we cannot go past Last Call with a known
and significant 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 


Representatives from both Apple and Microsoft were party to the writing of
that Requirements Document, and endorsed the final outcome of our extensive
meetings and work in creating that document (by attaching their names to it
as authors).

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 a "do nothing" response.


Continued pursuit of the Zero Edit option will likely be met with strong
resistance from the Accessibility Task Force, up to and possibly including a
Formal Objection. (I am quite prepared to do that myself.)

*************

With regard to "interactive transcripts" I would be willing to accept a
slower pace in their development, but I want to very much de-link the
initial requirement covered by Issue 194 and any enhancements addressed by
"interactive transcripts": specifically we require a dedicated, programmatic
linking of transcripts to their parent element, and such linkage cannot rely
exclusively on an on-screen textual link (the D-link problem) alone. 

The basic requirements have not changed since the issue was first raised,
they did not change during the extensive conversations at the recent
Face-to-Face meetings in Mountain View, and they have not changed now. Both
Ted's and Silvia's/media sub-group's current Change Proposals have listed
all of the requirements, which are:

	R1: Discoverability - the end user (sighted or otherwise) can
discover that there is a transcript available; machines (AT, search engines,
syndication) can discover that there is a transcript available.

	R2: Choice to consume - the option to consume or not consume the
transcript remains in the control of the user.

	R3: Rich text transcripts - transcripts should be able to support
richer content than flat text, including WebVTT files, HTML, RTF, Daisy or
other formats.

	R4: Design aesthetics - the transcript display needs to be stylable
for design aesthetic, including the possibility to include it in the video
controls.

	R5: Embeddable - the transcript needs to be embeddable, i.e. given
as a separate resource, but rendered full-text on-page.

	R6: Fullscreen support - the transcript needs to be able to go
fullscreen with the media element

	R7: Retrofitting - it should be easy for authors who are already
publishing content with transcripts to retrofit their existing pages.

	R8: No link duplication - transcript link duplication should be
avoided.

	R9: Multiple transcripts - transcripts may be available in different
languages - making multiple links available should be possible.

	R10: Stand alone transcripts - transcripts need to be available even
in browsers that do not support or do not render audio or video elements. In
fact, it should be possible to render transcripts without requiring a media
element be present on the same page.

Given that both of those CPs start from the same requirements list
(agreement), both use similar (almost identical) methods of linking the
transcript to the media element (more agreement), I would much prefer that
work be pursued in finding consensus between those two initiatives instead,
and the media sub-team have reconvened to work towards that: we have a
teleconference scheduled for next Tuesday at 3:30 Pacific, and I
specifically would like to invite both Ted and Frank to join us then.
(http://lists.w3.org/Archives/Public/public-html-a11y/2012Jun/0004.html)  


JF
Received on Saturday, 2 June 2012 00:33:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 2 June 2012 00:33:48 GMT