W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > June 1999

Re: Guideline 1 in The evaluation techniques document

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 25 Jun 1999 08:35:11 -0400
Message-Id: <199906251229.IAA211787@relay.interim.iamworld.net>
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

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

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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:28 UTC