Re: Multimedia tools bullet in Scope section (1.1)

To the extent that an image editor is used to put content on the web (and I
do it all the time) it is an authoring tool. I agree that many of these tools
are unlikely to meet the requirements. I think that is a shame, but a
short-term inevitability. But I also think it is important that we begin to
lay out what is necessary if somebody does want to make an accessible image
editor tomorrow. After all, there is nothing much to stop them as far as I
can see, and the line between what is a Web page and what is an image is
often very blurred already, at least in people's perception (for example
there are tools which generate "web content" which is really made from
images, including the text in the image). I have therefore written up an
example of how such a tool might meet all the guidelines, to achieve triple-A
conformance. I think everything I am describing is in fact available already,
but not necessarily all in the same tool.

I propose that the following example is incorporated as a 'sample
implementation in the techniques appendix', perhaps slightly edited.

MyTool - a hypothetical image editor, which is triple-A conformant to the
ATAG:

1.1 Follow standards and conventions:
  MyTool does this. It provides magnification, uses standard APIs for all
controls

1.2 Allow changes in the editing view
  MyTool provides remapping of colours via a style sheet so you don't
need to see a colour to use it - you can address it by any of 3 schemes.

1.3 Allow the author to display an editable equivalent
  The author can display the filename, can navigate by pixel and directly
edit the contents of each pixel as text descriptions of its state

1.4 Enable navigation via structure
  MyTool allows the author to build an image of component parts, placed in
layers. These layers can be named and navigated.

1.5 Enable editing of the structure
  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 W3C recommendations
  MyTool supports png and WebCGM as well as gif, jpeg, tiff, bmp, eps, etc.
The next version will implement full SVG support...

2.2 Extensions to W3C DTDs must not be inaccessible
  MyTool implements standards exactly as written, so this is not applicable.

3.1 Implement accessible authoring practices
  MyTool attempts to include as much information as possible with each image.
For formats which allow it, text entered into an image is also included as
annotation or title content.

3.2 Conform to WCAG
  MyTool produces images which have as much equivalent content available as
possible, and where the format allows, it enables colour and size control (eg
SVG)

3.3 Ensure templates conform to WCAG
  MyTool provides some standard clip-art, which has associated names and
descriptions for use in layered image construction (see 1.2 - 1.5, 4.5)

3.4 Preserve all accessibility content during transformations
  MyTool takes all metadata included in an image, and where it cannot be
included as part of the image format, supplies it with the image (see also
4.1, 4.4, 4.5)

4.1 Prompt the author for alternative content
  MyTool prompts the author to give a name and description for each image or
layer when it is saved. This option is available at any time.

4.2 Prompt the author for missing structural information
  MyTool prompts the author for a brief description of hte role of each image
or layer at save time, or when layers are merged. This can be done by the
author at any time

4.3 Allow the author to edit alternative content and structural information
  MyTool makes this available through its User Interface - similar to an HTML
input or textarea element

4.4 Provide pre-written alternative content for all multimedia packaged
  MyTool does this

4.5 Provide a mechanism to manage alternative content
  MyTool provides a databse system for managing images and layers and
associating metadata which is saved for future use.

4.6 Do not insert default alt-text unless the purpose is known
  MyTool offers default text where it exists, as an editable option. If it
has not been used before, MyTool prompts the author to confirm the use of
this default text.

5.1 Ensure highest-priority practices are most visible
  MyTool always prompts the author for accessibility features. Turning this
off is possible via an "advanced" options menu

5.2 Make accessible content integrated
  Accessiblity features are always available in relevant dialogs. The useer
interface includes a metadata menu at the top level, and on the button bar,
for easy addition of metadata at any time.

6.1 Check for accessibility problems
  MyTool checks for missing information at save time, or when layers are
about to be merged (see also 3.1, 3.2)

6.2 Allow users to control alerts
  MyTool allows the user to specify that alerts should occur at save time
only, or also when moving between images/layers, and/or also when moving
between tool palette functions

6.3 Assist authors in correcting problems
  MyTool 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 When removing unrecognised markup, alert the author
  MyTool provides an alert if it opens an invalid document, and the author
can cancel attempted repair or undo it afterwards. MyTool also alerts the
author when saving to a format which results in a loss of built-in accessible
content.

6.5 Provide a summary of accessibility status
  MyTool higlights alyers or images which do not have names, descriptions or
structural role information through the use of icons which have textual
equivalents available

6.6 Allow the author to perform tag transformations
  MyTool allows the transformation of layers, by combining or splitting, with
prompting for which metadata goes with which part of a split layer

7.1 Integrate accessible authoring into help
  MyTool Help pages have naming and describing images as part of the process
of creating them. THe discussion of layers (which is promoted as a good way
to do images) includes discussion of giving structural role information, and
what kind of information is required. All help contains numerous examples of
how to do the process.

7.2 Explain the accessible practices supported by the tool
  In addition to having the relevant accessibility practices as part of the
normal help, MyTool has a help topic called accessibility of images.  All
relelvant topics are available in both places

7.3 Do not use inaccessiboe markup in examples
  MyTool help has many examples, all of which are wonderfully constructed.

7.4 Explain the benfits of universal design
  MyTool help explains that structured images are eaasier to re-use, and can
be easily optimised for a variety of situations - low bandwidth/high
bandwidth, text-only editing, etc.

On Fri, 18 Jun 1999, Dick Brown wrote:


  During our conference call 6/16/99 I had some comments on 1.1 -- Scope of
  these Guidelines and was asked to post them.
  
  The intro of the section says:
  
  "These guidelines are intended to be used by developers of all tools used to
  produce content for the Web. These include:"
  
  The fourth bullet says:
  
  "Tools that produce multimedia, especially where it is intended for use on
  the Web (e.g., video production and editing suites);"
  
  Specifically, I am concerned that the wording of this bullet extends the
  scope to applications that aren't in our purview, such as Paint or an image
  editor.
  
  I can understand that it makes sense to include applications such as video
  editors that produce content which can be more or less be "plugged into" a
  Web page. There may be little opportunity for the page author to use the
  authoring tool to enhance/ensure the accessibility of that content. So, it
  makes sense for the guidelines to include the tool that produces the
  content.
  
  However, it's generally different with multimedia content such as JPEG or
  GIF images. An author can add ALT text, and so on, with the page authoring
  tool.
  
  I suggest we add language so that the bullet specifically applies to content
  that is little affected by authoring tools.
  
  I think Wendy had some good suggestions as the wording, possibly including
  "standalone."
  
  Dick Brown
  User Assistance Manager for Accessibility -- Microsoft
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Tuesday, 22 June 1999 00:59:50 UTC