Re: Framework for Web Accessibility Policies (FWAP) 0.1

>    intended to be an illustrative straw man proposal to stimulate

I really think the term "straw man" is ill-advised for a number of 
reasons, including basic meaning. A proposal like this is 
self-evidently not a "straw-man argument."

"Discussion paper," anyone?

>    FWAP describes a modules-based method by which a content-providing
>    entity

in which anyone who provides content online

>Declarations may be site-wide or may be made per directory,
>    per file, per business unit, etc.

For "declaration," I guess we really mean "policy," yes?

>   Exclusion Statement
>
>    A FWAP 0.1 Exclusion Statement consists of specific statements
>    regarding the accessibility of the content which must be asserted if
>    certain modules are not used. These statements are identified within
>    each module.
>
>    Ideally, the purpose of exclusion statements is to make the site
>    operator realize what groups are being excluded and own up to that
>    fact by requiring explicit labeling -- similar, for example, to the
>    Surgeon General's warnings on cigarettes sold in the U.S. ("The
>    Surgeon General has determined that smoking cigarettes is dangerous to
>    your health.")

This really needs to be much clearer.

Are we saying that an entity must post a policy stating what modules 
it conforms to, but also do penance by listing all the ways in which 
it lets the public down by failing to conform to *other* modules?

>    This module adds the following requirement(s):
>      * (2.4) Allow users the maximum time (infinite if possible)

(unlimited if possible)

I still think nobody is saying what they really mean with this 
requirement, which I've seen rewritten more ways than a Dear John 
letter.

If WCAG really wants site authors never to use events with a 
deadline, say so. It is clear to me that this is the intention.

>Module: Distinct Choices in Forms
>
>    This module adds the following requirement(s):
>      * (2.7) Use pull-down lists and check-boxes instead of text fields
>        for finite sets of possible values (such as states or provinces).

This is not the best idea at all. Why should a screen-reader user 
have to wait until the word Utah or Saskatchewan comes up when it is 
so much easier to type UT or SK into a field?

Pull-down lists of this sort are convenient for the developer since 
they preclude incorrect entries. They represent poor usability and 
very poor usability for screen-reader users.

>Module: HTML Table Annotation
>
>    This module adds the following requirement(s):
>      * (3.5) Use the summary attribute to describe the function and
>        contents of each table.
>      * (3.5) Use the abbr attribute to provide abbreviations for headers.

Abbreviations are not always necessary. In any event, existing WCAG 
requirements state that accessible table markup should be limited to 
*data* tables. As written, the requirement above also applies to 
layout tables, and it shouldn't.

>Module: Extended HTML Tables
>
>    This module adds the following requirement(s):
>      * (4.3) Use the axis, colgroup, headers, etc. attributes on complex
>        data tables.

You can't say "etc." Either the full range of attributes-- very 
difficult to understand, hopelessly unwieldy to implement, 
unsupported by virtually every authoring program, ignored by screen 
readers-- is necessary or only bits and pieces are.

>Module: XML Natural Language
>
>    This module adds the following requirement(s):
>      * (1.4) Identify the primary natural language of the document using
>        the xml;lang attribute.

Colon, not semicolon.

>    This module adds the following requirement(s):
>      * (1.1) Provide reasonable alt attributes for all images.

"Reasonable"? "Appropriate," I would say.

>Module: Image Descriptions
>
>    Dependencies: Basic Images
>
>    This module adds the following requirement(s):
>      * (1.1) Provide longdesc attributes for all images which are not
>        adequately described by the alt attribute.
>
>    Exclusion Statement: "Some graphical content is undescribed and may be
>    inaccessible to users without the ability to display or view
>    graphics."

Since we're improving in WCAG 1, I don't see why we can't propose 
using title first and longdesc only if necessary.

>Module: Basic Audio
>
>    Required by [89]Minimal Set
>
>    This module adds the following requirement(s):
>      * (1.1) Provide transcripts for all non-streaming audio text
>        containing spoken words.

What is "audio text"?

>Module: Basic Video
>
>    Required by [90]Minimal Set
>
>    This module adds the following requirement(s):
>      * (1.1) Provide text descriptions of all non-streaming video.

Text descriptions *do not work* as a substitute for audio 
description. This requirement must be removed.
>Module: Audio Captions
>
>    Dependencies: Basic Audio, Synchronized Multimedia
>
>      (1.1, 1.2) Provide text descriptions for all non-streaming audio
>    text containing spoken words.

There is no such thing as an audio caption, and a "text description" 
is just as meaningless.

Here, yet bloody again, the WCAG politburo refuses to use the very 
longstanding and *invariate* terminology in use for decades. Captions 
are captions (whether closed or open); there is no such thing as an 
audio caption. A "text description," whatever that is, certainly is 
not a caption.

>Module: Streaming Multimedia
>
>    Dependencies: Basic Audio, Basic Video, Synchronized Multimedia, Audio
>    Descriptions
>
>    This module adds the following requirement(s):
>      * (1.1, 1.2) Provide synchronized text streams and audio
>        descriptions for all streaming video.

Just say "captions," not "text streams." The exact presentation 
mechanism is outside the purview of these requirements. A "stream" 
may not be necessary, as with open captioning.

>Module: Accessible PDF
>
>    This module adds the following requirement(s):
>      * (4.1, 4.3) Create PDFs using the latest version of Adobe Acrobat,
>        and use the full accessibility features available.
>      * (1.1, 4.3) Provide a link or URL to the Adobe Access web site for
>        PDF to text conversion.
>
>    Exclusion Statement: This site may contain PDF files which are
>    incompatible with assistive technology devices and software.

I'm not sure there are many such PDFs given how PDF2txt and PDF2HTML 
work. Multi-column text is, I suppose, the exception, but only with 
some authoring programs.


-- 
   Joe Clark | joeclark@joeclark.org | <http://joeclark.org/access/>
   Accessibility articles, resources, and critiques ||
       "I do not pretend to understand the mind of Joe Clark"
       -- Larry Goldberg

Received on Sunday, 18 November 2001 10:38:30 UTC