RE: Framework for Web Accessibility Policies (FWAP) 0.1

Hi Joe

Great set of comments.    I have saved a copy separate along with Kynn's
to refer to as we move forward.


Couple of comments


1 - Overall your comments are very good and apply to our 2.0 as well as
Kynn's posting.  I have save a side copy of both of your comments for
later review as we move forward.

2 - RE: time limit.   You asked a question.   My response is that I
don’t think that we should be forbidding time limits or making them
infinite.  We do have to make sure they are sufficient to allow people
to respond, -- yet handle the real needs of some site activities.  There
is a triplet of rules/options that I think should be used.  I will post
them separately for comment.

3 - RE pull down lists.   I agree with many of your comments so I won’t
list them here.  But one I would like to highlight is 2.7 which dealt
with pull down menus.  I agree they shouldn’t be used alone but I think
they can be used in their hybrid form where direct typing is also
allowed (especially where they let the person typing know if what they
are typing is a legal response from the list).  Check boxes should be ok
but should not be used for long sets of choices.  They don’t allow
type-to-jump feature which is important for non-visual, low vision and
physical access.



Since you commented on all of Kynn's points -- did that mean you found
it interesting?

I'm not sure what I think.    I'm sure it has helped us move forward and
advanced our thinking.   Not sure if this is the approach we should go
with.   Doesn’t quite ring with me yet but I haven't had a long enough
chance to think about it to separate wrongness from just different-ness.
It is intriguing - and has a number of very interesting aspects to it.

All for now

Gregg


PS    Please watch the tone.   You did great except for a one instance.
But it was notable - especially since Kynn posted it as a restructuring
to try out an idea and had all sorts of caveats about wording etc.
Help us keep this list cool yet lively.

Thanks.


-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu <mailto:Gv@trace.wisc.edu>, <http://trace.wisc.edu/>
FAX 608/262-8848 
For a list of our listserves send “lists” to listproc@trace.wisc.edu
<mailto:listproc@trace.wisc.edu>


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Sunday, November 18, 2001 9:37 AM
To: kynn@kynn.com; w3c-wai-gl@w3.org
Subject: 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 23:52:12 UTC