Consensus on Elephants

In working on the 2.0 comments it  became clear that there were a number
of big issues that needed to be addressed.  We referred to them as the
Elephant Issues.   We therefore stopped to gather them.  Here is the
list we came up with.  
 
#4 is missing because we later determined that it was a duplicate with
number 13
 
 
   1. Baseline browser capabilities
      - in general
      - in specific contexts (intranet, public kiosk)
   2. User literacy level
   3. Differences by language
   5. How document is interpreted by non-technical people
   6. Implementation
   7. Normative vs. informative (do we need normative?)
   8. One version for all vs. multiple versions of web content
     - client-side vs. server-side
     - reading levels
   9. Access for absolutely all?
     - If not, how to draw line
   10. Guidelines for all sites vs. special sites
   11. Do we intend guidelines to be used by regulators and
requirements-setters (e.g., in companies)?
   12. Accessibility vs. usability
   13. Conformance - why do it? How to test?
   14. Author and user needs conflict
   15. User and user needs conflict
   16. What is an equivalent?
 
 
We then discussed these and tried to determine where there seemed to be
consensus and where not.   The following items are grouped into three
categories.
 
1 – Those that there was consensus on
2  - Those that there was some sentiment for but the group was not
comfortable yet  -- more discussion tomorrow
3 – Those that there definitely was not consensus on and there is
unlikely to be
 
 
1 – THOSE ITEMS WHERE THERE WAS CONSENSUS IN THE GROUP AND WHICH ARE
POSTED TO THE LIST FOR DISCUSSION
 
- 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.
 
- That our guidelines should not necessarily be directly usable or
adoptable as regulations
 
- 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. 
 
- we shouldn’t be including anything (as normative) that we can't
provide techniques and examples for.
 
- that technology specific checkpoints should be normative
 
- that “testable by a tool” should NOT be required for normative items
 
- 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)
 
- it is good to have levels of conformance rather than just all or
nothing. 
 
- there is a minimum set that conformance should not be possible
without.
 
- we want to have recognition for accomplishment beyond baseline
 
- 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) 
 
- 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.     [GL or EO or ?]   [Separate tool] 
 
 
=========================================
2 - CANDIDATE CONSENSUS STATEMENTS 
ITEMS THAT WERE MENTIONED BUT GROUP HAS NOT CONSENSED ON.
  
NOTE:  THERE IS NO AGREEMENT YET ON THE FOLLOWING ITEMS
 
-  we shouldn’t be including anything (as normative) that we can't
provide success criteria for.
-  normative is determined by objectiveness  -- ease of establishing
consensus on fulfillment. 
-  things that are normative must be testable.    (Testing  not equal to
machine testing)
- (testable and non testable ok? If separate????)
 
- things that are not normative should be in a separate doc. (or at
least not listed as guidelines)
(not remove from guidelines,  keep it prominent,  but make
separate/clear/??? that it is different.)
 
- that our guidelines should not be limited to only that information
that could or should be required today.   They should talk as well about
what would make web content more accessible where and when it is
possible - even if it is not possible everywhere today.    But it should
be clear what things are which (what is possible and reasonable today
for general application vs what may be possible in the future or
applicable only on some sites). 
 
THREE ALTERNATIVES DISCUSSED.
  -  conformance levels should be based on user needs only (and not ease
of implementation or ease of measurement/testing)
  -  conformance levels should take user factors and testability into
account.
  -  conformance levels should take user factors and testability and
ease into account.  (at least on a gross scale).
 
  -   conformance should be linear 
 
 
================================
3 – THE FOLLOWING ARE THINGS THAT THE GROUP REJECTED (THOUGH NOT
NECESSARILY UNANIMOUSLY)
 
- normative items should be determined by how easy it is to test. (in
time and effort)???
- we should be able to claim conformance by disability
- priority should be determined by ease of implementation (and testing?)
 
there was also no agreement on how to separate information that is more
important from that which is less important. 
 
 
 
 
Discussions will continue tomorrow.

Gregg 
 
For the Face to Face Group.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
-- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Human Factors 
Dept of Ind. Engr. - U of Wis. 
Director - Trace R & D Center 
Gv@trace.wisc.edu <mailto:Gv@trace.wisc.edu>, <http://trace.wisc.edu/> 
FAX 608/262-8848  
For a list of our listserves send “lists” to listproc@trace.wisc.edu
<mailto:listproc@trace.wisc.edu>