- From: lisa seeman <seeman@netvision.net.il>
- Date: Tue, 12 Aug 2003 13:42:20 +0200
- To: "'Matt May'" <mcmay@w3.org>
- Cc: <w3c-wai-gl@w3.org>
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