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

Re: A friendly suggestion

From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
Date: Thu, 25 Feb 1999 13:07:37 -0500
Message-Id: <v04011701b2fb3d045286@[142.150.64.191]>
To: Charles Oppermann <chuckop@microsoft.com>
Cc: w3c-wai-au@w3.org
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 13:05:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT