- From: Carlos A Velasco <velasco@fit.fraunhofer.de>
- Date: Mon, 14 Jan 2002 17:56:44 +0100
- To: Jan Richards <jan.richards@utoronto.ca>
- Cc: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Hi Jan, I believe that addressing the techniques by functionality is a good decision, although you have seen is tricky. I have some comments. 1) "Direct and direct" as pointed by Charles, are not common terms. I would name the category "Document markup creation". I would split the categories in WYSIWYG editors and direct editors. I also would include here: HTML, xHTML, XML, XSL, XSLT and CSS editors, and remove XML from 5. Also, I think that the inclusion here of multimedia, just because of editing directly the code is kind of artificial. I would leave that in the second category. 2) Here I would include any multimedia, also SMIL, SVG, etc. 3) As examples in 3, you might include Portal tools, for example. 4) In 4 I would include Javascript, PHP, ASP, VBscript (any script in general), Java (applets), etc. and move X()ML to 1). Like you point out, here shall go any proprietary format: Flash, Director, etc. Regards, carlos Jan Richards wrote: > In yesterday's conference call it was decided to define the technique > categories as tool functionality types rather than tool types. The > following includes this change as well as proposed re-wordings of the > category descriptions. Pay special attention to my attempt to split > Multimedia editors from markup editors according to the human > readability of the formats they produce. Does this work? I would welcome > more examples for the different categories. > > > Categories of Authoring Tool Functionality > > The Authoring Tools Accessibility Guidelines (ATAG) have been formulated > to apply across a diverse range of software products that produce Web > content. To accomplish this, the guidelines and checkpoints have been > stated fairly generally. To offset this generality, the implementation > techniques (in this document) have been formulated to be more specific, > at the cost of reducing the applicability of individual techniques to > all authoring tools. > > In order to simplify the task of determining which techniques are > applicable to a particular authoring tool, five categories of authoring > functionality have been defined. It is important to note that the > categories refer to authoring functionality rather than complete > authoring tools. This allows different aspects of a given tool to fall > within different functionality categories. For example, an HTML > authoring tool may feature a WYSIWYG markup editor (Category 1: Markup > editing functionality), a javascript editor (Category 4: Programming > functionality), and the ability to import word-processed documents > (Category 5: Conversion functionality). > > Each category has an associated icon that will label those techniques > that are likely to apply to products that include functionality in that > category. Keep in mind, however, that the categories are intended as a > guide, rather than a last word in compliance. Some techniques that are > flagged by a category icon might not be relevant to a tool with > functionality in that category, while other unflagged techniques, may in > fact be relevant. To avoid missing relevant techniques, it is > recommended that developers take the time to, at least briefly, consider > all the techniques in this document. > > > Category 1: Markup Editing Functionality > > These are tool functions that authors use to specify content and its > presentation. These include: > > - Direct (text-based.) and indirect (WYSIWYG, object-based, etc.) > editing of documents in markup formats (i.e. HTML, XHTML, etc.). This > includes indirect editing by word processors that are capable of saving > as markup formats (i.e. HTML, XHTML, etc.). > > - Direct and indirect editing of multimedia (images, animation, sound, > video, haptics) content in human-readable formats (i.e. SVG, SMIL, > etc.). > > > Category 2: Multimedia Creation Functionality > > These are tool functions that authors use to create Web content in > non-human-readable multimedia formats. These include > > - Indirect editing of multimedia (images, animation, sound, video, > haptics) content in non-human-readable formats (i.e. JPEG, PNG, > Quicktime, Flash, etc.). > > > Category 3: Content Management Functionality > > These are tool functions that create and organize Web content on the > basis of high-level author input. These include: > > - Database driven Web applications that prompt the author for > information that is then displayed in a generic (or semi-generic) manner > (i.e. courseware). Note that any direct or indirect authoring of the > final markup (i.e. editing presentation templates) is considered to be > markup editing functionality (see category 1). > > > Category 4: Programming Functionality > > These are tool functions that authors use to create Web application > code. These include: > > - Direct or indirect editing of program code (i.e. Java applets, Flash > action script, server and client-side scripts, etc.). > - Direct or indirect editing of markup languages grammars (i.e. XML > languages). > - Direct and indirect editing of style sheets (i.e. CSS). > > > Category 5: Conversion Functionality > > These are tool functions that convert content in one format into another > format. These include: > > - Converting word processor-formatted content into a markup format as it > is imported into an editor. Note that any direct or indirect authoring > of the converted markup, image, etc. is considered to be markup editing > functionality (see category 1). > - Saving multimedia content in other formats (i.e. bitmap saved as a > jpeg, etc.). > > -- Dr Carlos A Velasco mailto:velasco@fit.fraunhofer.de http://access.gmd.de/ Fraunhofer-Institut für Angewandte Informationstechnik (FIT.HEB) [Fraunhofer Institute for Applied Information Technology (FIT.HEB)] Schloss Birlinghoven, D53757 Sankt Augustin (Germany) Tel: +49-2241-142609/319272 Fax: +49-2241-142065
Received on Monday, 14 January 2002 11:56:27 UTC