- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Wed, 21 Jan 2004 08:19:03 -0600
- To: "Joe Clark" <joeclark@joeclark.org>, "WAI-GL" <w3c-wai-gl@w3.org>
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
Received on Wednesday, 21 January 2004 09:19:05 UTC