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

plain text editors and ATAG

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Thu, 02 Dec 1999 15:56:52 -0500
Message-Id: <4.1.19991202153431.00c155f0@pop3.concentric.net>
To: William Loughborough <love26@gorge.net>
Cc: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
aloha, bill!

while i am in sympathy with a number of the points you made in your recent post
on check versus identity, i am still at a loss as to why anyone would want to
claim conformance for a straight text-editor...  by text-editor, i don't mean
an enhanced text editor, such as HotDog or HomeSite, but an application whose
primary purpose is to provide the user with the ability to compose a document
in plain ASCII...   NotePad isn't an authoring tool, although it can be used to
write markup, it is simply a plain text editor...  it doesn't transform plain
text to HTML as Word and WordPerfect do -- the individual using NotePad
performs that transformation...  therefore, i think the whole question of what
conformance level would be accorded a plain text editor such as NotePad, ED,
PC-Pico, or BBedit if you gave it to someone along with WCAG, the HTML4 rec,
the CSS2 rec, and whatever other supplemental resources you care to throw in, a
specious non sequitur...

the only way that NotePad could qualify as an authoring tool is if it was
delivered in an executable or archived format along with the HTML4 and CSS2
specifications, specifically AS an authoring tool...

Emacspeak is a speech-output system for Emacs...  therefore, it is not itself
an authoring tool, but an adaptive technology for the Unix/Linux
environment...  it is no more an authoring tool than is Jaws for Windows or
JAWS for DOS...  granted, without either, i wouldn't be able to create content
for the web, but that does not make them authoring tools...

just my 2 cents,
gregory.

At 02:22 PM 12/1/99 -0800, Bill wrote:
>In the introductory paragraphs to Guideline 4: "To ensure accessibility,
>authoring tools must be designed so that they can automatically identify
>inaccessible markup" might be the crux of the matter we've been
>contending over. If it is impossible (at this time) to do this then we
>must change this language. Checkpoint 4.1 is clearly based on the
>assumption that such an identification of inaccessible markup is
>possible and frankly I doubt this is the case. The fact that the Note:
>to 4.1 acknowledges this makes it IMHO imperative that the intro to this
>guideline is the proper place to make the point made in the note. I
>strongly disagree with the notion that what can/cannot be automatically
>identified should be listed anywhere in the Guideline Document. 
>
>This same deplorable state of affairs may occur in other
>Guidelines/Checkpoints because we were a bit cavalier in our use of such
>phraseology as "check for" and other actions to take in regard to
>inaccessible markup. 
>
>If the "minimum" is alerting the author to accessibility problems then I
>still feel that a copy of WCAG furnished with a text editor can qualify
>at some level and with proper instruction in the design of extensions to
>the tool's capabilities with macros it might even proceed to triple-A!
>
>How much would Raman's emacspeak need to be modified to qualify?
>-- 
>Love.
>            ACCESSIBILITY IS RIGHT - NOT PRIVILEGE
>http://dicomp.pair.com
>

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------
Received on Thursday, 2 December 1999 15:51:20 UTC

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