- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 20 Sep 2001 23:35:51 -0400
- To: w3c-wai-gl@w3.org
[draft record of consensus] >>N3 - normative is determined by objectiveness -- ease of establishing >>consensus on fulfillment. > [Anne Pemberton] > I see problems with this .... [Al, here] So far this list only talks about 'normative' as though what we say is either 'normative' or 'not normative.' In the IETF they have found it helpful to have three grades of things that they find to say. These can be summarized by the graded series [MUST, SHOULD, MAY]. There are other keywords but they equate to these three in terms of their effect on 'normativity.' It could be reasonable for us to agree that one SHOULD minimize the dependency of your message on obscure words, and MUST annotate with definitions those terms that are essential to your message and not used in their standard meanings. In this it is not necessarily easy to gain consensus on when someone has minimized the dependency of their text on obscure words. It does not reduce to an objective Boolean pass/fail condition. But it unreasonable not to mention that they SHOULD do it, all the same. And while some find that SHOULD statements are weaker than they would prefer, it is still not quite right to say that they are 'not normative.' Is is possible that our 'objectivity' criteria should be different for things we say the content or content provider SHOULD do and things that we say they MUST do? Now, I know these code words are from a style guide for writing specifications. But as soon as we say that we are writing 'normative' stuff it is not that far from specification language. So we might think about more shades of grey that just 'normative' and 'not.' Al Ref: <<http://www.ietf.org/rfc/rfc2119.txt>http://www.ietf.org/rfc/rfc2119.txt> At 08:23 PM 2001-09-20 , Anne Pemberton wrote: >Gregg, > > I see problems with this .... if it is applied to the inclusion of >illustrations, it would be easy to fulfill by adding graphics, but >determining the illustrative value of the chose graphics may not be >objective. Likewise ... an alt tag may be determined as a string of text in >the right box, but determining the equivalency of the alt tag will not be >objective ... > > Seems some guidelines/checkpoints could have both normative and >non-normative attributes and techniques ... > >>N3 - normative is determined by objectiveness -- ease of establishing >>consensus on fulfillment. > > > Anne > > >At 06:46 PM 9/20/01 -0500, Gregg Vanderheiden wrote: >>Here is the latest list of CONSENSUS STATEMENTS >> >>New ones are marked with ** >> >>Please read them over and comment if you don’t consens. >>Thx >>G >> >> >> >>Consensus means "I can live with that". These are posted to see if >>there are problems with listing these as consensus for the working group >>at this time - so we can move on to those things where we need to >>address our >>discussion. >> >> >>ITEMS WHERE THERE WAS CONSENSUS IN THE GROUP. >>POSTED TO THE LIST FOR REVIEW. >> >> >>RE: OUR GUIDELINES AND REGULATIONS >> >>R1 - That what we develop should be usable by people who are writing >>regulations or requirements or policies (government, company, agency >>etc.) This is not the ONLY group - but it is one group we need to >>address. >> >>R2 - That our guidelines should not necessarily be directly usable or >>adoptable as regulations >> >>R3 - That our guidelines should have a "harmonizing" effect on >>regulations -- so that they cause regulations to be written so that they >>are similar and create similar or at least compatible demands on >>companies and individuals who must follow the regulations or standards >>or policies. >> >> >> >>RE: WHAT SHOULD BE NORMATIVE >> >>N1 - that technology specific checkpoints should be normative >> >>N2 - we shouldn’t be including anything (as normative) that we can't >>provide techniques and examples for. >> >>N3 - normative is determined by objectiveness -- ease of establishing >>consensus on fulfillment. >> >>N4 - we shouldn’t be including anything (as normative) that we can't >>provide success criteria for. >> >>N5 - things that are normative must be testable. (Testable does not >>mean it must be machine testable) >> >>N6 - that “testable by a tool” should NOT be required for normative >>items >> >>N7 - normative items should not be determined by how easy it is to test. >>(in time and effort) (Testability may be a criterion, but not ease of >>testing) >> >> >> >>RE: LEVELS AND SUBSETS OF CONFORMANCE >> >>C1 - we want to have recognition for accomplishment beyond baseline >> >>C2 - it is good to have levels of conformance rather than just all or >>nothing. >> >>C3 - there is a minimum set that conformance should not be possible >>without. >> >>C4 - should not be able to claim conformance by disability >> >>C5 - we WCAG should provide a way for people to see impact of items for >>particular disabilities but it should not be used for conformance. >>(see requirement 5) >> >>C6 - GL should provide hooks in WCAG to allow someone to provide a way >>for people to measure access against particular disabilities but it >>should not be used for conformance. [ Who should/would do the tool? >>GL or EO or ?] [Separate tool] >> >>** C7 - The success criteria (for a checkpoint) must be sufficient. >>(i.e. if you do them you comply. You would not have to do anything not >>in the list of success criteria.) >> >> >> >>RE: CLIENT SIDE AND SERVER SIDE SOLUTIONS >> >>S1 - serving content in different forms is an acceptable way to comply >>with the guidelines as long as equivalents for all of the information >>are provided in the different forms and it is all available through the >>same URI (though it may be linked to it) (server side solutions are >>acceptable as specified) >> >> >> >>RE: BROWSERS >> >>** B1 - Techniques should specify if particular browsers are needed or >>will not work with the technique. Or they should specify if they >>require particular technologies. e.g. You must have CSS2 support for >>this technique to work. >> >> >>RE: HOW OUR GUIDELINES ARE WRITTEN >> >>**W1 - Our document should be written as clearly and simply as is >>appropriate for the content, with links to definitions. We should go >>with the clearest and simplest language that someone can propose as long >>as it is accurate. > >Anne Pemberton >apembert@erols.com > ><http://www.erols.com/stevepem>http://www.erols.com/stevepem ><http://www.geocities.com/apembert45>http://www.geocities.com/apembert45 >
Received on Thursday, 20 September 2001 23:32:24 UTC