- 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>
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