Re: New AU Draft Recommendations

Hello,

Judy sent a lot of great comments about the latest draft,
and I'd like to add a few.


>3. The guidelines themselves should be as directly stated as possible. Use
>the active voice (actually, the imperative -- start each guideline with a
>verb), which has more impact, and is easier to understand and translate
>than passive voice (see 3.C.4).

I agree, although some of the wording in the current guidelines 
is probably mine. If the imperative is used, the guidelines
must clearly indicate who is the understood "you".

Thus, the table of contents would become something like:

3.A Integration of accessibility awareness
            3.A.1 Support all accessiblity features of relevant
languages 
                  (HTML, CSS, SMIL, XML, etc.)
            3.A.2 Emphasize accessible authoring practices 
            3.A.3 Expose all inaccessible markup
            3.A.4 Promote accessibility awareness in tool suites
            3.A.5 Integrate accessibility features naturally
            3.A.6 Allow users to configure levels of accessibility
awareness

3.B Provision of accessibility information
            3.B.1 Provide context-sensitive accessibility help to
authors
            3.B.2 Provide rationales that stress Universal Design
            3.B.3 Offer practical and accessible solutions in examples
            3.B.4 Package multimedia files with pre-written descriptions

3.C Accessibility Task automation
            3.C.1 Allow the user to check for and correct accessibility
                  problems automatically
            3.C.2 Ensure that all markup inserted through the user
interface
                  is accessible
            3.C.3 Ensure that conversion tools produce accessible markup
            3.C.4 Avoid removing or modifying existing structure or
                  descriptive content
            3.C.5 Offer dedicated accessibility tools


One problem is that not all of these entries "strike me" (for example
3.C.5 and
3.B.3). I recommend narrowing the scope of these guidelines slightly so
that
a stronger message is apparent.

I have some questions about 3.C.4. There are two phenomena we can
describe
here: (1) the structure and content of a document, and (2)
the way the characters appear in a file. As an author, I am always
frustrated
by authoring tools that modify (2). Authoring tools that reformat files
wreak havoc, for example, on archiving tools such as CVS. This
phenomenon,
however, is probably not the focus of this guideline. The guideline
states
that authoring tools should not modify existing structure. I think
instead that we should say:

    - Authoring tools must be allowed to change a document to make
      it more accessible. (They should be able to read inaccessible
      markup and write accessible markup).

    - Authoring tools must allow users to know when such changes are
      made. I could easily imaging working with a trustworthy tool with
      the option "Tell me when you've modified the document" turned off.
      Although in general I don't appreciate software doing things
      behind my back, in this case, I would rather not be interrupted
      is the only changes being made are to promote accessibility. Users
      should be able to choose to be notified or not.

In general, I recommend that the guidelines allow users to turn on
and off certain features. For example, 3.A.3 already reads "All
authoring tools for a specific markup languagemust be capable of
searching [for] and flagging inaccessible markup...Authors must
be made aware of the existing and location of inaccessible markup
as soon as possible..." I think users need to be able to configure
their tools so that they may be informed at different times. For
instance, I don't like Word to show me spelling and grammar errors
by underlining text (it's distracting, it hurts performance
etc.). I would rather check for spelling errors in a different
phase of editing (in batch mode, actually). In short, authoring
tools must provide certain functionalities, but allow the user
to configure the tool according to taste (this could/should actually
be a guideline related to the user interface of tools).

I'll have more comments soon,

 - Ian
 
-- 
Ian Jacobs (jacobs@w3.org) 
Tel/Fax: (212) 684-1814 
http://www.w3.org/People/Jacobs

Received on Friday, 9 October 1998 11:24:22 UTC