RE: proposal 3: checkpoint 3.3

Good points.
The only point I think that I really disagree with you is on your
statement

"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."

So far as I can tell you think that we need to ensure is rework the core
to make it normative- although where it is not normative I do not
actually know. 

Secondly from what I understand of your arguments you have issues with
checkpoint s, requirement 1 and 2, but to me they sound surmountable -
ones that we have some work to do -cross group and a strong note has to
be attached that the mechanism must be in place before release.

I think your comments on criteria  3 -7 
 are also valid, as they are restrictive. I see tow approaches to solve
this
1: that we decide that extended checkpoint may be restrictive and not
appropriate in many scenarios
2: we rework these points until we get it less restrictive and more
appropriate.
I actually would go for something in-between were we work the checkpoint
as much as we can to make it as practical as possible - and leave it
there- keeping in mind that this is an extended not a core checkpoint.  

OK my example of a  "flexible" 
 3. There is a public available policy statement of acceptable maximum
length of nown phrases,  sentences length,  paragraphs and that this
policy is conformed to on the site
 4. There is a public available policy statement of acceptable number of
words in sentences  and that this policy is conformed to on the site
  3. There is a public available policy statement of acceptable maximum
number of  sentences in  paragraphs and that this policy is conformed to
on the site
 Then a note on how to make a policy statement ( e.g.- a policy
statement should  balance  and justify the following factors - what
length etc is truly necessary on the site, v the people who will find it
harder to understand the site.)

 8.	The key term or idea of each paragraph is easily identifiable 
(techniques: through markup like em, or by "front loading")
This is human testable - is a key term highlighted? Id it near the front



> 9.	Inclusion of non-text content to symbolize or replace text for
key 
> pages

I do not understand your position on this - that we are not good at
this, so forget it, It is true that we are not good at it, but we have
had lots and lots of evidence over the years on this list, and have been
begged to remember that "a picture says a 1000 words" To someone who has
a word 



10 through 14  you felt are style guidance. As such, they should not be 
Normative. Again they may be style guidance but they are also
accessibility issues. For example 
"Provide all steps in  required actions" - content that misses out steps
is affect


One thing I think we have to agree on. We need to incorporate guidelines
for cognitive disability.  Preferences to make anything that relate to
them as "best practices" is, in my opinion, not acceptable.


All the best
Lisa Seeman
 
Visit us at the UB Access website
UB Access - Moving internet accessibility
 



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.

Lisa - we can not omit something because it is inconvenient for current
authoring tools. What we do is write Author tools guidelines.......Or we
would never get any wear - (current tools do not create valid HTML..)

>  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.
Lisa - Unique is not subjective at all. Making since is testable and we
had agreed on human testable were 9 out of ten people will agree was
good enough...

>  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").

Lisa-- It is similar, but hear we are saying that you must _identify_ 
important content. See I just identified the word identify...



>  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.
-Lisa -  maybe and maybe not, it is more affective then putting it in
best practices, and if the only way we can is by a giving loop hole -
that is better then nothing - we had something similar for text in
images 

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


Ideally  you are right - lets do it in time for 2.0

On the other hand, in checking the words is similar
> 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 Tuesday, 12 August 2003 07:49:02 UTC