RE: A friendly suggestion

<<
But then,
we decided that we didn't want simply a list of all the beefs about what is
wrong with present authoring tools and a list of do's and don't, but rather
a guiding document that communicates the principles and approaches an
authoring tool developer needs to take to ensure that their tool both
produces accessible content and is accessible to authors with disabilities.
>>

If that's the goal then you've failed.  Currently the document IS a list of
beefs what about is wrong with present authoring tools.  It has a series of
"wish list" items with no real basis in need.

How else can you explain:
2.1 Generate standard markup
The first step towards accessibility is interoperability.
2.1.4: [Priority 1] 
Do not use a document type which precludes users' access to content or
function of the document. 

Can I get an example the problem this is solving?

I can give lots of very focused feedback, but if the process is such that
random things are thrown in, without a basis in need or an example of the
problem, then I'd spend all my time rewriting the document - not being a
contributor.  That's not the role my employer wants me to take.

My suggestion is that you define the problems first.  You then collect
potential solutions.  Then write checkpoints based on the solutions.  Then
prioritize the checkpoints.

Right now, all I can do is comment on the invalidity of the existing
checkpoints.  That's not contributing - that's revising.

You have a major problem with process.  This has shown up time and time
again in the WAI, and is a one of the reasons why, after 2 years, the WAI
still has not produced anything as a W3C Recommendation.

Compare the progress this group has made against, say the "XML Schema
Requirements" W3C note.

In fact, you should check out the XML Schema Working Group process document
at http://www.w3.org/XML/Group/1999/01/reqsproc-19990127.htm.  

Here's an interesting passage from that document:
----
Requirements documents are intended to establish a shared, public
understanding of the problems that the Work Group is attempting to solve.
The requirements describe and relate elements of the problem space that must
be addressed further on in the design process. For this reason, requirements
should be broadly enough defined to allow multiple design solutions.
----

And if you think that what the WAI produces is different than a requirements
document, think again.  They both are trying to solve a problem and getting
other entities to buy into their proposed solutions.

I do not wish to be mean or criticize the efforts of the people involved.
We are all committed to a more accessible world and have been for some time.
We all have opinions on how that can be best accomplished.  The processes
that have been followed so far are not producing practical, or even
achievable guidelines for their intended audience.

It's my hope that will change soon.

Charles Oppermann
Program Manager, Accessibility and Disabilities Group
Microsoft Corporation
http://www.microsoft.com/enable/

 -----Original Message-----
From: 	Jutta Treviranus [mailto:jutta.treviranus@utoronto.ca] 
Sent:	Thursday, February 25, 1999 10:08 AM
To:	Charles Oppermann
Cc:	w3c-wai-au@w3.org
Subject:	Re: A friendly suggestion

Chuck,
I think you may have missed a few steps in the evolution of the group
process. If you trace the history of the various drafts you will note that
we had a list of the critical problems with possible solutions. But then,
we decided that we didn't want simply a list of all the beefs about what is
wrong with present authoring tools and a list of do's and don't, but rather
a guiding document that communicates the principles and approaches an
authoring tool developer needs to take to ensure that their tool both
produces accessible content and is accessible to authors with disabilities.
Like the Web Content group we want this document to age gracefully but we
also want to present enough specific advice to solve today's problems. This
is why we have settled on several tiers of information. The guideline with
rationale, the checkpoint as the verifiable outcome of following the
guideline and the techniques which outline possible approaches. Given that
the intended audience is developers, your input would be very valuable in
the upcoming meeting.

Because we want to make the process of editing the document as public as
possible, Jan was posting proposed wording for edits discussed in the
conference call you missed. Perhaps we should use introductions in the
emails to give occasional viewers a better sense of the context. As Charles
stated we are trying to make sure we have the critical principles of the
approach down, then we want to make sure our checkpoints are complete, then
we will review priorities.

Jutta


><<
>3.2.1: [Priority 1]
>Provide examples of accessibility solutions in help text.
>>>
>
>What is the process this working group is taking?  Are we just throwing out
>ideas and assigning a priority to them?  If so, it didn't work for the UA
>group.  While I agree in principle to the checkpoint stated above, I
>strongly disagree with the priority.
>
>My suggestion, based on working in the UA group for over a year now, is to
>create a big list of problems that people have and then enumerate the
>potential solutions for those problems.  Turn the solutions into
>checkpoints.
>
>Then and only then should the checkpoints be prioritized.  This is because
>what appears to be a priority 1 for in the documentation section, shouldn't
>come before a priority 2 in the user interface section.
>
>That way, we can ensure that the checkpoints are in direct response to an
>actual or potential problem.  We also don't waste time knocking a solution
>because of its priority.  We just gather all the potential solutions -
tweak
>them, combine some, separate some and then word them as checkpoints for
>developers.
>
>So, given that method, let's try the above example.
>
>Problem:
>Page authors create inaccessible web sites due to ignorance of the need for
>accessible design.
>
>Solutions:
>1) Provide examples of accessible design in product documentation
>2) Provide sample HTML that uses accessible design wherever appropriate
>3) Include references to W3C recommendations in product documentation
>4) Include references to WAI recommendations in product documentation
>5) Include material on the need for accessible design in product
>documentation, particularly in tutorials
>
>Note that the solutions are not necessarily checkpoints - they might be,
but
>the UA group found that solutions can be the same - but the checkpoints
>radically different.  Also, a checkpoint for a product is worded different
>than the solution to a problem.
>
>I strongly urge you not to develop checkpoints without enumerating the
>problems people face first.  A key principle in software design is
>requirements gathering.  You can't build something without knowing the
>requirements.
>
>For this group - we are trying to solve a problem - the creation of
>inaccessible web sites.  Let's enumerate the all the reasons for this
>problem and propose solutions before we start haggling over the priorities.
>
>Charles Oppermann
>Program Manager, Accessibility and Disabilities Group
>Microsoft Corporation
>http://www.microsoft.com/enable/

Received on Thursday, 25 February 1999 21:48:12 UTC