- From: Chris Brainerd <Chris.Brainerd@cds.hawaii.edu>
- Date: Mon, 11 Aug 2003 17:37:05 -1000
- To: "Matt May" <mcmay@w3.org>, "lisa seeman" <seeman@netvision.net.il>
- Cc: <w3c-wai-gl@w3.org>
I prefer specifics regarding the readability of text be relegated to "Best Practices." Chris Brainerd Instructional Designer Real Choices ACCESS Center on Disability Studies University of Hawaii Chris.brainerd@cds.hawaii.edu 808-956-9356 -----Original Message----- From: Matt May [mailto:mcmay@w3.org] Sent: Monday, August 11, 2003 1:31 PM To: lisa seeman Cc: w3c-wai-gl@w3.org Subject: Re: proposal 3: checkpoint 3.3 I continue to have reservations with normative "solutions" to language problems. I will state my position on this as clearly as I can: I am against any element in WCAG 2 that limits the language of the author's principal message. This includes: - Limits to words per sentence or paragraph; - Limits to syllables per word; - Limits to vocabulary; - Imposition of writing style requirements Therefore, I disagree with all of the proposed Enhanced success criteria to 3.3. Additionally, while I understand and agree with most of the points of 3.3 Core, I don't see how they can be made normative. Now, to defend that position: We destroy our own credibility by stating that we know enough about all content to state authoritatively that it is more understandable by Web users when authors use arbitrary numbers like this. These are all good ideas (in varying degrees) for certain types of content, but they are not backed by anything but an educated guess. With all due respect to the participants of this working group, we are not a group of language experts, not even with respect to English, and certainly not across a full range of languages. This approach lacks flexibility, and strict treatment of language is a fundamental problem. Newspapers have the Associated Press Stylebook to specify proper spelling and usage of words and phrases in news articles, along with other material relevant to journalists. However, even in this narrow context, AP style permits exceptions explicitly. Professional writers have historically offered themselves guidelines which they learn in such detail that they know when to violate them. I'm not aware of any style guides which are absolutely mandatory, nor any language checkers which are smart enough to catch meaningful errors. This approach does not localize (or localise, for that matter) well across languages. Particularly, limits to word or character count varies widely, especially with ideographic languages like Chinese. Language is not itself a standard. It is a product of experience, education and culture, both in terms of how it is created and how it is used. The problem experienced by many people with learning disabilities is one of context. All Web content as we define it is a one-way conversation. Since we have no way to see a user's confusion as they read our content and respond with "by which I mean...", our efforts to reach everyone with a common set of rules such that they can get it without context is, at present, limited. The key here is not to look inside, i.e., to expect us to bind up all our experience in each document, but to look outside, providing semantics that offer the user and/or her or his agent to seek that context it- or her- or himself. We are deluding ourselves if we write this document believing that all meaning and all interpretation belongs in each resource. It is not an achievable standard. This approach relies on something we cannot assume: the good faith of the author. In order for these criteria to be genuinely helpful in all situations, the author must constantly ask her- or himself, "how can I do this in a way that best satisfies users with disabilities," and I don't think anyone here can honestly believe that this is the common use case for WCAG. We must ensure, as a basic requirement of WCAG 2, that even the most cynical, cursory approach to satisfying a requirement will yield minimally positive results. If we do not, people will only "fix" sites to shut up the evaluation tool, and may do more harm than good in the process. This has happened many times before. Another point: people are really lousy communicators, and language, as we know it, is often not our best tool. Bad communicators make bad content, and no number of requirements is going to change that. We can only do so much in this document. What we want to say here is "think about this when you write," not "do this." As such, it should not exist in the form of normative success criteria. My suggestion: Move all of these into best practices. They do not belong in the (normative portion of the) Guidelines document we are working on. We do not have the expertise or credibility to define the stuff outside of the angle brackets in this working group. Comments continue below. On Saturday, August 2, 2003, at 11:21 PM, lisa seeman wrote: > criteria: > > 1, provide uniqueness of page titles This may be difficult or impossible in many modern content management systems, at least at the unprivileged user level. > 2, provide headings and linked text that are unique and clear when > read out of context This is highly subjective -- certainly not testable in the way we expect Core to be. > 3, markup of key information that the user most typically > requires with structural markup -(note: this is similar to1.3 [CORE] > however we are adding a requirement to _identify_ important content > - and then incorporate it into structural mark up ) This sounds like a criterion on 4.1 ("Technologies are used according to specification"). > 4, when the content is more important then the writing style, > clarify Syntactic and Semantic ambiguity, (but not word ambiguity). > -see end notes The attempt here to separate one type of content from another introduces a giant loophole. Nobody would hesitate to say their style is more important, if only to clear the requirement here. I think this would go completely ignored. > checkpoint 3.3 -E > checkpoint 3.3 -provide clear content > success criteria > > 1. All terms used are available in a linked to, fully accessible > accessible simple language lexicon, or supplementary lexicon of topic > specific Jargon Until a standard mechanism is launched and adopted by mainstream browsers and/or assistive technologies for LD users, along with an agreed upon format for creating such a lexicon, this is not adoptable. With that said, I think a lexicon standard is achievable, and would support its creation. But this checkpoint can't happen without that lexicon standard. > 2. A language structure is chosen to aid comprehension (such as active > voice in languages where this form helps convey information) This appears to be a good technical solution, but the burden on content providers would be immense. This reads "use a controlled language" to me, and almost nobody is going to adopt one. > 3. Strings of no more than three nouns are defined as a phrase in a > linked to lexicon > 4. Sentences without lists do not exceed 25 words. > 5. Do not use more then two conjunctions in a sentence or list item > (unless in a sub list). > 6. Paragraphs do not contain more then 7 sentences > 7. Separate ideas are provided in a separate paragraphs > 8. The key term or idea of each paragraph is easily identifiable > (techniques: through markup like em, or by "front loading") Disagree, for the reasons mentioned above. > 9. Inclusion of non-text content to symbolize or replace text for key > pages I've explained my position on this before, when it was (I think) checkpoint 4.3. As bad as we are with language, we're worse with visual communication. It's not what we are taught to do in school, and requiring it of all content producers doesn't make us any more adept at it. (Bear in mind that even user interface developers and graphic designers often have trouble creating meaningful icons, and they do this stuff for a living.) > 10. Clarity of references are provided for pronouns and anaphoric > expressions (these refer back to something already said in the text) > > 1. example of potential ambiguity: "Scientists study monkeys. They eat > bananas." > > 11. Conjunction forms and adverbs are used correctlyto make explicit > the relationship between phrases or parts of the text such as "and," > "but," "furthermore," "not only" > > 12. Clarify thelogic in the order and flow of information (for example > provide a summary, document map or flow diagram) > > 13. Provide all steps in required actions or inthe explanation of > instructions > > 14. Provideconsistency in the use of names and labels 10 through 14 are style guidance. As such, they should not be normative, as explained above. - m
Received on Monday, 11 August 2003 23:56:31 UTC