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 19:32:26 UTC