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

Comments and Recommendations

From: Janina Sajka <janina@afb.net>
Date: Mon, 4 Oct 1999 20:57:59 -0400 (EDT)
To: w3c-wai-au@w3.org
cc: Walter Decker <wdecker@afb.net>
Message-ID: <Pine.GSO.4.10.9910042055450.24363-200000@helen.afb.net>
I am writing to offer a few comments regarding the W3C's draft
recommendation on the Accessibility of Authoring Tools. I  have
only a few suggestions, but I consider the first two critical to
the success of this proposed recommendation. The working group is
to be commended for an excellent document that will contribute
significantly to the usefulness of web technology for everyone, not
just for people with disabilities. Thank you for the comprehensive
specification on this central topic.

                        Two Major Points

1.)  "Help" must be accessible help if it is to assist the
authoring user who relies on assistive technology. This is a
critical point which should not be absent from the enumerated
requirements as it now is. It should be classified priority one,
because it is that important to successful use of an application.
At the very least, equity demands it. But usability principles also
demand it. If the author using assistive technologies is forced to
work around inadequate documentation, that author is forced to be
less efficient. This is both unfair and unnecessary. Furthermore,
a requirement for accessible help undergirds the working group's
other recommendations in support of accessible authoring
applications in that it compels the consideration and specification
of alternative means for each task on which help is provided. It
will help insure that all functional elements in the authoring tool
are, in fact, equipped with appropriate accommodations;

2.)  The references to universal design in 6.4 and 7 should be
strengthened and elaborated. They should also be incorporated into
the abstract and introduction. They significantly enhance the case
for adopting this recommendation by demonstrating the greater
applicability of these requirements. In fact, they also support
internationalization of authoring tools and of generated content--a
not insignificant collateral benefit. One of the more persuasive
features used in the existing access recommendation is the parallel
structure of a.) how this works for accessibility; and, b.) how
this works in support of general audience concerns. This format
would be helpful in this recommendation as well;

                        Two Minor Points

3.)  I would like to see explicit mention of footnotes and end
notes because these should be retained when converting from word
processing formats. A mere mention, in around the discussion of
tabular structures should suffice.

4.)  I have a minor technical problem with the definition of XML
and HTML elements. Is this definition unique to this document and,
therefore amenable to technical correction? Or, is it taken from a
formal definition used elsewhere by the W3, and consequently
uncorrectable here? My concern arises from the last sentence in the
following paragraph taken from the definitions in this draft
recommendation:

     Element An element is any identifiable object within a
     document, for example a character, word, image, paragraph or
     spreadsheet cell. In HTML and XML an element refers to a pair
     of tags and their content, or an "empty" tag - one that has no
     closing tag or content.

A casual reading of this paragraph might tend to suggest that it is
acceptable practice to not close any tag, whereas the intended
meaning, as I understand it, is that there are some tags which are
unitary, and not paired as opening and closing. Perhaps one could
say, "or an 'empty' tag -- one that requires no closing tag or
content." I have replaced the word "has" by the word "requires" as
my suggestion on this point.



				Janina Sajka, Director
				Information Systems Research & Development
				American Foundation for the Blind (AFB)

janina@afb.net



Received on Monday, 4 October 1999 20:49:56 UTC

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