Re: Last Call for Authoring Tool Accessibility Guidelines

The document is very impressive and shows the immense amount of work and
thinking that the group has done to evolve and communicate these ideas.  My
comments in no way denigrate the document and are intended only to be the
observances of a new reader.

I have a background in reviewing this kind of document.  For three years I
managed the General Aviation Regulation Branch of the Federal Aviation
Administration (FAA).  This branch wrote pilot regulations, exemptions, and
denials.  During that time and in subsequent years I wrote and reviewed many
policy documents, and conducted policy presentations to upper management
including the Secretary of Transportation.  Now that I no longer work for
the FAA, I'm taking Kynn's course "Designing for Universal Accessibility."
I'm sure that you will detect that influence in my comments.

1.  Abstract Section:  It would be helpful to have links to a definitions
page similar to that used in the Web Contents Accessibility Guidelines.
This would clarify the intent of words such as "Web authoring tool
developers", "authoring tools",
"authoring interface", "prompts", "alerts", "checking and repair functions,
and
"automated tools"

2.  The Authoring Tools Accessibility Guidelines should be written to
conform to the Web Contents Accessibility Guidelines which are now a
Recommendation.  The following are suggestions:

    a.    Regarding the Table of Contents, which is a list of links:
Checkpoint 13.6 - Group related links, identify the group (for user agents),
and, until user agents do so, provide a way to bypass the group. [Priority
3]

    b.  It would be very helpful to provide links to the Top of the Document
and to the Table of Contents between each section of the document:
Checkpoint - 13.5 Provide navigation bars to highlight and give access to
the navigation mechanism. [Priority 3]

    c.  Tabbing through the document takes the reader only to links.  This
is disorienting to the reader.   It would be helpful to have TABINDEX used
in the links and at the places listed in the Table of Contents, so the
reader could tab through the document in a logical fashion.
 Checkpoint - 9.2 Ensure that any element that has its own interface can be
operated in a
device-independent manner. [Priority 2]

    d.  After using the keyboard to access a given Technique, there is no
keyboard way to return to the Authoring Tools Accessibility Guidelines -
Checkpoint 9.2 Ensure that any element that has its own interface can be
operated in a device-independent manner. [Priority 2]

    e.  A mouse click on an item listed in the Table of Contents takes the
reader to the proper section of the document.  However, there is no keyboard
equivalent provided.  Perhaps the ACCESSKEY shortcut could be placed within
the element to take the reader using only a keyboard directly to that
portion of the document. Checkpoint - 9.2 Ensure that any element that has
its own interface can be operated in a device-independent manner. [Priority
2]

    f.  For clarity and consistency in structure, it would be helpful for
each checkpoint to present the checkpoint number and statement as is
currently done.  Then under the statement, indented, should be first the
[Priority], then each "Topic",  "Refer to:", and "Technique."   This kind of
written structure would meet the intent of Checkpoint - 14.3 Create a style
of presentation that is consistent across pages. [Priority 3]

For example:

        Checkpoint 1.xx Ensure that ....etc.
                [Priority 1]
                *    Provide for...
                *    Allow ...
                *    Refer to: ...
                *    Techniques: ...



3.  Wherever the term  [Priority 1] is used by itself it is colored red
which makes it stand out for those people who can see the color red.  This
could be a problem for those with red/green color blindness or for those not
using style sheets.  However, since the Priorities are always enclosed in
square brackets, this should meet the guidelines.  However, to be
consistent, when [Priority 1] is used together with other Priorities, as in
[Priority 1 for level-A conformance, Priority 2 for double-A conformance,
Priority 3 for triple-A conformance], it would be helpful for it to still be
colored red.


4.  In the fourth bullet of Checkpoint 1.1, there is no link to the HTML4.0
specification.

5.



Edna
ednafrench@home.com

Received on Monday, 6 September 1999 15:06:18 UTC