- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 25 Jun 1999 08:35:11 -0400
- To: dd@w3.org
- Cc: "Bruce Bailey" <bbailey@clark.net>, w3c-wai-er-ig@w3.org
At 09:31 AM 6/25/99 +0200, Daniel Dardailler wrote: > >The list was started as a mean to specify techniques for auto or >semi-automatic evaluation of checkpoints (as used by Bobby). > >Chris came in with the additional requirements that we look at >suggested checkpoint repair techniques during the authoring process >(for A-prompt). > >I think it's fine to treat both kind of issues at the same time, as >long as we separate them in different section in the resulting >document. > Would you consider some variations on that? I agree it is very important to keep the distinction clear, although I also think that it is quite valuable to be able to examine both detection and repair specifics for a given detectable condition together. This is why I started thinking about a tabular format for these layers of information. Structured sub-paragraphs are another way to do it in a document. Maybe I am just much into my virtual code-writing imagination. But the author tool has to deal in a closed-loop fashion with generation, evaluation, and possibly repair of the same fragments of document. At least for that author one doesn't want to have to be flipping back and forth from Chapter 3 to Chapter 5. Al PS (Recap more formally): Software is a web of assertions. Specifications are software. It is important to be able to view together all threads through the assertion web derived from a given authority, i.e. guideline or checkpoint in the WCAG. It is important to be able to view together all threads through this web that act on a given item or substructure in a document.
Received on Friday, 25 June 1999 08:29:31 UTC