- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Fri, 07 Sep 2007 12:48:24 -0400
- To: WAI-AUWG List <w3c-wai-au@w3.org>
Continuing my glossary review I've been looking at the interplay between the definitions of "authoring tool", "authoring tool user interface", "editing view" and "technology". Basically, I think that since "authoring tool user interface:content display" covers rendered and non-rendered views some important distinctions are lost. Also I don't think the code-level/WYSIWYG/object-oriented/guided breakdown is working. I have several inter-connected proposals for fixing this: ------------- PROPOSAL 1: Move the examples of authoring tools back up from "Editing Views" into the definition for "Authoring Tools": Definition of authoring tool This section is *normative.* ATAG 2.0 defines an "authoring tool" as any software, or *collection of software components*, that *authors* use to create or modify *Web content* for *publishing*. This definition covers a wide range of products including: - plain text editors - WYSIWYG editors - productivity software that can output Web content technologies - content management systems - site management tools - courseware tools - blogging tools - content aggregators - conversion tools - model-based authoring tools - wikis - etc. ------------- PROPOSAL 2: Overhaul the definition of "Editing Views", including the types (code-level, WYSIWYG, object-oriented, guided) and merge with "preview" into "view": view - also called viewport *User interface* functionality that *authors* use to interact with the *content* being edited. Authoring tools often have two types of views: 1. Editing View Views that both present the content to authors and allow authors to make modifications to the content. There are several broad approaches to presenting content for editing, which may be combined: (a) Instruction Level: Authors work with non-rendered instructions for the content being edited (e.g., HTML markup). Examples include plain text editing views as well as form-based editing views that provide direct access to the instructions (e.g., selecting attribute values). (b) Content Renderings: Authors work with content that is fully or partially rendered, played, or executed. *Partial renderings* occur when only some aspects of the content are rendered, played, or executed. For example, a frame-by-frame video editor may render the graphical aspects, but not the temporal aspect of a video. Some renderings are *WYSIWYG* because they closely resemble the appearance and behavior that a *user agent* would produce (e.g., an HTML editor that displays rich text, images, tables, etc.), while others are non-WYSIWYG because they differ from those produced by user agents (e.g., a graphical wavefront editing view of an audio file). (c) Meta-Content: Authors work with higher-level or abstract information that the authoring tool interprets to generate the resulting *content*. For example, a content management system that allows authors very limited control (e.g, toggling on/off, setting colors) over it's built-in content modules (e.g. stock ticker, calendar). 2. Preview: A non-editable view in which the content being edited is rendered, played, or executed as it would in a *user agent*. ------------- PROPOSAL 3: Modify the definition of "authoring tool user interface" to make use of "view". authoring tool user interface The display and control mechanism that *authors* use to communicate with and operate the authoring tool software. Authoring tool user interfaces may be *non-Web-based* or *Web-based* or a combination (e.g., a stand-alone markup editor with on-line help pages). Authoring tool user interfaces can be considered in two parts: 1. "Chrome": Any parts of the user interface that do not represent the content being edited. This includes: - user interface elements that surround, underlie, and/or super-impose upon editing views (e.g., text areas, menus bars, rulers, pop-up context menus). - user interface elements that are separate from the editing view (e.g. documentation) 2. Content Display: Any parts of a *view* that represent the content being edited. This includes: - plain text content (but not the containing text box control). - content renderings *Content Display Accessibility Exemption:* While Part A of ATAG 2.0 generally holds authoring tools responsible for providing accessible content displays, accessibility problems that are due to the existence of accessibility problems in the content being edited are exempt from the requirements. For example, if an author has not yet defined a text label for an image, it is permissible for a WYSIWYG rendering of that image to lack a label. ------------- Any thoughts? I can give a more detailed rationale for this on Monday's call. Cheers, Jan
Received on Friday, 7 September 2007 16:48:00 UTC