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

Re: My issue

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Wed, 01 Sep 1999 04:19:00 -0400
Message-Id: <4.1.19990831125446.00a0d5d0@pop3.concentric.net>
Message-Id: <4.1.19990831125446.00a0d5d0@pop3.concentric.net>
Message-Id: <4.1.19990831125446.00a0d5d0@pop3.concentric.net>
Message-Id: <4.1.19990831125446.00a0d5d0@pop3.concentric.net>
To: Charles McCathieNevile <charles@w3.org>
Cc: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
aloha, charles!

i agree with you and william -- ultimately, the order in which the
checkpoints are presented is irrelevant, despite my predilection for
arguing from first principles...

the main reason that i have held out on this issue so far is twofold:

1) my desire that the guidelines contained in the AUGL flow in a "natural"
order: that is, from first principles to last...  we are, after all,
writing guidelines for a piece of software, so it makes sense -- at least
to me -- that we would start by addressing what i have always understood to
be the first principle of software design: "what programming conventions do
i need to follow in order for my tool to work seamlessly when running on OS
X, and what can i do to maximize my application's performance on OS X?",
and into any such discussion, accessibility considerations MUST be
introduced...

the second reason for my obstinance on this issue is the knowledge -- based
both on my own practical experience as an end user, and on the example set
by the success of Swing, the Java Accessibility API, and the promulgation
of Java Foundation Classes -- that retrofitted solutions (read:
after-the-fact accessibility layovers) are inferior to having accessibility
features and hooks considered and implemented at the authoring tool's
inception...

after all, the guidelines are designed to assist in the development of:
1. an application
2. which is itself accessible
3. which produces accessible content
and 4. which promotes knowledge of, and sensitivity towards, accessibility
issues, so it would seem only natural that the AUGL should start by
addressing the application itself, and end by addressing the promotion of
accessibility in the application's documentation and on-line help system...

that being said, i am more than willing to wipe away the line i've drawn in
the AU sandbox *provided* that your third suggestion

quote
3. Leave accessible tool as the first of the goals which are currently listed
in the section on priorities.
unquote

is adopted by the WG, for all of the reasons i've enumerated ad nauseam
elsewhere,
	gregory.
Received on Wednesday, 1 September 1999 04:14:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:22 UTC