- 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>
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 UTC