addressing the sophistication of the user in Section 1.2

in response to the second ordered list item contained in Member A's review,

2. lack of clarity about the expected level of sophistication of the user
of the tool

i would strongly advocate that a reformulation of the first introductory
paragraph for ATAG Guideline 1 be included in the section entitled "1.2
Checkpoint Priorities"  with the following modifications...  

When a tool generates markup, an author usually remain unaware of the
accessibility status of the content being produced, unless he or she:

1. uses an accessibility checklist as a guide when reviewing the document
source created by the tool. 

2. explicitly invokes an external tool, utility, or online service to check
the accessibility of the content that has been created, and/or

3. explicitly invokes an accessibility evaluation and repair feature which
has been built into the tool,

Obviously, such repair strategies are impractical if the author must then
either make any appropriate corrections by hand or in response to prompts
and alerts without guidance from the tool itself. Since most
authors--regardless of their level of familiarity with a particular markup
language or tool--are unfamiliar with accessibility issues as they relate
to web content, the onus is on the authoring tool to (a) generate
accessible markup; and (b) where appropriate, to guide the author in
producing accessible content in a manner consistent with the "look and
feel" of the tool.

why this particular formulation?  just as we cannot possibly bar anyone
from using the ATAG to promulgate an entity's purchasing requirements, we
cannot address the "expected level of sophistication of the user", as that
is something that each individual developer will have to address when
deciding what features to add or emphasize in their tool...  what we can
do, however, is reiterate our oft-repeated mantra that there is no
reasonable expectation that an author -- regardless of his or her
familiarity (or lack thereof) with a particular markup language or user
interface -- will be aware of the accessibility issues which need to be
addressed when content is being created or when it is automatically
transformed by an application (particularly those not explicitly thought of
as an authoring tool, such as the Office suite or WordPerfect) for
transmission via the web in what is traditionally referred to as a
web-based markup language (i.e. HTML, XML, SMIL, etc.)

i know that the proposed text above could be tersified and clarified -- but
i think it is the right way to address this particular issue...


He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
Gregory J. Rosmaita <>
   WebMaster and Minister of Propaganda, VICUG NYC

Received on Monday, 29 November 1999 19:45:58 UTC