A friendly suggestion

<<
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 Wednesday, 24 February 1999 22:11:48 UTC