Re: New Draft: Please Review

Comments on section 2, 3 and 4.

>    * 2 Ensure Content Produced by the Tool is Accessible
>         o 2.1 Generate standard markup [Priority 1]
>         o 2.2 Support all accessible content recommendations [Priority 1]
>         o 2.3 Emphasize accessible authoring practices [Priority 1]
>         o 2.4 Identify all inaccessible markup [Priority 1]
>         o 2.5 Provide mechanisms for authors to add missing alternative
>           representations for the content of converted documents
>           [Priority 1]
>         o 2.6 Provide comprehensive accessibility help to authors
>           [Priority 1]
>         o 2.7 Package multimedia files with pre-written descriptions
>           [Priority 2]
>         o 2.8 Offer text representations of site maps
>         o 2.9 Integrate accessibility solutions into relevant automated
>           tools and wizards [Priority 1]
>         o 2.10 Allow the user to check for and correct accessibility
>           problems automatically [Priority 1]
>         o 2.11 Ensure that all markup inserted by the authoring tool is
>           accessible [Priority 1]
>         o 2.12 Ensure that conversion tools produce and retain accessible
>           markup and content [Priority 1]

I already posted my preferred section 2 using a more concise TOC.
see http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0000.html


>    * 4 Promote Accessibility
>         o 4.1 Provide rationales that stress Universal Design [Priority 1]
>         o 4.2 Promote accessibility in all Help examples [Priority 3]
>         o 4.3 Provide the author with progress feedback [Priority 3]

I would suggest either to fold this section in 2 or to have it include 
what's already in 2: 
  2.6 Provide comprehensive accessibility help to authors
and to a lesser extent:
  2.9 Integrate accessibility solutions into relevant automated
           tools and wizards
This is all about Documentation to make sure content produced by the
tool is accessibleand so I think it really belongs in 2, under ONE
heading guideline:
  Provide comprehensive accessibility documentation to authors

>    * 5 Sample Implementations
>         o 5.1 Alt-Text for the HTML 4.0 IMG Element
>         o 5.2 Tool: "Alt"-text registry
>    * 6 Terms and Definitions
>         o 6.1 Integrated Author Guidance and Prompting
>         o 6.2 Alert Techniques
>         o 6.3 Markup Editing Tools and Functions
>         o 6.4 Documents, Elements, and Attributes
>         o 6.5 Accessibility Terms
>         o 6.6 Alternative Representation of Content
>         o 6.7 Inserting and Editing
>         o 6.8 Alert Techniques
>         o 6.9 Selection, Focus, and Events

Make these two non-normative annexes.

> 1.1 Guideline Priorities
 
> This document also refers to guidelines and techniques defined in the WAI
> Page Author Guidelines and to priorities assigned to them (indicated, for
> example, by [Page-Author-Priority 1]).

Any reason why we don't use the model of guideline, checkpoint,
technique used in PA ?
 
> 2.1 Generate standard markup [Priority 1]
> 
> The first step towards accessibility is interoperability. Authoring tools
> should ensure that content is created in accordance with W3C specifications

checkpoint/technique: validate with validator.w3.org, css validator.
checkpoint: list them all: HTML, CSS, MathML, XML, SMIL, PICS, etc

> (or other standards when applicable).

What do we have in mind here ? Java, EcmaScript, VRML, Shockwave ?
Since we don't have PA for these, what are we going to say ? We could
say, refer to their own accessibility guidelines, and if there is
none, say just don't use ?

 
> Mechanisms that can be employed by authoring tools to support accessible
> authoring practices are discussed in Section 5.

Pointer to Section 5 looks broken.
 
> 2.3 Emphasize accessible authoring practices [Priority 1]

(in addition to my earlier message about overall structure of section 2)
I wonder in which way this isn't a superset of "2.2 Support all
accessible content recommendations." If one needs to emphasize, one
needs to support.

> [Technique: 2.5.1] [Priority 1]
>      The author must be prompted, on a configurable schedule, to provide
>      "alt"-text for images, image maps, and image map links.
> [Technique: 2.5.2] [Priority 1]
>      The authoring tool must never insert rule-generated description text
>      into the document (default "alt"-text) or a properties field
>      (place-holder "alt"-text). Automated processes may place pre-authored
>      (by a person) text when the meaning or function of the described object
>      is known with certainty.
> [Technique: 2.5.3] [Priority 1]
>      The author must be prompted to provide captioning or transcriptions for
>      any video or audio segments.
> [Technique: 2.5.4] [Priority 3]
>      The author should be given the option of providing a long description
>      for any graphic element.

To give water to my argument for why a 2.5 is not needed, these
technique are applicable to native editing as well, not just
conversion time.
 

> 2.7 Package multimedia files with pre-written descriptions [Priority 2]
 
> Techniques:
 
I'd add "remembering description of the same image/sounds/etc", under
pre-written (already written once, by the author)

> [Technique: 2.8.1] [Priority 1]
>      Allow the author to display the site map in text form (e.g., as a
>      structured tree file).

If it's to "publish" the site map, then it should be included in other
guideline, if it's for accessibility of the environment, then it
should be mentioned there (I think it is already)

> [Technique: 2.12.2] [Priority 1]
>      Authoring tools must never remove or modify structure or content that
>      is necessary for continued accessibility.

We need to talk about the issue of a tool wanting to generate HTML
valid for the HTML 3.2 spec, and therefore needing to remove longdesc, 
table stuff, etc, on the ground that they are only in HTML 4. 

Maybe we should say that HTML 4 stuff should never be removed and
that's it's a fallacy to want to be compliant with older HTML
releases.

> 3.1 Ensure that users may configure accessibility mechanisms
> [Priority 1] In supporting the creation of accessible Web content,
> authoring tools must take into account the differing authoring
> styles of their users. Some users may prefer to be alerted to
> problems when they occur, whereas others may prefer to perform a
> check after the document is completed. This is analogous to
> programming environments that allow users to decide whether to check
> for correct code during editing or at compile time.

This is not about an accessible environment, is it ? This is usability 
and it needs to be good so that things in section 2 are adopted.

> 3.2 Integrate accessibility solutions naturally [Priority 2]

same thing
 
> 3.3 Provide optional views of the edited document
> 
> When creating or editing a Web page the desired ultimate rendering of the
> page may not be optimal for creating and editing.
> 
> Techniques:
> 
> [Technique: 3.3.1] [Priority 1]
>      The authoring tools should support at least two views:
>        1. an authoring/editing view
>        2. a publishing or browser view, (similar to the normal and page view
>           or print preview of popular word processors).

same thing, in fact, this is a P2 in section 2 in the area of checking 
accessibility.

> [Technique: 3.3.2] [Priority 1]
>      In the authoring/editing view, the font size, letter and line spacing,
>      and text and background color should be independent of the final format
>      of the document.

this one is really about accessibility of the environment.
 
> 3.4 Offer text representations of elements
> 
> Graphically represented elements cannot be identified by third-party
> assistive technologies that translate text to Braille, speech, or large
> print. Some authoring tools display the start and end tags as graphics.
> 
> Techniques:
> 
> [Technique: 3.4.1] [Priority 1]
>      Allow the author to display tags in a text format.
> [Technique: 3.4.2] [Priority 1]
>      To help distinguish the start or end tag from the remainder of the

same here. Overall, since the bulk of accessibility of the environment 
will be somewhere else, I still think this should be an annex in this
document.

Received on Thursday, 7 January 1999 13:03:22 UTC