Re Checkpoint 6.3

Here is my proposed guideline 6, with checkpoints and techniques - text
version below, html version (the links probably won't work) attached

Charles McCN


  Guideline 6. Provide methods of checking and correcting inaccessible content
  
   Many authoring tools allow authors to create documents with little or
   no knowledge about the underlying markup. To ensure accessibility,
   authoring tools must be designed so that they may automatically
   identify inaccessible content, and enable its correction even when the
   markup itself is hidden from the author.
   
   In supporting the creation of accessible Web content, authoring tools
   should take into account the differing authoring styles of their
   users. In general, authors will prefer to be able to configure their
   tools to support their working style. Tools that allow such
   configuration can help authors to feel that accessible authoring is a
   natural practise (see also the previous guideline) rather than a
   tiresome intrusion on their normal work pattern. For example 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.
   
   Note that valid markup is an accessibility requirement, particularly
   because it supports interoperability of assistive technologies (see
   also guideline 2 - Generate Standard Markup).
   
    Checkpoints:
    
   6.1 Check for and alert the author to accessibility problems.
          (Priority 1 for accessibility problems that are
          [1][Web-Content-Priority-1], Priority 2 for accessibility
          problems that are [2][Web-Content-Priority-2], Priority 3 for
          accessibility problems that are [3][Web-Content-Priority-3])
          
          + Highlight accessibility problems by applying an error class
            and allow the user to declare presentation rules in the local
            (user) style sheet, either through direct CSS editing or via
            a wizard or menu interface.
          + Highlight problems detected when documents are opened, when
            an editing or insertion action is completed, while an author
            is editing.
          + Allow users to choose different alert levels based on the
            priority of authoring accessibility recommendations.
          + If interruptive warnings are used, provide a means for the
            author to quickly set the warning to non-obtrusive to avoid
            frustration.
          + Where there is a change in the character set (or subset)
            used, prompt the author to identify whether there has been a
            change in language
          + Alert authors to accessibility problems when saving.
          + Access concerns can be highlighted using strategies similar
            to spell checking within a word processor. Access alerts
            within the document can be linked to context sensitive help.
          + A view that renders the document as it might appear without
            technologies such as style sheets and images enabled, or the
            ability to turn those features off and on in the editing
            view, will give an author some idea of whether a document's
            logical order has been correctly preserved, whether
            alternative text is appropriate, etc.
          + The WAI Evaluation and Repair group [4][WAI-ER] is developing
            a document that discusses which aspects of the Web Content
            Accessibility Guidelines can be automatically tested. A draft
            of that document is available [5][Auto-test].
            
   6.2 Assist authors in correcting accessibility problems. (Priority 1
          for accessibility problems that are
          [6][Web-Content-Priority-1], Priority 2 for accessibility
          problems that are [7][Web-Content-Priority-2], Priority 3 for
          accessibility problems that are [8][Web-Content-Priority-3])
          
          + Do this in a way that is consistent with the look and feel of
            the authoring tool.
          + Provide context sensitive-help for accessibility errors. See
            also [9]7 Promote accessibility in help and documentation
          + Where there are site-wide errors, to make correction more
            efficient the author can be given the choice to make
            site-wide changes or corrections. For example this may be
            appropriate for a common error in markup, but may not be
            appropriate in providing alt text that is appropriate for one
            use of na image but completely inappropriate for the other
            uses of the image on the same site (or even the same page).
          + Allow authors to control both the nature and timing of the
            correction process.
            
   6.4 Allow the author to override any removal of unrecognized markup.
          [Priority 2]
          Notes:
          
         1. The author may have included or imported markup that is not
            recognized by the tool, but which enhances accessibility.
         2. This need not be the default setting.
            
          + Provide options for the author to confirm or override
            removals on a change-by-change or as a batch process
          + Provide a summary of all automated structural changes that
            may affect accessibility.
          + Do not change the DTD without notifying the author.
            
   6.5 Provide the author with a summary of the document accessibility
          status on a configurable schedule. [Priority 3]
          
          + Provide a summary of accessibility problems remaining by type
            and/or by number.
            
   6.6 Allow the author to perform element transformations. [Priority 3]
          For example, to transform visually formatted elements to
          structure elements, or tables to lists.
          
          + Allow the user to define transformations for imported
            documents that have presentation, rather than structural,
            markup.
          + Allow the user to create style rules based on the formatting
            properties of an element, and then apply the rule to other
            elements in the document, to assist conversion of documents
            to the use of style sheets
          + Include pre-written transformations to rationalize multiple
            tables, and to transform (deprecated) presentation HTML into
            style sheets.
          + Remember that accessibility information, including attributes
            or properties of the elements being transformed, must be
            preserved - see [10]3.4
            
Techniques for this guideline:

     * Prompts can be used to encourage authors to provide information
       needed to make the content accessible (such as alternative textual
       representations). Prompts are simple requests for information
       before a markup structure has been finalized. For example, an
       "alt-text" entry field prominently displayed in an image insertion
       dialog would constitute a prompt. Prompts are relatively
       unintrusive and address a problem before it has been committed.
       However, once the user has ignored the prompt, its message is
       unavailable.
       Alerts warn the author that there are problems that need to be
       addressed. The art of attracting users' attention is a tricky
       issue. The way users are alerted, prompted, or warned will
       influence their view of the tool and their opinion of accessible
       authoring. See also [11]5 Integrate accessibility solutions into
       the overall "look and feel" .
       
        User Configurable Schedule
                A user configurable schedule allows the user to determine
                the type of prompts and alerts that are used, including
                when they are presented. For example, a user may wish to
                include multiple images without being prompted for
                alternative content, and then provide the alternative
                content in a batch process, or may wish to be reminded
                each time they add an image. If the prompting is done on
                a user configurable schedule they will be able to make
                that decision themselves. This technique allows a tool to
                suit the needs a wide range of authors.
                
        Interruptive Alerts
                Interruptive alerts are informative messages that
                interrupt the edit process for the user. For example,
                interruptive alerts are often presented when a user's
                action could cause a loss of data. Interruptive alerts
                allow problems to be brought to the user's attention
                immediately. However, users may resent the constant
                delays and forced actions. Many people prefer to finish
                expressing an idea before returning to edit its format.
                
        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.

References deleted - they don't work anyway.