- From: Andrew Kirkpatrick <andrew_kirkpatrick@wgbh.org>
- Date: Mon, 08 Sep 2003 11:36:56 -0400
- To: w3c-wai-gl@w3.org
- Cc: Joe Clark <joeclark@joeclark.org>
A couple of quick comments on Joe Clark's comments <http://joeclark.org/f2f/?GL> on WCAG 2.0 Public Draft: Under "Deficiency Report: 1) Checkpoint 1.1: I agree with Joe's concern over the use of the word "significant". This checkpoint should emphasize the importance of all dialog and sound effects being captioned. 2) Response to captioning implementation issue in Joe's comments: Joe wrote: "There is no reliable way to produce online closed captions, using media playersı scripting or text formats, that works in the real world. Magpie and similar SMIL/SAMI generators are not production-ready." This is listed as an implementation issue under the subheading "Real-Time Video". The statement that there is no reliable way to produce online closed captions is false. Captions can be delivered for Real and Windows media open or closed very reliably. This can be done for both real-time and off-line (not live) projects. It is done very infrequently for live broadcasts, but is reliable when done. The obstacles to live closed captions seem to be budgetary rather than technical. Regarding MAGpie and other SMIL/SAMI generators, I'm not sure how that fits in here. MAGpie is not designed as a tool for real-time captioning, so it is certainly not production-ready for that task. However, with regard to off-line captioning, there are a number of tools that can be used to create closed captions for a variety of media types. Depending on the definition of "production-ready", you might or might not consider tools like MAGpie and HiSoftware's HiCaption "ready". These tools are used in production environments. In addition, a variety of "Production" tools (including the one used by the Media Access Group here at WGBH) are capable of delivering text tracks for different media formats. Under "Recommendations": 3) Joe wrote: Itıs unrealistic to expect authors to caption all their videoclips right away. i. They donıt have the expertise and certainly should not be encouraged to guess or dabble. It may be unrealistic to expect, but it is important to set the bar on what accessible means with regard to multimedia content for people who can't hear. WCAG 2.0 should not set phase-in percentages; that should be left to a legislative interpretation. Dabbling should be encouraged. People learn from bad examples as much as good ones, and bad captions are usually better than no captions. Large productions tend to outsource or hire trained captioners because of the efficiencies of the work being done by a professional. These comments also apply to audio description, although it is certain that fewer people will dabble at audio description than captioning. 4) On transcription: "Transcription is not the way to make video accessible. The correct accessibility methods are captioning and audio description." It is important to keep transcription on the table. A deaf-blind person doesn't benefit from audio description unless there is a text transcript that includes the audio description text. Caption and audio description production can include an additional step to output such a transcript. 5) On collated text transcripts: "A ³combined² caption transcript plus audio-description script has been attempted exactly once in known history (for a demonstration project that was never completed). There is no method to combine those two sources due, among other reasons, to a lack of interchange formats. The idea is a non-starter." Previous attempts are probably not too relevant here. This is easy to do and is important for deaf-blind users. There is no post-production method for combining the CC and AD sources, but it can be accomplished using MAGpie's XML project file and XSLT. This is not a built-in feature of MAGpie at this time, but a method exists. 6) Under "original Web content": "Live video and audio presentations should require captioning or description only if the source is already captioned or described. Adding real-time captions is an onerous process online, reliant on proprietary JavaScript methods; itıs also expensive. Live description has almost never been attempted." This comes back to the practicality of Real-time web captioning. It is possible and practical, and doesn't require proprietary javascript methods. It is expensive, but it is hard to find any time-sensitive skilled labor that isn't. AWK -- Andrew Kirkpatrick CPB/WGBH National Center for Accessible Media 125 Western Ave. Boston, MA 02134 E-mail: andrew_kirkpatrick@wgbh.org Web site: ncam.wgbh.org 617-300-4420 (direct voice/FAX) 617-300-3400 (main NCAM) 617-300-2489 (TTY) WGBH enriches people's lives through programs and services that educate, inspire, and entertain, fostering citizenship and culture, the joy of learning, and the power of diverse perspectives.
Received on Monday, 8 September 2003 11:35:49 UTC