Glad you like the summaries, Joe.
One quibble with your quibble: I wasn't quarreling with or objecting to
Kynn's "sarcastic comment" about the opacity of the checkpoint. I was
noting it for the record (the actual comment was something like, "Is
this English?"). And I don't think any of us disagree with the
sentiment: The "plain language" drafts of this and other WCAG 2.0
guidelines came about because the Working Group recognizes that we need
to do a much better job of writing clearly ourselves
There are times when sarcasm is well placed-- even yours, sometimes...
John
"Good design is accessible design."
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Tuesday, January 20, 2004 5:49 pm
To: WAI-GL
Subject: Re: Summary of Bugzilla comments on checkpoint/guideline 3.3
I like these summaries! Might be nicer as HTML pages somewhere, then
mailed in Lynx, which preserves all the nice structure in a readable
text-only way.
A couple o' quibbles:
>Kynn Bartlett, Aug 2003, sarcastic comment about opacity of language;
Listen, get used to the "sarcastic comment[s]," OK? Lifers in the
accessibility field are eccentric, as I mentioned already
("colourful," actually).
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2003AprJun/0313.html>
WCAG Working Group has *got* to get over this ridiculous peevishness
that NICE conversations are better than every other kind. Some of us
are sarcastic! Like you didn't know that already!
>2. notes that we should distinguish between "alternative formats"
>and simpler or less complex versions, noting that in our examples we
>talk about supplementing complex text with audio and/or visual
>illustrations but don't make clear that these are simplified
>representations.
The terms are admittedly confusing.
Indeed, an easy-reader version of a site really isn't an "alternate
format" (not "alternative") in the traditional sense. As an example
the Copyright Act here does not even define "alternate format,"
though the only translation permitted is into sign language.
<http://laws.justice.gc.ca/en/C-42/37956.html#section-32>
(IIRC the U.S. copyright laws don't even permit that.) You could
twist and deform the definition of "perceptual disability" to include
easy-reader rewrites as an alternate format, but I bet you would get
sued.
Complicating matters is the fact you can use the <link> element to
associate alternate forms of a document.
<link rel="alternate original" title="Original version" href="X" />
<link rel="alternate easy-reader" title="Easy-reader version" href="X"
/>
(That is one coding possibility. You could add the alternate entry
just to the base document and use <link rel="start"> *in* that
alternate document to point *back* to the original.)
>August 2003, Harvey Bingham: suggests explicitly including synthetic
>speech (with variations of pitch, rate, etc.) as well as
>announcement of events.
>
>Not yet addressed; might be incorporated in strategies and examples,
>references to CSS 2.1 speech properties.
We really shouldn't be encouraging people to cause their Web sites to
read themselves out loud. The settings you the developer like will
never or very rarely match what the visitor wants, plus there is much
less control, *plus* we can flunk it under WCAG 1 as an unannounced
change of state (plus don't you need to caption it?).
>#430 Proposal 3, Checkpoint 3.3
>
>
>August 2003, Lisa Seaman, on behalf of a group.
>
>This proposal, sent to the list and available at
>[15]http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0244.html
><[16]http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0244.htm
l>
>, forms the substance of Checkpoint 3.3 as it appears in the
>September WD, though portions of the proposal were altered as they
>migrated into the WD. Perhaps the most important concept that does
>not appear in the WD is the one that calls for "markup of key
>information that the user typically requires." Lisa notes that this
>requirement is "similar to 1.3" but differs in the important respect
>that it first calls for identifying important information and
>including it in structural markup, whereas 1.3 calls for using
>structural markup and making structure manifest:
>
>In my judgment, the proposal is clearer and perhaps more nearly
>testable than Checkpoint 3.3 as it appears in the September WD; the
>first plain language proposal (#648) took the WD as starting-point
>rather than this proposal, so does not include the item about
>identifying key information and incorporating it into structural
>markup.
I really need this one explained better. Various WCAG drafts have
gone off into this fantasyland tangent that it is possible to use
custom markup to emphasize different page components for different
audiences. Yeah, like what-- <blink> and <marquee>?
If you're writing semantic, valid HTML, *there is no more you can
do*. It becomes a user-agent issue.
>3.3 [E8] Use the clearest wording that is consistent with the
>purpose of the content. Provide summaries or paraphrases of complex
>material, and provide visual or auditory illustrations as
>appropriate.
>
>The proposed rewording eliminates the controversial phrase "no more
>complex than is necessary," but replaces it with one about
>consistency which may be equally difficult to test.
Let's say "appropriate for," "compatible with," "consonant with" (if
we wanted to get fancy, but then pedants would accuse us of banning
vowels, which, I dunno, maybe I shouldn't mention in this company),
or "is suitable for."
>The reference to summaries or paraphrases
Why is a paraphrase so different from a summary that we need to list
it specially?
>1. The original wording of "A. familiarity of terms and language
>structure" would be replaced by "A. The resource uses vocabulary
>which is widely used by members of the intended audience." This
>replaces the vague "familiarity" with language that suggests a test.
>Note that Lisa Seaman's proposal would go even farther by calling
>for links to a specific lexicon or glossary.
few of which are even available. A lot of terms I know and use don't
even come up with hits in the Google Glossary, for example. It would
be imaginable that if a glossary didn't exist on a certain topic, a
pedant could come along and forbid people from claiming conformance
with this guideline for their pages. There would be, after all, no
way for the author to link to a glossary that doesn't exist.
>2. The original "B. reasonableness of length and complexity of
>sentences" would be replaced by language that suggests possible
>tests: sentence length and complexity should be consistent with
>practices recommended by widely used textbooks about writing in the
>relevant discipline
Let's have a full bibliography of all such books published in the
last ten years in the English language. You mean there *isn't* a
textbook published about how to write in, say, automotive mechanics,
organic chemistry, needlepoint, homemade tofu, or even...
accessibility? Shock.
>4. The call for "clarity of headings and link text when read out of
>context" is modified to include specific situations where headings
>and link text must be understandable, e.g., in lists of links and
>headings reported by screen readers
This continues to be an extremely serious mistake the Working Group
cannot stop itself from making. I have explained over and over
again-- including face to face at the Toronto meeting-- that our task
is not to custom-craft guidelines that suit the peccadilloes of
whatever adaptive technology the Working Group politburo happens to
like. (This always means Jaws and Internet Explorer for Windows.) You
can*not* expect authors to write valid, semantic HTML pages that
*also* make sense when someone comes along and removes all their
bones.
I want a straight answer (preferably from Wendy, sitting right next
to me at the f2f) why this one hasn't been deleted forever. It *is
not an accessibility aid* in Web content development. At best it's
something a revised User Agent Accessibility Guidelines could handle.
>5. The item about accuracy of page titles is now written in sentence
>form and calls for page titles to be unique and informative
>(consistent with Seaman proposal)
I have strong reservations about the possibility of doing this across
the entire Web. Unique compared to what? Every other page you've ever
seen on that site? Every other page ever served by that site? Lisa
has only ever given hopelessly simplistic examples that betray
simplistic real-world Web usage. Book a couple of airline tickets,
particularly with price comparisons, and let me know how this is
gonna work.
The *page content* matters. Unique <title> elements are less
important than *meaningful* <title> elements. Unless of course your
computer platform is Microsoft Windows, in which the stacking of
multiple seemingly-identical buttons in the Taskbar might lead you to
demand unique titles. (What if they're the same all the way down to
the 50th character? Are they still "unique"? What if I serve up a
300-character <title> element just to comply with this guideline? Do
you really want to listen to that in Jaws?)
>6. The item about care in using all caps is deleted as being
>categorically different from other criteria in this list. The
>deletion is NOT consistent with the Seaman proposal.
Isn't it fun how John uses ALL CAPS to talk about ALL CAPS?
Also, I take this passage to mean that Lisa has the Working Group by
the gonads and everything she says goes. She makes a single proposal
and you rewrite the Guidelines just for her. I prove your Guidelines
are factually incorrect, sometimes saying it to your very faces, and
you pretend it never happens.
If you're tired of my saying all this over and over again, quit doing
it and I'll stop.
--
Joe Clark | joeclark@joeclark.org
Accessibility <http://joeclark.org/access/>
Expect criticism if you top-post