Plane Comments (take deux)

I already gave to Charles minor editorial bits.

Follow more clarification and content related things that I'd like to
add to the issues list for the meeting.

In the abstract

   Accessible Web content is achieved by encouraging
   authoring tool users to create accessible Web content (through
   mechanisms such as prompts, alerts, checking and repair functions,
   help files and automated tools), but also by ensuring that the
   automatic processes of the authoring tool generate accessible content.

This is a recurrent topic: to me, splitting up automatic processes
from regular authoring tool process is non-sense: it's all automatic
under the cover. This sentence confused me for 5 minutes and I bet
it's going to confused a lot more people for a lot more time.

This problem shows in other places in the document and we shouldn pay
attention to fix it.

  
      * 6 Terms and Definitions
          + 6.1 Integrated Author Guidance and Prompting
          + 6.2 Alert Techniques
          + 6.3 Markup Editing Tools and Functions
          + 6.4 Documents, Elements, and Attributes
          + 6.5 Accessibility Terms
          + 6.6 Alternative Representation of Content
          + 6.7 Inserting and Editing
          + 6.8 Alert Techniques
          + 6.9 Selection, Focus, and Events

Make that an alphabetical list and do not expand here: clutter to TOC.

  2.1 Generate standard markup
   The first step towards accessibility is interoperability.

A little more rationale to the effect of open standard = possible to
implement specialized tools, would be good.
   
   2.2.1: [Priority 1]
          Support all accessibility features that have been defined for
          the markup language(s) supported by the tool.
          
   Listing the accessibility features of specific languages lies beyond
   the scope of this document. However, an informative list of documents
   that address accessible Web authoring practices follows.

Kind of weird to say: support all X P1 but we don't give you X.
We need to discuss that at the face to face.

       
   Page Author Implementation Priorities: (The priorities placed on the
   accessibility markup solutions)
     * General: WAI Page Author Guidelines

Why is it here ? Sounds like same as just before.

       
   2.3 Ensure that all markup inserted by the authoring tool is accessible
   
   If markup is automatically generated, the author will be unaware of the

Same issue of automatic process or not. Guideline not needed.

   
   2.3.1: [Priority 1]
        Do not produce inaccessible markup.

The sentence itself could be folded in 2.2.1.

   2.4 Identify and allow the user to correct all inaccessible markup

Since this one is about checkers, I'd like to see this name or the
verb check  mentioned somewhere here.

   2.4.3: [Priority 1]
        Check existing documents when they are opened for editing.

Mention Save function as well. 

As always, modulo configuration setting.
(maybe this config blanket should be a generic statement)

   2.5.1: [Priority 1]
        Generate documents that respect the Web Content Accessibility
        Guidelines.

Another repeat.


We need to talk about the conflict issue with saying on one hand:
generate valid markup and on the other do not remove any accessible
markup, in the context of someone adding new markup not yet recognized 
by the tool at its level of validity. For the face-2-face.


   Checkpoints:
   
   2.6.1: [Priority 2]
        Include professionally written descriptions for all multimedia files
        packaged with the authoring tool.

I would add here the checkpoint about incremental alt registry (not
pre-written, already written)

   2.6.2: [Priority 1]
        Prompt the user, on a configurable schedule, to provide "alt"-text for
        images, image maps, and image map links.
   2.6.3: [Priority 1]
        Prompt the author to provide a caption or transcription for any audio
        segment.
   2.6.4: [Priority 1]
        Prompt the author to provide a caption or transcription for any video
        segment.
   2.6.5: [Priority 1]
        Allow the author to provide a long description for any graphic element.
   2.6.6: [Priority 1]
        Do not generate description text or insert place-holder text except
        human-authored description text when the meaning or function of the
        described object is known with certainty.

These do not belong here but in 2.1.

  
   3 Encourage Authors to Create Accessible Documents

I think a flatter structure with all the guidelines in one section
would be better. The way it is now, it looks at we split along
priority level in some arbitrary way.
   
   3.1.1: [Priority 1]
        Do not encourage or recommend those authoring practices discouraged by
        [Web-Content-Priority 1].

Another repeat (negative/negative)

   3.5 Ensure that users may configure accessibility mechanisms

I'd give much more visibility to this one. i.e. move it up in the list.
   
   If interruptive warnings are used provide a means for the author to quickly

if intrusive = interruptive, let's use one language only.

   2.5 Never remove existing accessible structure
        Implementation: The authoring tool has the capability of opening and
        converting word processor documents into HTML. If an image is
        encountered during this process, the user will be prompted for
        "alt"-text. The authoring tool sometimes makes changes to the HTML it
        works with to allow more efficient manipulation. These changes never
        result in the removal or modification of "alt"-text entries.

All the prompting stuff do not belong here.

   map link. Then, whenever one of these elements is inserted, the file name
   information of the object is checked against the registry association file.

"file name" should be "identifier" or something more generic (the alt
registry will probably not use the file extension for instance)

   6.2 Alert Checkpoints

confusing because Checkpoint is already use to mean something
different. Charles suggest just Alert which is fine.
   
   Unintrusive Alerts
        Unintrusive alerts are alerts such as icons, underlines, and gentle
        sounds that can be presented to the user without necessitating
        immediate action. for example, in some word processors misspelled text
        is highlighted without forcing the user to make immediate corrections.
        These alerts allow users to continue editing with the knowledge that
        problems will be easy to identify at a later time. However, users may
        become annoyed at the extra formatting or may choose to ignore the
        alerts altogether.

Need to rephrase as 3.5.3 says "cannot ignore".
   
   6.3 Markup Editing Tools and Functions
   
This one need rework.

I think there are:
   Authoring Tool (interactive markup editor)
   Word processor with save as html
   Conversion tool (batch/generation)
   Site Management
   Multi-media (image, video, timing)

Publishing tool and Automated Markup Insertion Function are really
confusing the picture and not relevant.

   Description Link (D-link)

I don't think we refer to d-link (we shouldn't anyway) so we don't need
this one.

Received on Thursday, 25 February 1999 12:36:16 UTC