Re: [TECH] Requirements for Techniques v0.3

Thanks for explaing it to me Jason. There is a need for testable techniques,
but may I recommend that:
a, test cases etc be available only in a specific rendering of the
techniques (so we do not confuse everybody) - as you suggested
and
b, techniques that are not testable be included anyway.
It seems a bit daft to exclude useful techniques because they do not fit
with the needs of authoring tools and evaluation and repair tools etc.
For example, clear writing techniques are, oh so hard, for evaluation tools
to pick up on.
should we excluded them? Surely these tools are there to enhance
accessibility and not limit it.

all the best
Lisa


----- Original Message -----
From: "Jason White" <jasonw@ariel.ucs.unimelb.edu.au>
To: "Lisa Seeman" <lisa@UBaccess.com>
Cc: "Web Content Guidelines" <w3c-wai-gl@w3.org>
Sent: Monday, January 06, 2003 1:19 AM
Subject: Re: [TECH] Requirements for Techniques v0.3


>
> Lisa Seeman writes:
>  > assuming that I have got the gist-
>  >
>  > I think the testability thing is overdone, and I am not sure why we
need techniques to be testable. The success criteria are testable. Making
the techniques testable may be overkill , (with negative and positive
criteria, and test cases.....) - might reduce usability.
>
> It depends on the audience, I suspect. There is a strong requirement
> for testability of techniques from authoring tool, evaluation and
> repair tool and user agent developers, who are primary audiences of
> the techniques. Also, by having multiple presentations of the material
> we can create views of the techniques in which only some of the
> information (namely, that relevant to a particular audience or for a
> specific purpose) is included. Does this adequately address the
> concern? If not, what alternatives are there?
>  >
>  > Overdoing descriptions, commentary, implementation notes, links to
resources or training materials, may also reduce usability. The thing should
read well, give you a sense of context, similar to the old techniques. But
too many links to resource
>  >
>  > will be confusing.
> Agreed. A concise exposition is always to be preferred.
>  >
>  > In general I find this document hard to understand. for example:
>  >
>  > <quote>
>  >
>  > Where technologies work together (e.g., HTML and CSS), relevant joint
techniques must be presented with the host technology (e.g., HTML). If
techniques do not involve interactions between the two technologies, they
must be presented with the techniques for their respective technology only.
>  >
>  > Techniques must state to which versions of the technology they apply,
that is, describe a practice to avoid or that will have a positive
accessibility impact. They may specify all versions, all versions prior to
or later than a particular version, or enumerate particular versions.
>  >
>  > </quote>
>  >
>  > is obtuse, but the point is actually simple (unless I have missed the
point).
>  >
>  > I think it means, for each technique state what technologies (and
dependent technologies and versions of technologies) apply.
>
> I suspect you missed the main point, which is that where one
> technology operates within a host language, the techniques for the
> dependent technology, CSS for example, should be included with the
> techniques for the host language rather than as a separate document.
> The second point in the above passage is as you stated it, however.
> While it is true that CSS works with XML, HTML was here mentioned only
> as an example rather than in an effort to be exhaustive.
>

Received on Monday, 6 January 2003 03:31:47 UTC