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.html> 
>, 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

Received on Tuesday, 20 January 2004 18:49:54 UTC