techniques

I believe that under 2.1.1 the first thing should be "The following are
common requirements for producing accessible software. This list does
not necessarily cover all requirements for all platforms, and items may
not be applicable to some software." which is a concise list (which can
be amended via this list) and the references should be pointed to as if
a biblio.  This has the virtue of a "poor man's" checklist without going
through the extreme refinement and "stone-engraving" of the
guideline/checkpoint process.  We might even be able to grant the list
items "priority levels" in a more informal way.

We spoke of doing this in the GL doc would take 14 months but it appears
to already be done to a certain extent.  This stuff is for people who
will probably understand the points without it being written at a
third-grade level and we could have at least some checkable items from
the already-widely-understood guidelines for software accessibility.

Incidentally these are important points in (lower-case) accessibility as
usability and that's where we will make the most points.  In a few
Webyears authors will be writing documents that must play over the
phone, etc. and if it turns out that one-fits-all prevails it will be
handy to have studied the points in this section since they are geared
towards inclusivity of devices and people with differing abilities.
-- 
Love.
            ACCESSIBILITY IS RIGHT - NOT PRIVILEGE
http://dicomp.pair.com

Received on Thursday, 17 June 1999 10:29:58 UTC