- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 9 Aug 1999 13:42:17 -0400 (EDT)
- To: WAI AU Guidelines <w3c-wai-au@w3.org>
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