Re: Last Call for Authoring Tool Accessibility Guidelines

The Authoring Tool Accessibility Guidelines and the accompanying Techniques
document are very impressive and show the immense amount of work and
thinking that the group has done to evolve and communicate its ideas.  My
comments in no way denigrate these documents 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 Regulations Branch of the Federal Aviation
Administration (FAA).  The branch wrote pilot regulations, exemptions, and
denials to petitions for exemption.  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.


*Both The Authoring Tools Accessibility Guidelines and the related
Techniques Document should be written to conform to the Web Contents
Accessibility Guidelines which are now a Recommendation.  The following are
suggestions; the checkpoints referenced come from the Web Contents
Accessibility Guidelines:*

    1.    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]

    2.  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]

    3.  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]

    4.  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]

    5.  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]

    6.  The ACRONYM tag could be very effective in educating readers who are
new to web design to the meaning of the technical shorthand that can act as
a barrier to inclusion.  Surely acceptance is part of accessibility.



*I have reviewed both the Authoring Tools Accessibility Guidelines and the
associated Techniques.  Following are the comments pertinent to both
documents.*

    1.  In the Abstract and Introduction sections, it would be very helpful
to have specific words and phrases linked to a definitions section or page
as is done in the Web Content Accessibility Guidelines.

    2.  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 Web Content Accessibility 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 still to be colored red.

    3.  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 (as needed)
first the [Priority], then each "Topic",  "Refer to:", and "Technique."
This kind of written structure would meet the intent of Checkpoint - 14.3
(in the Web Contents Accessibility Guidelines) 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 ...
                *    Notes:...
                *    Refer to: ...
                *    Techniques: ...




*Following are comments pertinent to the Authoring Tool Accessibility
Guidelines:*

    1.  The fourth paragraph of the Introduction begins with this sentence,
"A separate document, entitled Techniques for Authoring Tool Accessibility
[WAI-AUTOOLS-TECH], provides suggestions and examples of how each checkpoint
might be satisfied, "  First, I note that the sentence ends with a comma
(apologies to the proof-readers).  Secondly, the link takes you to a link
labeled CONTENTS at the bottom of what is purportedly the Techniques
Document.  Following that link does not take you to the contents section of
the document that you are in as you might expect, but instead returns you to
the contents section of the previous document.
    What is worse, following the link [WAI-AUTOOL-TECH] appears to take you
to a document that has exactly the same content as the Authoring Tool
Accessibility Guidelines, but with a different URL.   The Authoring Tool
Accessibility Guidelines is located at www.w3.org/TR/WAI-AUTOOLS.
Following the link in the Guidelines which is labeled [WAI-AUTOOLS-TECH]
takes you to the URL: www.w3.org/TR/WAI-AUTOOLS/#ref-WAI-AUTOOLS-TECH.  Both
URL's have the same title.
    However, if you cursor down to Checkpoint 1.1 and double-click on
"Techniques for Checkpoint 1.1", you access a detailed document with the
URL: www.w3.org/TR/1999/WAI-AUTOOLS-TECHS/#check-support-access-features.
This document is titled, "Techniques for Authoring Tool Accessibility."
Aha, I believe that I have finally located the ubiquitous Techniques
Document.  Later in this message, my comments on the Techniques Document
will refer to this URL.


    2.  Checkpoint 2.2 - Is a "user-agent" the same as "author"?  (Ditto for
"user's")  If not, the term should be defined somewhere.  If so, then I
suggest that the term, "author" be used throughout.

    3.  Guideline 3, second paragraph, second sentence could have a stronger
impact if divided into two sentences.  Suggest:  "Where such information can
be mechanically determined (e.g., the function of icons in an
automatically-generated navigation bar, or expansion of acronyms from a
dictionary) and offered as a choice for the author,  the tool will assist
the author.  At the same time it will reinforce the need for such
information and the author's role in ensuring that it is used appropriately
in each instance."

    4.  Guideline 7 - Again I wonder if "user" is the same as "author".  And
I confess that I simply do not understand the first paragraph, despite
repeated reading.  On the other hand, the second and third paragraphs convey
both pertinent information and well-reasoned considerations.

    5.  In the definitions section, under "Rendered Content", the word "user
agent" is used again.  Am I simply standing on a soapbox?  I truly believe
that consistency in the use of terms improves comprehension of any
document's contents.




*Following are comments pertinent to the Techniques Document:
(www.w3.org/TR/1999/WAI-AUTOOLS-TECHS/#check-support-access-features)*


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

    3.  In Checkpoint 2.2, would it be appropriate to require the

    4.  In several cases, the *why* is not separated from the *must*.  For
example, in Checkpoint 3.3, the first four bullets are requirements, while
the fifth bullet is a sales pitch.  The last bullet and the beginning Note
are *information*.  Another example is found in Checkpoint 4.1.  The last
two bullets are information, not requirements.  In Checkpoint 4.3, a similar
thing happens in that the Notes come before the *to do's*.  I suggest that
for consistency with the rest of the document and with the Web Content
Accessibility Guidelines 1.0, the requirements come first, be identified
with bullets, and begin with a *to do* kind of verb.  Then the other
information should follow as outlined in Item 2.f above.

    5.  Re Checkpoint 4.2, bullet 3 - is this a suggestion or a must do?







Edna
ednafrench@home.com





Edna
ednafrench@home.com

Received on Monday, 6 September 1999 19:28:25 UTC