CONSENSUS REVISED 9-20-01

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.

Received on Thursday, 20 September 2001 19:46:59 UTC