W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2001

Re: Deconstructing WCAG: FWAP 0.1 Straw Man

From: Lisa Seeman <seeman@netvision.net.il>
Date: Wed, 21 Nov 2001 11:52:14 -0800
To: Kynn Bartlett <kynn@idyllmtn.com>, "_W3C-WAI Web Content Access. Guidelines List" <w3c-wai-gl@w3.org>
Message-id: <014b01c172c6$051f6840$c193003e@dev1>
This is a fantastic job Kynn,
My first impression, before I nit pick etc is - cool

well done
Lisa

----- Original Message -----
From: "Kynn Bartlett" <kynn@idyllmtn.com>
To: <w3c-wai-gl@w3.org>
Sent: Saturday, November 17, 2001 11:22 PM
Subject: 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 Wednesday, 21 November 2001 04:54:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:16 GMT