- From: Edna French <ednafrench@home.com>
- Date: Sun, 3 Oct 1999 23:26:33 -0400
- To: <w3c-wai-au@w3.org>
October 3, 1999
Comments on the "Authoring Tool Accessibility Guidelines" to:
Charles McCathieNevile (W3C Staff contact) and
Jutta Treviranus (chair)
for the Authoring Tool Guidelines Working Group
Note to Archives: These are my final comments. Please disregard comments
received from me prior to this date.
Thank you,
Edna H. French
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, and one who is new to writing for the Web.
I do, however, 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 produced 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.
**A. Both The Authoring Tools Accessibility Guidelines and the related
Techniques Document should be written to conform to the Web Contents
Accessibility Guidelines. 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 elements 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]. Providing better internal
navigation would also bring this Techniques Document into conformance with
its own Checkpoint 7.5, bullet two, "To minimally satisfy this checkpoint,
allow navigation from element to element."
4. After using the keyboard to access a given Technique, there is no
keyboard way to return to the Authoring Tools Accessibility Guidelines other
than that provided by the browser. - 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, as does using the "enter" key.
However, there is no keyboard way provided to return to 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]
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.
**B. 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. The last paragraph of the Abstract states, "This document is part
of a series of accessibility documents published by the W3C Web
Accessibility Initiative." I believe that it would help the reader of this
document understand its context if a brief description of the Web Contents
Accessibility Guidelines and the User Agent Accessibility Guidelines were
included at this point. This would also provide a place to link to a more
detailed definition of these terms, which are frequently used later on in
this document. (See also comment B.1 above.)
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 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. The red color alone is insufficient
to show the importance of this Priority to all readers.
4. 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 "bullet", "note", "other information" and
"Technique(s)." Each bullet should begin with an active verb to emphasize
its importance, while the other information need not. 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] Note: This is only a suggested style. The
important thing is to establish a consistent style of presentation.
For example:
Checkpoint 1.xx Ensure that ....etc.
[Priority 1]
* bullet (begin with active verb)...
* Note:...
* Refer to: ...
* Techniques: ...
**C. 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, there seem to be some broken or misdirected links. The link
[WAI-AUTOOL-TECH] in this paragraph (in first document) takes you to another
link labeled CONTENTS at the bottom of what is purportedly the Techniques
Document (second 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 first document.
What is worse, the second document appears to have the same content as
the Authoring Tool Accessibility Guidelines, but with a different URL.
The Authoring Tool Accessibility Guidelines (first document) is located
at www.w3.org/TR/WAI-AUTOOLS. The second document (accessed by following
the link in the fourth paragraph of the Introduction of the first document)
takes you to the URL: www.w3.org/TR/WAI-AUTOOLS/#ref-WAI-AUTOOLS-TECH. Both
documents are titled, "Authoring Tool Accessibility Guidelines 1.0 (working
draft) W3C Working Draft 3 September 1999."
I'm still trying to find the Techniques Document.
. 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 W3C
Working Draft 3 September 1999."
There is another link to the Techniques Document in the References
Section. This link is: http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS/
However, that provided in the 3 September, 1999, e-mail from Charles
McCathieNevile (W3C Staff contact) and Jutta Treviranus (chair) for the
Authoring Tool Guidelines Working Group is:
http://www.w3.org/TR/WAI-AUTOOLS-TECHS.
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 final URL (http://www.w3.org/TR/WAI-AUTOOLS-TECHS) .
If this sounds confusing, it is. I did not intentionally check other
links within the document.
2. Checkpoint 2.2 introduces the term, "user-agent". As far as I can
determine this term is not defined anywhere in the document. Since it is so
important to the series of accessibility documents published by the W3C Web
Accessibility Initiative, I believe that it should be defined in the
Abstract or Introduction.
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 4, first paragraph states, "To ensure accessibility,
authoring tools must be designed so that they may automatically identify
inaccessible markup, and enable its correction even when the markup itself
is hidden from the author." In this sentence, the words, "must", and "may"
contradict each other. I believe that the intent of the guideline would
best be served by deleting the word, "may."
5. Guideline 7 - I do not know if the word, "user", used twice in the
first sentence, refers to "author" or "user-agent". Other places within
this document clearly refer to "author" or "browser". As mentioned above,
the term "user-agent" is not defined. 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.
6. In the Terms and Definitions section, under "Rendered Content", the
word "user agent" is used again without definition or reference to the User
Agent Accessibility Guidelines. Am I simply standing on a soapbox? I truly
believe that consistency in the use of terms improves comprehension of the
document's contents.
7. The definitions would be more "accessible" if they were in
alphabetical order.
*D. Following are comments pertinent to the Techniques Document:
(http://www.w3.org/TR/WAI-AUTOOLS-TECHS/)*
1. The Introduction states clearly and compassionately the imperatives
behind the Web Accessibility Initiative. The link to the Authoring Tool
Accessibility Guidelines, however, takes you to the bottom of the document
which both links and refers you to the (almost a last call) version. I did
not check other links in the document.
2. I particularly like the second bullet in Checkpoint 1.1, because I
believe it is important that the software not "get in the way" of hands-on
editing.
3. I think it would be clearer if the last four bullets were presented
as suggested the Item B.4 above.
4. In the fourth bullet of Checkpoint 1.1, there is no link to the
HTML4.0 specification, although it appears that one is intended.
5. Checkpoint 2.2 introduces the very important term, "user-agent",
without prior definition, reference to the User Agent Accessibility
Guidelines, or definition anywhere in the document that I can find.
6. Guideline 3, second paragraph could be revised as mentioned in Item
C.3 above.
7. Checkpoint 3.2 implies that automatically generated text may be
inserted when "For example, in an automatically generated navigation bar, it
is clear that "search" is appropriate for a button linked to a search
function." At times, the author may want the search button to state
something other than the word, "search". Perhaps the Authoring Tool should
prompt the author instead of handling this automatically. Or perhaps I
don't understand the "Technique" prompt.
8. I believe that Checkpoint 3.3 would have more impact if written,
"Including pre-written descriptions for all multimedia files (e.g.,
clip-art) packaged with the tool would save authors time and effort, provide
them with convenient models to emulate when they write their own
descriptions, and illustrate the importance of description writing. It
would also increase the number of professionally written descriptions
circulating on the Web."
9. Checkpoint 3.4 uses the acronym, "ACM", without any explanation or
expansion.
10. Guideline 4, first paragraph states, "To ensure accessibility,
authoring tools must be designed so that they may automatically identify
inaccessible markup, and enable its correction even when the markup itself
is hidden from the author." In this sentence, the words, "must", and "may"
contradict each other. I believe that the intent of the guideline would
best be served by deleting the word, "may."
11. Checkpoint 4.2, third bullet, the word "an" is misspelled, "na".
12. Guideline 4, Techniques - I wonder if it would be appropriate to
remind the developers of Authoring Tools that some of their users will be
using assistive technology themselves. Some "prompt" and "alert" examples
appropriate for the Authors described in the Introduction Section should be
included. Some of the examples described here may not be sufficient by
themselves.
13. The first two bullets in Checkpoint 5.1 in effect state that if the
Authoring Tool was originally inaccessible to Authors with Disabilities,
then after integrating the accessibility solutions into the overall "look
and feel", the tool would remain inaccessible. This would negate the intent
of Guideline 7, "Ensure that the Authoring Tool is Accessible to Authors
with Disabilities."
14. Checkpoint 6.1, bullet two does not have a link to
[WAI-WEBCONTENT], although it appears as though one is intended.
15. The link [WAI-AUTOOLS] in Checkpoint 6.2, bullet four takes you to
the bottom of the page and that referenced link takes you to the (almost a
Last Call) version.
16. In Checkpoint 6.4, do you mean non-deprecated or deprecated?
17. Checkpoint 7.1 lists two sets of priorities, i.e., "(Priority 1 for
standards and conventions which are essential to accessibility, Priority 2
for those that are important to accessibility, Priority 3 for those that are
beneficial to accessibility). [Priority 1]." The first set is in
parentheses and black in color, while the Priority 1 is in square brackets
and red in color. I find this somewhat confusing (and would find it more so
if I were colorblind). What level of Priority does this Checkpoint have?
If Checkpoint 7.1 is Priority 1, and the standards and conventions have
their own levels of importance, perhaps it would be better to retain the use
of the word, "Priority" only for the Checkpoint itself, and use a different
word for the standards and conventions. On the other hand, perhaps the
phrase, "(Priority 1 for standards and conventions which are essential to
accessibility, Priority 2 for those that are important to accessibility,
Priority 3 for those that are beneficial to accessibility)", should be
deleted or moved to an informational bullet.
18. Checkpoint 7.1, bullet 4 uses the term, "User interfaces." Perhaps
this term is self-evident, but then again perhaps it could be confused with
Author interfaces or User Agent interfaces.
19. Checkpoint 7.1, "Following Standards", bullets two and four use the
acronym "API" without defining or expanding it. It is also used in "User
Focus", bullet one.
20. Checkpoint 7.2, bullet two states, "Allow the user to create audio
style sheets using a visual representation rather than an audio one ..."
Would it be helpful to rephrase this to state, "Allow the user to create
audio style sheets using a visual representation and/or an audio one..."?
21. In the Appendix - Sample Implementations, each platform illustrates
one or more Techniques for Checkpoints. The Checkpoints seem to be listed
in random order rather than in numerical order.
22. The section on Terms and Definitions has this caveat, "[Editors'
note: This section will be reviewed by the group, and is expected to be
updated in future drafts]." Should this be deleted before the "Last Call"
becomes a "Proposed Recommendation"?
23. The definition of Publishing Tool states, "A tool that allows
content to be uploaded in an integrated fashion. Sometimes these tools makes
changes such as local hyper-reference modifications..." The word *makes*
should be changed to *make*.
24. In several Checkpoints, the *information* is not clearly separated
from the *recommended techniques*. For example, in Checkpoint 3.3, the
first four bullets are techniques, while the introductory Note and the last
two bullets are information. Another example is found in Checkpoint 4.1.
The last two bullets are information, but are not labeled as such to
distinguish them from techniques. In Checkpoint 4.3, a similar thing
happens in that the Notes/information come *before* the techniques. Other
Checkpoints are arranged in similar haphazard fashion.
I suggest that for consistency and clarity, the bulleted techniques
come first, each beginning with an active verb. Then the notes,
information, etc., could follow in a fashion similar to that outlined in
Item B.4 above.
I appreciate the opportunity to comment on these documents.
Sincerely,
Edna French
ednafrench@home.com
Received on Sunday, 3 October 1999 23:30:05 UTC