Response: Straw Poll for Issue 194

Attempting to respond to this Straw Poll this evening, I received the
following error message:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST
/2002/09/wbs/40318/issue-194-objection-poll/.

Reason: Error reading from remote server

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

Enclosed please find my Objection to the Change Proposal: Mint a transcript
attribute for the programmatic association of transcripts with media
elements (http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B)

Objection

I object to this change proposal, based upon the following summary:

The Change proposal makes a number of assertions that are of questionable
status. They include:

Discoverability

    .	in existing User Agents (which do not implement a transcript
mechanism), the user can't get to the transcript. 

Response: There are no User Agents today that are providing the required
functionality driving this Issue - the programmatic linkage of transcripts
to the video element. 

This is a strawman argument that could be used to halt any advance of any
part of the specification that does not have full implementation today.
Further, through scripting, the attribute and its corresponding link could
be discovered and served to the end user today, either through a JavaScript
framework (shim) or browser extension/plugin.

    .	in future User Agents which expose transcript="" to AT but do not
provide transcript access in their default media controls, the non-AT user
can't get to the transcript. 

Response: this presumes that User Agents will deliberately not provide
support for this feature. It is a presumption of a worst-case scenario, with
no evidence that this is what will happen in the future. 

While it is out of Scope for this or any other proposal to mandate user
agent behavior, a recommendation that such exposure and related mechanism
can certainly be added to the User Agent Accessibility Guidelines, and user
requests and market forces will likely encourage user agents to provide this
functionality. 

    .	and in future User Agents which expose transcript="" to AT and
expose transcript access in their default media controls, on sites which use
custom media controls that do not provide transcript access, the non-AT user
can't get to the transcript. 

Response: Another strawman argument - if a developer or site owner is going
to ensure that a Transcript is being made available to end users, and at the
same time also wants to use custom scripted controls, it is a huge leap of
credibility to presume that they will NOT include the custom control that
exposes the transcript they are consciously and deliberately providing.


Design aesthetics 

Response: The Change proposal states "Our proposal encourages transcript
links to be visible" and it indeed does, however it does not address the
design requirement of when, for design/artistic considerations the content
owner DOES NOT WANT a visible link on the same page as the video asset.

Insisting that it be visually present then reduces the designer to 2
options, "ruin" the esthetic of the page, or not include the link to the
Transcript. This has significant (fatal) impact on accessibility
requirements, and we have years of experience with complex images to prove
this (Google INFOGRAPHIC for enough evidence to fill a cruise-ship). We
should consciously avoid perpetuating this all-or-none scenario.

It is true that the ANCHOR element being referenced *could* be included
inside of the opening and closing tags:

     <video transcript="foo"><a href="transcript.html"
id="foo">Transcript</a></video>

.which is a longer but essentially identically performing version of: 

     <video transcript="transcript.html"></video>

.in that once again, any user will need to have a control (native or custom)
to access the transcript. The IDREF proposal therefore does not provide any
additional benefit here.


No link duplication

Response: The assertions made here are once again strawman arguments. 

   1)	It makes the presumption that user-agents will not make the
availability of a transcript part of native or custom controls, despite the
fact that this is in fact the current pattern for closed captions (another
linked text file that provides programmatic support of an associated video).


   2)	It further makes assertions that the transcript="URL" pattern will
encourage or promote "link-rot" (bit rot), and cites 2 references as
"proof". 

One of those references (http://tantek.com) currently has a  number of
"broken links" (link rot) itself, for which one can only thus conclude that
broken links are not a question of visibility or non-visibility, but rather
of author stewardship. There are numerous tools (including the W3C Link
checker) that can be used to avoid this problem, and so the problem is less
with the code pattern and more with the author themselves.

(I also want to state that this is not a criticism of Tantek or his site,
but rather simply serves to illustrate the falsehood being argued. As well,
I originally noted more than 40 broken links and pointed out this fact to
Tantek in person 2 weeks ago; he apparently went back and did some
house-keeping between that time and the time of this response. If nothing
else, this also serves to illustrate that Link Rot need not be as fatal as
being portrayed - it is an easily repairable state).


Multiple transcripts

Response: The Change proposal makes a significant point of stating the
support for multiple language transcripts of media, without providing any
proof that this is common, or that we can anticipate this in the future.
While there will always be corner-cases where a specific video will offer a
transcript in more than one language, it will likely be the rare exception
rather than the common experience, and so it can be argued that this is of
minimal benefit. 

A transcript is supposed to be the textual equivalent of the media asset,
and a translated transcript is not "the transcript" but rather a translation
of "the transcript". While this nuanced difference might seem almost moot,
there is an equivalent correlation to the difference between closed captions
and sub-titles that helps to illustrate the difference.

In the case where there are multiple languages of transcripts available, the
native language transcript of the video should/would be the linked
transcript, and other supporting transcripts (alternate languages) could be
linked on the same or supporting pages.


Surviving cross-document copy-and-paste operations 

Response: the Change Proposal states:

	"The programmatic association of the <video> with its transcripts
might not be maintained through a cross-document copy-and-paste operation,
though this is primarily a function of the distance in the DOM between the
media element and the element representing the transcript, and not the
actual form of programmatic association."

This is the most critical flaw of this change proposal. The CP also cites
another author (Cory Doctorow) and specifically his assertion: "2.2 People
are lazy" (http://www.well.com/~doctorow/metacrap.htm#2.2).

This is precisely the concern and weakness of having a link to a Transcript
placed remotely from the <video> element: in cross-document copy-and-paste
operations, "lazy" authors (those same authors BTW that won't use link
checkers to prevent link-rot) will copy and paste the <video> and not the
IDREF'd <anchor> (especially if it is not extremely closely located to the
<video> source code - the greater the distance the greater the likelyhood
this will happen), thus actually increasing link-rot, not reducing it.

This concern was surfaced during many of the calls leading up to the
divergent Change Proposals, and this CP does not adequately resolve this
significant issue.

I object to this Change Proposal based on this concern: that the
copy-and-paste problem is not adequately addressed, and by design may also
promote the same form of "link rot" it purports to squelch. I also object to
the numerous strawman arguments presented, as they are assertions with no
supporting evidence to back them up.


JF
---------------
John Foliot
Web Accessibility Specialist
Co-Chair, W3C HTML5 Accessibility Task Force (Media)
Co-founder, Open Web Camp

Received on Friday, 27 July 2012 04:03:06 UTC