Re: Devising a schema for accessibility testing

On Sun, 30 Jun 2002, Charles McCathieNevile wrote:

> Well, I like it, but a couple of comments:
>
> I would try to define the test as being about a particular URI that is
> expected to be used as an earl result. But where this is only one of several
> tests that you apply to meet another requirement, I would give it its own
> URI, and then I think we need to sort the piece that says "results X and
> Y and Z imply result Q" for earl and re-use here. (I know that they don't
> seem to be strictly inside EARL, but they seem really important to many use
> cases.  On the other hand, I think there is some low-level RDF that does this
> - or is it OWL stuff?)

Hmmm ... I have another consideration, which is that I want my users to
generate this test definition language via a few simple CGI forms.
I need something that will work with a very simple frontend.

> How do you envisage adding tests that apply to free text? xml:PCDATA might be
> an option I guess. likewise for mime types...

Valet doesn't do that.  Some Valet tests do analyse text nodes, but they
act on an element and look at the text it contains.  For example, a
<th> with no abbr attribute and too many words, will generate a
warning suggesting an abbreviation.


> How do you identify tests that are done by a person, and integrated via an
> interview process? I think that I can see this in your schema, but examples
> would make it clear that it is possible.

Good point.  My schema is intended to be general-purpose, but I hadn't
considered that particular issue.  If I got the general-purpose right,
it should presumably work.

> There were some other proerties in earl that we thought were more related to
> test description, such as earl:excludes and earl:operatorInstructions. Do you
> envisage moving those into a tesst description language?

Yes, I think we can & probably should introduce this and other
EARL vocabulary.  But not tonight!

> Defining the code to be used directly is sub-optimal - this is how IE makes
> object unworkable in the long term, by specifying a particular bit of code as
> part of the requirements for running the test. Being able to identify the
> test, and then identify a bit of code in one app seperately means that we can
> make pluggable testing architecture without having to pretend that some tool
> is something else.

That's what I'm doing ... the use of <valet:code> was just 'cos I
didn't think of anything more imaginative to call it.

> Anyway, this seems like a good start. Should we pick a few namespaces and try
> to take it further?

Sounds good to me.

-- 
Nick Kew

Available for contract work - Programming, Unix, Networking, Markup, etc.

Received on Sunday, 30 June 2002 18:02:56 UTC