Re: WAI process whitepaper

  From: Daniel Dardailler <danield@w3.org>
  
  I've read 
    http://www.access.digex.net/%7Easgilman/web-access/process_points.html
  ...  
  and I thank you for it already.
  
Great!  I sweat some over writing it, so I am glad if you found reading
it worth your time.

  As always when I have to reply an long message like this one, I try to
  find the few key sentences and I ignore the rest (ignore in my reply,
  but I have read it of course). Please tell me if there is particular
  aspect I should have answered and didn't.
  
Thank you for not quoting back the whole thing.

My overall assessment is that we are in pretty good sync.  My confidence 
in the process is way up from, say, the launch date.

I have continued on a few points below, but I don't want to take too
much of anyone's time with this right now.

[big snip]  
  > Protocols are too important to be left to the developers.
  
  I'd rather not start a religeous discussion on that topic, but I can't
  help :-)
  
  Protocols are developers' things.
  Requirements are not.
   
There is more difference in our word-use than our management
ideas, here.  I see user-level descriptions of both requirements
and solutions, and developer-level descriptions of both --
concurrently in existence in the process.  

To me a protocol is any method involving more than one agent.
Which means we need to define method and agent... Suffice it to
say that abstractions are included.  The way I use protocol,
the ISO-OSI model is a protocol for software decomposition.

And I am willing to bend my word-use to the norms of the group as
the group gets together and is able to assert a common view on
these things.

What I got out of your response is that you have a good grasp of
the users' inability to write a fire-and-forget requirements
statement and disengage thereafter.  That's why I don't see a
problem in the terminology clash.

[snip.. back to Daniel...]
  What laws are you thinking about ?
  Which countries are they applicable in ?
  
My familiarity is only with U.S. Law.  There are precedents in
public accomodation laws, the ADA, and fair housing laws that
commercial entities have to be public and non-discriminatory in
offers to do business.  These do not translate directly to Web
commerce, but the do suggest that there will be a body of public
policy attempting to say that some distinctions are anti-social.
The Web technology creates a whole web of new gray shades between
public and private.  How the policy comes down in the end is
still up in the air.  But our thinking should include the possibility
that there will be some concerns enforced by legal sanctions 
whether criminal or tort.

  >From day one of writing the briefing package, Mike Paciello, Jim
  Miller and myself have tried and wanted to gather more than just US
  legislation pointers in our document. Guess what: it's too hard, a
  moving target where most pieces are not in sight!
  
  Again, depending on the resources we get, this is one of my favorite
  action item: build up a WAI legit resource center for people *word
  wide* to get the context they need.
  
[Al again...]
I think that you can induce some of this just by the way you ask 
others questions and actually listen to them.  Part of the problem
is that the legal scene is changing perhaps faster than the data
communications scene.

I don't think that you need to build an archive to make the
information come together.  Link to what you can find and you may
achieve critical mass.  The linking may spread.

  > 
  > The invitation to the Initiative Launch went out to contacts that the
  > organizers already knew. This list should be made public and revised with
  > the aid of public comment.
  
  Agreed and I hope I can count on people like yourself to help bridging
  gaps between these existing virtual communities and WAI.
  
I hope I can be of assistance in this.
  
[Al said "make a rough sketch of the acceptance test process one
of your first products"]
  
  A hard one. We can build prototypes and evolve our spec to meet the
  requirements of our users, but we will know if all that really works
  in the field itself: are 1998 or 1999 web pages and tools better than in
  1997, accessibility-wise ?
  
  OK, so we first need to assess the current field situation but for
  that we need to build up some guidelines and the tools that check
  them, for which we need the technology straighten out first. Kind of
  chicken and egg problem here...

You don't need scientific measures to get started.  You do need
to contact the right populations.  Get them to characterize their
experience of the 'Net and Web.  Lloyd Rassmussen is a pretty
good rapporteur for Lynx and the blind.

  I propose that we start with the technologies we know best at W3C:
  HTML/CSS/HTTP. From there we can work our way toward including
  additional topics, usage guidelines of course, but also better email
  or archiving support, or less web centric things like Java or Windows
  APIs.
  
Go for it.  Do something you can see your way clear to doing.  It
can grow from there.

--
Al Gilman

Received on Tuesday, 20 May 1997 23:16:14 UTC