Re: Sample techniques for a video editor

Here it is again, with the checkpoint text included, to make life a bit
easier.

(For the next working group draft of the techniques document I will include
the text of checkpoints in each sample implementation piece, so we can see if
it is easier to read or too cluttered)

Charles

A Hypothetical Multimedia Editor

SMILey - a hypothetical video and audio editor, which is triple-A conformant
to the Authoring Tool Accessibility Guidelines:

1.1 Use all applicable operating system and accessibility standards and
conventions (Priority 1 for standards and conventions which are essential to
accessibility, Priority 2 for those that are important to accessibility,
Priority 3 for those that are beneficial to accessibility). [Priority 1] :
SMILey 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 Allow the author to change the editing view without affecting the
document markup. [Priority 1] : SMILey uses SMIL to separate audio, video,
descriptive signing and text tracks.

1.3 Render an accessible equivalent of each element property. [Priority 1] :
The author can display the filename, and can read all metadata for each
multimedia segment.

1.4 Allow the author to edit all properties of each element and object in an
accessible fashion. [Priority 1] : 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 Ensure the editing view allows navigation via the structure of the
document. [Priority 1] : SMILey allows navigation of the SMIL structure.

1.6 Enable editing of the structure of the document. [Priority 2] : 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 Use applicable W3C Recommendations. [Priority 2] : SMILey is primarily a
SMIL editor. It imports various formats for images, audio, video, and text.

2.3 Ensure that document language used enables accessibility of content.
[Priority 1] : SMILey implements SMIL to allow multiple paralell tracks,
providing support for medium-independent rendering.

3.1 Implement all accessible authoring practices that have been defined for
the markup language(s) supported by the tool. [Priority 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 Produce content that conforms to the W3C's Web Content Accessibility
Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A conformance, Priority 2
for double-A conformance, Priority 3 for triple-A conformance] : SMILey
splits audio, video, and text layers into separate tracks, with appropriate
system-variables, to allow them to be rendered seperately.

3.3 Ensure that templates provided by the tool conform to W3C Web Content
Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A
conformance, Priority 2 for double-A conformance, Priority 3 for triple-A
conformance] : SMILey provides a sample presentation made available by a
third party to demonstrate accessible design of multimedia.

3.4 Preserve all accessibility content during transformations and
conversions. [Priority 1] : SMILey keeps all the elements of imported
presentations.

4.1 Prompt the author to provide alternative content (e.g., captions,
expanded versions of acronyms, long descriptions of graphics). (Priority 1
for alternative content that is [Web-Content-Priority-1], Priority 2 for
alternative content that is [Web-Content-Priority-2], Priority 3 for
alternative content that is [Web-Content-Priority-3]) : 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 Provide pre-written alternative content for all multimedia files packaged
with the authoring tool. [Priority 2] : The example document supplied with
SMILey includes multiple content types - text captions, audio description,
etc.

4.3 Provide a mechanism to manage alternative content for multimedia objects,
that retains and offers for editing pre-written or previously linked
alternative content. [Priority 3] : SMILey uses RDF metadata to associate
multiple tracks. It can interrogate the RDF store.

4.4 Do not insert automatically generated (e.g., the filename) or
place-holder (e.g., "image") equivalent text, except in cases where
human-authored text has been written for an object whose function is known
with certainty. [Priority 1] : 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 Make generation of accessible content a naturally integrated part of the
authoring process. [Priority 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 Ensure that the highest-priority accessible authoring practices are among
the most obvious and easily initiated by the author. [Priority 1] : SMILey
always prompts the author for accessibility features. Turning this off is
possible via an "advanced" options menu

6.1 Check for and alert the author to accessibility problems. (Priority 1 for
accessibility problems that are [Web-Content-Priority-1], Priority 2 for
accessibility problems that are [Web-Content-Priority-2], Priority 3 for
accessibility problems that are [Web-Content-Priority-3]) : SMILey checks for
missing information each time changes are made to the document, and at save
time.

6.2 Allow users to control both the nature and timing of accessibility
alerts. [Priority 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 Assist authors in correcting accessibility problems. (Priority 1 for
accessibility problems that are [Web-Content-Priority-1], Priority 2 for
accessibility problems that are [Web-Content-Priority-2], Priority 3 for
accessibility problems that are [Web-Content-Priority-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 Allow the author to override any removal of unrecognized markup.
[Priority 2] : 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 Provide the author with a summary of the document accessibility status on
a configurable schedule. [Priority 3] : SMILey highlights tracks which do not
appear to have full alternative versions through prpoperties defined in the
user stylesheet, which can also be applied to the source mode.

6.6 Allow the author to perform tag transformations. [Priority 3] : SMILey
allows conversion between switch and par elements, enabling the author to
specify whtehr tracks should be played all together or only as alternatives
to each other.

7.1 Integrate accessible authoring practices in all applicable help topics.
[Priority 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 Explain the accessible authoring practices supported by the authoring
tool. [Priority 1] : 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 Do not use inaccessible markup in examples. [Priority 1] : SMILey help
has many examples, all of which use standard markup and conform to the Web
Content Accessibility Guidelines [WAI-WEBCONTENT].

7.4 Emphasize the universal benefit of accessible design. [Priority 3] :
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 13:42:18 UTC