W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 1999

Comments: Authoring Tools Accessibility Guidelines

From: Edna French <ednafrench@home.com>
Date: Mon, 6 Sep 1999 14:28:35 -0400
Message-ID: <032701bef895$a1fa3ee0$90840618@hwrd1.md.home.com>
To: <w3c-wai-au@w3.org>
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,
"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
at the places listed in the Table of Contents. 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 14:28:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:43 UTC