Sample techniques for a video editor

Here is a first draft of a sample (hypothetical) implementation for a
video/audio editor which complies to the ATAG. I am proposing it for
inclusion in the techniques document. As well as the Authoring Tools Working
Group I have sent this to Philipp Hoschka, Chair of the SMIL group, who I
hope can give it a quick reality check with more knowledge of the field than
I have.

 A Hypothetical Multimedia Editor

   SMILey - a hypothetical video and audio editor, which is triple-A
   conformant to the Authoring Tool
   Accessibility Guidelines:
   
   1.1: MyTool follows the accessibility guidelines provided for the language
   the user interface is written in, and implements the accessibility
   features and APIs which are described in the reference literature for the
   platforms on which it is available.
   
   1.2: MyTool uses SMIL to separate audio, video, descriptive signing and
   text tracks.
   
   1.3: The author can display the filename, and can read all metadata for
   each multimedia segment.
   
   1.4: The author can edit all metadata for each component, and can edit a
   video frame by frame by using MyTool as a plugin through a text-based
   interface, as well as through a standard image manipulation user
   interface.
   
   1.5: SMILey allows navigation of the SMIL structure.
   
   1.6: While the image is layered, it is possible to make changes at the
   layer level. For animated GIFs, the author can directly edit the control
   structure, or use a simple graphical interface.
   
   2.1: SMILey is primarily a SMIL editor. It imports various formats for
   images, audio, video, and text.
   
   2.3: SMILey implements SMIL to allow multiple paralell tracks, providing
   support for medium-independent rendering.
   
   3.1: SMILey supports all access features in SMIL, and includes an RDF
   parser and generator to provide additional functions such as searching and
   more complex multiple tracks.
   
   3.2: SMILey splits audio, video, and text layers into separate tracks,
   with appropriate system-variables, to allow them to be rendered seperately.
   
   3.3: SMILey provides a sample presentation made available by a third party
   to demonstrate accessible design of multimedia.
   
   3.4: SMILey keeps all the elements of imported presentations.
   
   4.1: SMILey prompts the author to provide text captions, audio
   descriptions for video, and text descriptions of video to allow searching.
   The SMILey team are investigating the ability to provide music markup as a
   seperate track to facilitate re-presentation of soundtrack music.
   
   4.2: The example document supplied with SMILey includes multiple content
   types - text captions audio description, etc.
   
   4.3: SMILey uses RDF metadata to associate multiple tracks. It can
   interrogate the RDF store.
   
   4.4: SMILey interrogates its RDF database when a new track is added to
   suggest tracks which could be associated. The author must confirm these
   tracks before they are included.
   
   5.1: Accessibility features are always available in relevant dialogs. The
   user interface includes a metadata menu at the top level, and on the
   button bar, for easy addition of metadata at any time.
   
   5.2: SMILey always prompts the author for accessibility features. Turning
   this off is possible via an "advanced" options menu
   
   6.1: SMILey checks for missing information each time changes are made to
   the document, and at save time.
   
   6.2: SMILey allows the user to specify that alerts should occur at save 
   time only, also when moving between images/layers, and/or also when moving
   between tool palette functions
   
   6.3: SMILey has an easy prompt-driven interface for adding metadata, as
   well as fast
   keyboard-control and buttons for the power user. Context-sensitive help is
   always available.
   
   6.4: SMILey provides an alert if it opens an invalid document, and the
   author can cancel attempted repair or undo it afterwards. SMILey also
   alerts the author when saving to a format which results in a loss of
   built-in accessible content.
   
   6.5: SMILey highlights tracks which do not appear to have full alternative
   versions through properties defined in the user stylesheet, which can also
   be applied to the source mode.
   
   6.6: SMILey allows conversion between switch and par elements, enabling
   the author to specify whether tracks should be played all together or
   only as alternatives to each other.
   
   7.1: SMILey provides extensive documentation on how to generate multiple
   tracks for accessibility, including examples of what they should contain
   and how they should be included.
   
   7.2: In addition to having the relevant accessibility practices as part of
   the normal help, SMILey has a help topic called accessibility of images.
   All relevant topics are available in both places
   
   7.3: SMILey help has many examples, all of which use standard markup and
   conform to the Web Content Accessibility Guidelines [WAI-WEBCONTENT].
   
   7.4: SMILey help explains how multiple tracks allow for searching and
   indexing of timed presentations, as well as providing access to poeple
   with one or more disabilities to the full content of the presentation.

Received on Monday, 9 August 1999 12:56:38 UTC