W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2000

Checking server-side code

From: Charles McCathieNevile <charles@w3.org>
Date: Fri, 19 May 2000 06:15:30 -0400 (EDT)
To: Marjolein Katsma <access@javawoman.com>
cc: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.20.0005190607090.6834-100000@tux.w3.org>
The first piece about a prompt at save time is an implementation decision -
it applies to a tool like homesite, which requires another app to preview and
therefore needs the document to be saved, but it is irrelevant to a WYSIWYG
tool in many cases, especially a multi-view, stylesheet capable tool like
amaya.

The more serious part of this is the assertion that we cannot check
server-side code for accessibility - I disagree fairly strongly. To use an
example of cold fusion, a tool like CFStudio can check whether things like
alternative content are going to be produced in the final result. To take
Lotus Notes as another example, the template can check whether there is
alternative content, and the database can check whether there is a value (or
an explicit null) specified that can be used - the AIMM technique of
checkpoint 4.6 (I think). There are other examples - checking everything may
be difficult, but for many of the cases where we have automated checking
algorithms it is not really a quantum leap (although it is clearly extra
work - there needs to be some dry-run of the code in the tool).

In a batch processor we run into a similar problem - there are two parts, and
in one the tool can check that alternative content will be generated at all
(or that the document will end up with structured content, or whatever) and
in the other it can check the content that it runs on to ensure that the
requied initial information is present.

cheers

Charles McCN

On Thu, 18 May 2000, Marjolein Katsma wrote:
[snip]
  A prompt at saving is also out of the question: depending on the work
  method some documents will have to be saved literally hundreds of times
  while being worked on, before it's finalized. Also we should take into
  account that frequently the document being created or edited is not
  itself HTML but (a combination with) server-side code which will
  ultimately _generate_ the HTML to be sent to the browser; accessibility
  does not apply to server-side code, so even (forced) prompting at
  deployment time (as opposed to saving) is not an option in many cases:
  the server-side code is what will be deployed but only the resulting HTML
  (i.e., after deployment) can be checked.
  
Received on Friday, 19 May 2000 06:15:42 UTC

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