Classification of AT in ATAG2

I was involved in a discussion on the WAI GL list a few months back 
regarding the problem with formatting authors input content into marking 
up via forms from TEXTAREA elements.  Many CMSs and Web log software, 
including forum software, often use a combination of javascript toolbars 
and backend filters to process the user text into marked up content.

Someone on that list asked me to take a look at ATAG2, so I did, but 
have not had time to address the issues I found until now.  I did have a 
discussion off list with 2 W3C people related to these areas, but it 
seems that the issues I raised did not register as major concerns to 
them.  So I will endeavour to share it here.

The problem I have with ATAG2 is that I feel there is a clear need to 
define tools according to the environment they operate.  Application 
software operates within the domain of the operating system API and 
therefore is bound by the SDK and the Interface Standards of that 
operating system.  The good thing is that amongst all the major 
operating systems, these standards are quite uniform and consistent.

Web forms are also an authoring tool environment, but they are not 
subject to, nor do they have access to the operating system APIs.  They 
are outside the domain of being able to call or interact with it.  They 
do not even have access to the user agents run time environment.  The 
user agent, as native application software has access to the operating 
system API, the Systems Metrics and their own runtime engine 
manipulating the resources according to user configuration.  Web based 
AT only have the basic form processing abilities and access to the DOM 
via the user agents DOM implementation.

There are other authoring tools that utilise a WYSIWYG environment 
within the runtime environment of a particular user agent.  Then there 
is also sets of scripts and programs that could also be classified as 
authoring tools by their ability to be configured to interpret and parse 
documents and transform them according user configuration.

My point is, as it stands, ATAG2 does not clearly define each of these 
authoring environments and classify its guidelines accordingly.  ATAG2, 
as a document, bundles all these tools into the one basket, not defining 
which classification of tools should be compliant with which set of 
guidelines.

For instance, only authoring tools that are built as native software 
applications (ie Dreamweaver, FrontPage, etc) can comply with any of the 
guidelines under points 1.x.  (1,4 & 1.5 not impossible but improbable 
for non native apps).  You cannot apply these guidelines if your mandate 
is to develop a web forms authoring tool to meet all of ATAG2.

What is needed is clear classifications of these AT in the document. 
For instance;

Application software needs to comply with check point A,B,C, etc
Web Based form AT need comply with XYZ
Scripts need to comply with OPQ
whatever.

You may say that everyone understand this, and lets just pretend that is 
so.  The problem then comes up in a business and functional 
specification when a business, department or vendor wants a web based 
interface authoring tool for their CMS and it has to comply with ATAG2 
as laid out in the contract or specifications.  At that point I get very 
worried if this clarification is not in the document.  Why, because I 
have been in so many situations where the aim is not so much for a 
quality product, but to screw the software developers or create a back 
door for an escape clauses that show the software developers have not 
delivered on the product specified.  In such cases the flaw would lie 
squarely with the ATAG2 document.

So I feel there is need to address these technical clarifications for 
ATAG2 to be a responsible document and be technically correct.

Geoff Deering

Received on Wednesday, 10 December 2003 21:12:31 UTC