Deconstructing WCAG: FWAP 0.1 Straw Man

Hi everyone,

I have suggested several times in the past the concept that WCAG 2.0
(or 3.0, or whatever) could be used as a modularized "toolkit" for
constructing an accessibility policy.  This is what we saw the federal
government do (with arguable success) with WCAG 1.0 to create Section
508 regulations.  Since WCAG 1.0 was not intended to be used as such
(witness the de facto implementation policies embodied by the compliance
scheme), the effort was difficult.

After me proposing this enough times, someone (Jason or Gregg?) finally
got through to me that merely talking about it was not enough, and a
fleshed out straw man proposal would be helpful.  Therefore, I've spent
the last few days working on "FWAP" -- Framework for Web Accessibility
Policies, based on WCAG 2.0 (draft 24 August 2001).

      http://kynn.com/access/fwap-0.1.html

FWAP is a modularized approach to accessibility policies, one that
takes into account that different policy-setting entities may have
different priorities and may have different interpretations of the
WCAG 2.0 guidelines.  Thus many of these modules are broken up along
PRACTICAL considerations rather than DOGMATIC.  For example -- a
company may wish to require the use of lang="fr" on all their
pages (assuming French is the default language) but may not wish
to require xml:lang="fr" as that assumes the use of XML.  A strict
reading of the guidelines could require both, as well as requiring
XHTML Strict, etc, etc.

The concept of "exclusion statements" is introduced in this document
as well.  Basically those are a way of saying "if you make an exclusionary
policy, you've got to admit to yourself and the world."  These are marked
as optional specifically because the idea is new and reflects even less
concensus than modularized accessibility policies, and because they are
not a key component of the FWAP system.  I ask you to consider the
issue of exclusion statements as a separate proposal from the FWAP
framework in general.

You will notice that I've rewritten checkpoints to create FWAP
"requirements" -- this is intentional.  I don't claim that my rewrites
are perfect, but they serve the straw man purpose of illustrating what
I mean -- and what I mean is that the way you write a FWAP requirement
is different from the way you write a WCAG 2.0 checkpoint.  For
example, it's one checkpoint to say "provide text equivalents for
non-text content" -- but it's multiple FWAP requirements.  This is
not an aesthetic choice but one of pure practicality -- web
developers don't think in terms of "do all my non-text content bits
have text equivalents?" but rather in terms of "do I need alt text
for my image?  do I need longdesc?  do i need functional equivalents
for my Java applet?  do I need HTML versions of PDF files?"  Any good
policy created for use within an entity MUST answer those questions
and cannot stay as vague as WCAG 2.0 does.

(This is not a criticism of WCAG 2.0 phrasing -- it is a statement,
and a true one, of the type of additional material that policy-makers
must provide to web developers beyond what WCAG 2.0 states.)

I welcome your comments on this.  If I've left out any requirements,
or written them poorly, or whatever, those comments are accepted but
not requested, because what it comes down to is whether or not we like
this type of APPROACH.  If we do, the specifics (which requirements
go with which modules, how we phrase things, what terminology we
use) can be worked out -- and if we don't like it, it doesn't really
matter if I got your favorite checkpoint "wrong."

So -- any feedback on the FWAP proposal?

--Kynn

PS:  I call this "deconstructing WCAG 2.0" because it's necessary to
      take apart WCAG checkpoints and break them down into their
      necessary policy implications as part of the guideline ->
      policy practice.  I call this "FWAP" because it's moderately
      pronouncable, and because sometimes I want to *fwap* entities
      which do not have sound web accessibility policies.

-- 
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/

Received on Sunday, 18 November 2001 02:31:33 UTC