W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2001

Re: Accessibility vs. consideration X: how to handle

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 01 Jan 2001 18:10:28 -0500
Message-Id: <Version.32.20001230202300.04534140@pop.iamdigex.net>
To: "Leonard R. Kasday" <kasday@acm.org>, w3c-wai-gl@w3.org
At 04:34 PM 2000-12-30 -0500, Leonard R. Kasday wrote:

>4. Make a detailed catalog of all the hardships that each consideration may 
>5. -- your suggestion here --


My ideal is closer to 4. than to the others you list.  This is to gradually
grow a structured record of all the considerations that we have discovered and
considered.  This is pretty much the only way we can go back over our
when we discover a new consideration to throw into the stew late in the game.

I don't really think we can proceed by (B) setting aside all considerations
access "until later."  I am afraid this would generate a tendency for us to
wander pretty far from where we should be at the end.  As many perspectives on
an issue as we can articulate should be considered "early and often" if we are
to make reasonable headway toward a successful impact on actual practice.

It would be easier to resist an impulse to rush to judgement if we had a
defined method of capturing the considerations.

The more I think about this, it is so close to an EARL application that we
should look seriously at making the requirement to support this knowledge base
one of the EARL operational requirements.

Think of it in terms of describing "a consideration" in terms of the
journalist's agenda:

<ID etc. administrative stuff ad lib>
Who: affected category of people
When/Where: scenario description to set up the outcome
What: outcome, impact on effective communciation, function enabled or disabled
Why: detailed explanation of the mechanism

This is a genericized version of the corresponding sections of a trouble (or
praise) report.

There is an interesting variant of a differential observation, where the
is a relative statement of efficiency or effectiveness and there are two or
more alternatives within the who/what/where setup.

If we can succeed in wrestling the issue brought by each person that testifies
into a statement like the above, that we can consense on as factual or
objective description, then we can narrow the range of argument to what is
clearly judgement in balancing these considerations.  At present, particularly
when an issue comes up on the IG list, there is a natural temptation to
slug it
out over A vs. B without first finding out what about A and B is bothersome to
groups C and D.

One of my agendas in this regard has to do with XHTML reform.  Not that we
should think we can change much, but there is a crack of an opportunity for us
to change how HTML works if there is a real problem.  The harder it is for
group to agree on how to use it, the more that issue is a candidate for us to
see if there is some way by changing the protocols and formats that we can
it easier for the authors and users to come to an agreeable middle ground on

If we are going to get XHTML or any other technology specification to deliver
some relief, however, we need a clear statement of the considerations. 
This we
need in order to train up the workers in the other working groups rapidly on
what the access considerations are.  Otherwise we a) get a solution that
doesn't solve the problem or b) miss the boat because they freeze the spec
before they grasp the problem.

Received on Monday, 1 January 2001 18:05:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:35 UTC