- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Tue, 2 Oct 2001 00:16:22 -0500
- To: "GLWAI Guidelines WG \(GL - WAI Guidelines WG\)" <w3c-wai-gl@w3.org>
FYI -- CURRENT LIST OF ALL CONSENSUS STATEMENTS These will soon be added to the REQUIREMENTS document as an appendix. You will then always be able to find the latest version there. Gregg RE: RELATION OF OUR GUIDELINES TO REGULATION EFFORTS 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) N-8 If techniques or examples for a normative checkpoint (guideline) are not generally applicable across web sites, then the checkpoint or guideline must be qualified/restricted to those conditions where the techniques would work. N-9 Our normative portions would (as qualified) apply to sites in general. Our informative portions can give information that may apply to sites in general or to special targeted sites as long as they are clearly labeled. 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: GENERAL ISSUES / COMMENTS G1 - 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. G-2 Accessibility and usability are intertwined and vary between people and tasks. We think that our distinctions and decisions about normative or importance will be based on something other than categorizing them as an "accessibility" or "usability" items. APPLICABILITY - COVERAGE - SCOPE A-1 Cannot make products accessible to all A-2 How to draw the line? As accessible to as many people as we can create the techniques and criterion A-3 We should expend our best effort to identify techniques, criteria and examples that would cover the greatest range possible
Received on Tuesday, 2 October 2001 01:17:16 UTC