W3C

Results of Questionnaire ISSUE-194: How to provide a mechanism for associating a full transcript with an audio or video element? - Straw Poll for Objections

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: pcotton@microsoft.com, rubys@intertwingly.net, mjs@apple.com, mike@w3.org

This questionnaire was open from 2012-07-11 to 2012-07-26.

4 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to introduce a @transcript attribute that contains a URL
  2. Objections to the Change Proposal to introduce a @transcript attribute that contains a list of one or more ID references
  3. Objections to the Change Proposal to defer ISSUE-194 until HTML.next.

1. Objections to the Change Proposal to introduce a @transcript attribute that contains a URL

We have a Change Proposal that proposes to introduce a @transcript attribute on HTML5 media elements that contains a URL. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to introduce a @transcript attribute that contains a URL
Janina Sajka
Theresa O'Connor In "Comparing to the IDREFs change proposal," the URL proposal
misrepresents the IDREF proposal in several respects.

* With regard to R1 (Discoverability), when the referenced transcript is
not in the same document as the media element, the URL proposal claims
two deficiencies in the IDREF proposal:

* First, it implies that an indirect link (of the form <video
transcript=foo>...<a id=foo href=bar>) is somehow a more difficult
programmatic association for UAs to process, but a) it does not back
up this implication with any evidence, and b) in fact, such a
programmatic association is not difficult for UAs to process. (A
simple call to document.getElementById(), possibly the most basic
DOM operation, suffices.)

* Secondly, it makes an argument about how the IDREF proposal's
solution would survive cross-document copy-and-paste operations,
which I believe is adequately addressed in the IDREF proposal
itself.

The sample markup that's provided also misrepresents the IDREF
proposal. A corrected version follows.

<video poster="poster.jpg" controls transcript="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<div id=transcript lang=en>
<h4>Transcript</h4>
<p>This is where the full transcript goes.</p>
</div>

Note that the extraneous <a> element has been removed, and that the
transcript ID has moved to a element which contains the transcript,
not to an element that simply happens to precede the transcript.

Neither proposal imposes a restriction on what markup is provided
for fallback to older clients.

* In the section on R5 (Embeddable), the URL proposal again mistakenly
asserts, as it did in R1, that the IDREF proposal requires "special
markup inside the video element and a double indirection" when in fact
it does no such thing.

* The URL proposal misrepresents both the meaning of R8 (No link
duplication) and how the IDREF proposal addresses this requirement. It
again erroneously includes sample markup not advocated by the IDREF
proposal. (It correctly asserts that this markup, erroneously
attributed to the IDREF proposal, contains a duplicate link.)

Fortunately, this markup pattern is not advocated by the IDREF
proposal. The markup actually advocated by the IDREF proposal for such
a case would be like the following:

<video poster="poster.jpg" controls transcript="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<iframe src=transcript.html id=transcript>

As you can see, there is no link duplication.

* In R9 (Multiple transcripts), the URL proposal again misrepresents the
sorts of markup patterns advocated by the IDREF proposal, in the same
way as before (by including redundant <a> elements inside the <video>
fallback content, which in turn point to elements elsewhere on the
page).

Either the UA provides the ability to directly access multiple
transcripts, or the UA only provides the ability to access one
transcript, from which the author might provide access to other
transcripts. The IDREF proposal allows for both UA-provided and
author-provided transcript selection; the URL proposal does not make
UA-provided transcript selection possible.
Laura Carlson
John Foliot

2. Objections to the Change Proposal to introduce a @transcript attribute that contains a list of one or more ID references

We have a Change Proposal that proposes to introduce a @transcript attribute on HTML5 media elements that contains a list of one or more ID references. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to introduce a @transcript attribute that contains a list of one or more ID references
Janina Sajka
Theresa O'Connor
Laura Carlson
John Foliot See
http://lists.w3.org/Archives/Public/public-html/2012Jul/0220.html

3. Objections to the Change Proposal to defer ISSUE-194 until HTML.next.

We have a Change Proposal that proposes to defer ISSUE-194 until HTML.next. If you have strong objections to adopting this Change Proposal please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to defer ISSUE-194 until HTML.next.
Janina Sajka The HTML-A11Y Task Force has resolved objection to the Zero Change Proposal on Issue-194 without objection as recorded at:
http://lists.w3.org/Archives/Public/public-html-a11y/2012Jul/0065.html
The Task Force RESOLUTION reads: "The TF opposes the Zero Change Proposal offered on Issue-194 because a
transcript is important to satisfy disability alternative media requirements
for persons with disabilities as described in the TF's Media Accessibility User
Requirements." The relevant section of the TF's Media Accessibility User Requirements document can be found at:
http://www.w3.org/TR/media-accessibility-reqs/#transcripts
Theresa O'Connor
Laura Carlson I strongly object to the postpone and defer ISSUE-194 to a bridging technology approach because HTML5 provides native, semantic, programmatically determinable elements for audio and video content. HTML5 should equally provide a native, semantic, programmatically determinable mechanism to make the content of those elements accessible to people with disabilities. Currently it does not. Native, semantic, programmatically determinable elements and attributes provide a higher level of communication. Communication is pretty much the point of language design. Lay people consuming audio/video content may never get that additional communication, supplied by a new attribute but machines can. Providing that extra meaning will allow machines to utilize it for people with disabilities.

As the Accessibility Task Force said in its objection to this proposal "a transcript is important to satisfy requirements for people with disabilities". [1] For example, blind-deaf users require a non-time-based programmatically determinable transcript, which they can read at their own pace. Some people with cognitive or learning disabilities require a programmatically determinable transcript because it is impossible for them to follow synchronized captions.

Not fulfilling requirements [2] and use cases is a dereliction of duty and a charter violation. Our charter states, "The HTML Working Group will cooperate with the Web Accessibility Initiative to ensure that the deliverables will satisfy accessibility requirements". The URL proposal from the Media Subgroup of HTML Accessibility Task Force [3] provides native semantics and satisfies requirements. This proposal [4] does not.

We have the opportunity to fix Issue 194 natively in HTML5 now. Shirking off our responsibility to some unknown time in the future would be a disservice. Moreover the proposed use of aria-describedby does not fulfill the need for off-page transcripts as it does not work correctly on links [5], which would unduly hamper authors.

--
[1] http://lists.w3.org/Archives/Public/public-html-a11y/2012Jul/0065.html
[2] http://www.w3.org/WAI/PF/media-accessibility-reqs/#transcripts
[3] http://www.w3.org/html/wg/wiki/ChangeProposal/ISSUE-194/TranscriptURL
[4] http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange
[5] "Currently aria-labelledby and aria-describedby are only robustly supported for associating text content to a subset of interactive content elements, they do not work correctly on links, support on embedded content is unknown..." - Steve Faulkner, June 19, 2012.
http://www.paciellogroup.com/blog/2012/06/html5-accessibility-chops-using-aria-notes/
John Foliot

More details on responses

  • Janina Sajka: last responded on 25, July 2012 at 02:30 (UTC)
  • Theresa O'Connor: last responded on 26, July 2012 at 16:09 (UTC)
  • Laura Carlson: last responded on 26, July 2012 at 19:18 (UTC)
  • John Foliot: last responded on 29, July 2012 at 13:38 (UTC)

Everybody has responded to this questionnaire.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire