Re: Subject: RC Brainstorm 1 (all positive)

> 1. Please include a one-sentence Summary for each proposal and comment. 
> I'll transfer the summaries to a "blackboard" at
> http://www.w3.org/WAI/RC/blackboard.

Summary: Scope of this group (and name)

Our first task is to agree on the scope of this group.

First question: should this group be dealing with tools (including
development of new tools, coordination of existing developement), or
just with what the tools should do (i.e. specifications).

Note that the first case doesn't mean the tools won't get done or
looked at by WAI, but that they will not be dealt with in this forum.

In fact, there are several possibilities.

1 there is no RC group.
  we let the UA group (working on user agent accessibility)
  deal with tools that can improve browsing (including design of proxy
  technique, altserv kind of stuff) and the AU group deals with tools
  that can improve generation of pages (including dynamic
  evaluating/validating what is being generated) 
2 RC group defines what evaluation and improvement means, but the
  tools are implemented/coordination/integrated by the respective
  UA/AU groups.
3 RC works on both evaluation and improvement techniques, potentially
  oversee/coordinate implementation/evolution of some tools, the
  results being integrated in the other groups at some later stage.
4 A combination or subset of 2 and 3: RC works on Evaluation tools
  all the way thru, but not on browsing improvement tools: that's for
  UA, wherever it's done.

I personally favor 3.

Given the fact that some of these tools are already out there being
managed by other groups, I think there is already a strong need for
coordination aspect to be dealt with in one forum, this forum.

My definition of 3 includes the wording "at some later stage".

Let me try to clarify that.

There is a fuzzy concept in my mind that this tool group should be
limited to working on *remote* things.

For browsing, this means anything that is not entirely done *in* the
browser (like a proxy server used to linearize table), for authoring
this means anything in the area of evaluation done on *existing* web
pages, not the page being authored locally.

Let's take rating as an example. The idea is that we work on
establishing some kind of rating system, using guidelines,
incorporating auto and semi-auto features, and then we work on
implementing it and testing it on the Web.

At some point, the authoring tool will naturally want to include
self-evaluation in the authoring process. The assumption is that they
will use the results of this group work in terms of experience and
specification for categories and scales, but not necessarily the
implementation. In other words, the integration is their job, not
ours, and they (UA/AU) should feel free to used our code but not
forced to do so.

On a last note, I think WAI-RC should be renamed WAI-TIE: Tools for
Improving and Evaluating Weg Page Accessibility.

Received on Tuesday, 10 March 1998 05:38:25 UTC