Re: Consensus on Elephants

Just a few quick thoughts.

These issues are pretty tightly interdependent.

There is one example in here were a top-down analysis suggests that a
world-wide norm is not something we can gain acceptance for.

This is in the language diversity area.

Language diversity is highly political.  Political units have policies in this
regard and the policies vary.  I seriously doubt that we as W3C can set a
'mondiale' standard of service in this respect and have it adopted around the
world in place of the local-option existing policies given that language is so
closely tied to cultural differences that are the subject of bitter emnity and
mortal conflict.

Likewise, there is a bottom-up argument for why a world-wide setting of a
standard of service is not something that can be sold off as justified by a
technical analysis.

Take point 9, "access for absolutely all?"  The question is where do you stop
laying demands on the content providers for pockets of the underserved with
smaller and smaller counts?

Or at least I am going to examine the question as if it were taken in that
sense.

There is a school of policy analysis we might call economic rationalism that
says one sound rule for stopping adapting the automatic means of service
delivery at the point where the cost of providing personal assistance to
deliver service to the remaining underserved is less than the cost of
upgrading
the technologized service to reach this population.  The cost of providing
personal assistance as opposed to technology varies radically across economies
around the globe.  So the point at which this cost exchange flips sign is very
locale dependent.

If we try to set a standard for service, we know we find we have a great deal
of trouble agreeing amongst ourselves.  There is some evidence to suggest that
when we are done it is not clear to others there is a compelling reason why
they should take our answer.  

If we focus our efforts on delivering a service which provides factual answers
to questions concerning what content strategies have, or avoid, what access
problems, and leave threshold setting to duly constituted policy setters, we
may have reduced our problem to something where we can close more rapidly on
agreement amongst ourselves, and we find our results are eagerly grabbed off
the presses.

Al

[mantra:  just tell them what you know]

At 12:56 AM 2001-09-11 , Gregg Vanderheiden wrote: 

>
> 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>mailto:Gv@trace.wisc.edu>,
> <<http://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> 
>
>  
>
>  

Received on Tuesday, 11 September 2001 08:53:38 UTC