- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 22 Jun 1999 00:59:42 -0400 (EDT)
- To: Dick Brown <dickb@microsoft.com>
- cc: w3c-wai-au@w3.org
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