RE: Development Cost

<<
Enforcement of these guidelines and assessment of how much they cost a
particular manufacturer to implement are both beyond the scope of the
group as currently chartered.
>>

I agree with this sentiment.  This problem of "implementation cost" isn't
one of creating checkpoints, it's of prioritizing them.

We can agree that providing a structured view of a document might improve
the accessibility of the documentation creation tool for certain users.
However, the cost of implementing such a feature may be prohibitive.

When we come to prioritize this checkpoint, I will strongly argue that it
should have a low priority.  Here is why based on my understanding of the
current checkpoint:

* It only helps document creators and editors, not users of the finished web
site
* It only helps those document editors using speech output.  It is of little
help to users with mobility impairments or low vision people using screen
magnifiers.  
* The degree that it helps those users is unknown and debatable
* It's only meaningful in the cases where structure is important.  The
feature would make little sense in products such as Microsoft Access, Excel
or Project.
* The feature already exists in Microsoft Word.  Does it need to be
duplicated in FrontPage?

So, given that very few people will achieve a dubious benefit, and given
that the design, development and testing cost is likely to be quite high, I
would recommend to our development teams that they concentrate on the
accessibility of new and existing features and fix accessibility problems
that affect a larger number of users.

All software project managers juggle three balls - Time, Resources,
Features.  Time and Resources are finite.  I have to cut features.  I will
cut the features that have the least benefit to the smallest number of
users.  I want to place my resources where they can have maximum impact and
dramatically increase the accessibility of the produced content.  

So, I agree that the discussions of the working group should not be colored
by the potential cost of a feature.  However, when it comes time to
prioritize those features, I hope that common sense and practicality will
win out.

Another area where cost should be considered is alternatives.  If the
problem is that the document editor is unaware of the hierarchy of the
information, then how can that be presented?  A structured view is one way,
what's another?  Surely there are other possibilities.  Jutta mentioned
several times yesterday about the visual formatting information.  However
that information is already available to speech output products - why are
they not representing that to the end user?

In short - State the problem.  Propose some solutions.  Write the
checkpoints.  Unfortunately, it *appears* that a checkpoint was thought up,
put into the document and then everyone is racing around trying to justify
it.  Let's get those justifications into the document.  Let's get the
alternative solutions into the document.

If we can agree on the problem, and present some possible solutions, each
with various trade offs, it becomes much easier to get one of the solutions
implemented.

If the checkpoint is "provide a structured view" with no supporting
information or alternatives, then it becomes very unlikely that the problem
that some users are having will get solved in any form.

I can hear Charles, Ian and Jutta say "there is no supporting information
currently, but that's only because we didn't get a change to fill that out
yet."  That is where I say your process is faulty.  Don't put the
checkpoints in first.  Put the problems in first.  Put potential solutions
in next.  Develop check points based on the solutions.  Prioritize the
checkpoints.

Don't think of me as rejecting this checkpoint totally.  I can understand
that there might be some benefit.  Maybe it can be proven that there is
greater benefit to a wider range of folks.  I am absolutely passionate about
improving the accessibility of our products and Microsoft's track record
bears that out.  

Things that are of lower priority or not practical just serve to distract,
dilute and discredit accessibility efforts.  I will fight that just as
passionately.

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

Received on Tuesday, 9 March 1999 19:55:27 UTC