RE: Key results and recommendations from Face to Face

Hi Al,

Some feedback on your comments.

AL: Just because UAAG 1.0 doesn't answer all questions doesn't mean it
shouldn't be a key source in profiling User Agent expectations.

GV: Agree.  We didn't say we won't be using it.  we just said that it didn't
answer the questions needed about baseline.  It didn't set a baseline for
what authors could assume - only what UA makers should provide. 

AL: The pace of change in browser functionality has slowed radically
since 1997 when the WAI was launched.   

GV: Yes it has.  But it constantly changes - and will quite a bit over the
(hoped for) lifetime of WCAG 2.0.  

AL: Who will do this?  Should we enlist DLNA?

GV:  We have several ideas on this.  we didn't post them since that wasn't a
consensus item.    We will be posting something soon discussing this.  WAI
might suggest. (but not in WCAG)  Governments, companies, customers,
manageres might.    There was some suggestion that it might have to differ
for some contries or it would be too high for developing countries and too
low for some of the most supported.    Don't understand DLNA comment.  That
is a consortium primaarily interested in home audio video components.  

AL: A plan more in line with the W3C culture would be:
WCAG requirements should be identified at
the functional outcomes level.  The W3C standard way
to publish this is a Requirements Document which has the
status of a Working Group Note.
In addition, requirements should be identified in
bindings to a variety of widely-used Web technologies.
These can and perhaps should be normative.
At the very least, they should be no less authoritative
than the more abstract requirements.

GV: This Guideline - which may be required by government policy - is
different in nature than a voluntary technical guideline.  We are trying to
work toward something that can be normative and used by many countries who
have different needs and support.   It must be done very carefully to not
create barriers while it tries to remove them.   More on this when we post a
longer description of the approach overall

AL:  Cannot follow the logic, here.  Normative is not equal to restrictive.
The UAAG has provided a fine example of declaring *sufficient*
techniques which are then normative, but not restrictive.

GV:  Perhaps we have a different understanding of normative.  If something
is sufficient but not required - I don't think of it as normative.  It is
just informative.  The requirement is the requirement.   The technique is
just one way of solving it. it is not a requirement.   I guess if you word
it as a declaration of conformance criteria it would be normative.  But we
are being careful (or want to be) to not make the techniques doc normative
so we can update it as an ongoing informative doc. 


AL: Without agreed methods of observing the de-jure normative
functional outcomes, will not the guidelines be unenforceably vague?

GV: Don't think so.  We have an ad hoc looking at that now.



AL: Adopting the above [below] stated level of abstraction is dubious in the
absence of a fully fleshed out proposal about the profilable
conformance assessment scheme.

GV: Working on it.  We are just reporting how far we got in those two days.



Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Al Gilman
Sent: Thursday, March 24, 2005 2:44 PM
To: w3c-wai-gl@w3.org
Subject: Re: Key results and recommendations from Face to Face


These sound scary.

At least, at a preliminary discussion of this direction in PF,
serious reservations were expressed.

A few, not exhaustive or definitive examples inline below.

Al

>From: Gregg Vanderheiden <gv@trace.wisc.edu>
>Date: Tue, 22 Mar 2005 21:18:13 -0600
>To: <w3c-wai-gl@w3.org>
>Message-Id: <20050323051833.95C3960C14B@m18.spamarrest.com>
>
>
>
>At the WCAG Face to Face in Los Angeles March 21, 2005 the working group
>made very good progress on our key questions regarding baseline and
>structure.  
>
>
>
>On structure we reached agreement on an overall structure  - and are now
>putting it together in a form that is easy to review.  We will submit this
>to the list as soon as we can get it pulled together with some examples.
>Basically it is not terribly different than what we have but straightens
>things out and makes the roles of the various documents clearer. 
>
>
>
>On baseline we reached consensus on the items listed below.  The consensus
>was unanimous with the following people in attendance: Jenae Andershonis,
>Mike Barta, Doyle Burnett, Ben Caldwell, Wendy Chisholm, Michael Cooper,
>Becky Gibson, David MacDonald, Loretta Guarino Reid, John Slatin, Andi
>Snow-Weaver, Makoto Ueki, Gregg Vanderheiden, Takayuki Watanabe
>
>
>
>These are submitted to the list for review. 
>
>We will accept comments from the list - and then consider the following
>items for formal adoption with revisions to accommodate list comments.
>
>This review for adoption will take place at the working group
teleconference
>on March 31st  2005 .
>
>
>There were 5 consensus (unanimous) items from the meeting. 
>
>
>1) Can't use UAAG as Baseline
>
>
>It was concluded that UAAG 1.0 does not resolve the baseline issue because
>it does not resolve key questions like whether script support is provided.
>
>We will therefore not be relying on UAAG as a baseline.

Just because UAAG 1.0 doesn't answer all questions doesn't
mean it shouldn't be a key source in profiling User Agent
expectations.

>2)  WCAG not set any explicit baseline

The pace of change in browser functionality has slowed radically
since 1997 when the WAI was launched.

Who will do this?  Should we enlist DLNA?

>WCAG will not set an explicit baseline; instead, external decision makers
>will make baseline assumptions or requirements. These include [but are not
>limited to] governments, customers, companies, managers, and authors.
>
>
>3) WCAG written as functional outcomes and not assume user tools and
>technologies
>
>
>WCAG will not explicitly state what technologies are supported or what
tools
>users will have at their disposal. WCAG criteria should be written as
>functional outcomes (see clarification #1) and therefore should not be
>specific to any technologies such as scripting, css, etc.

A plan more in line with the W3C culture would be:

WCAG requirements should be identified at
the functional outcomes level.  The W3C standard way
to publish this is a Requirements Document which has the
status of a Working Group Note.

In addition, requirements should be identified in
bindings to a variety of widely-used Web technologies.
These can and perhaps should be normative.

At the very least, they should be no less authoritative
than the more abstract requirements.

>4) With regard to baseline and techniques:
>
>
>1.	Techniques can not be more restrictive than guidelines otherwise
>techniques become normative.

Cannot follow the logic, here.  Normative is not equal to restrictive.

The UAAG has provided a fine example of declaring *sufficient*
techniques which are then normative, but not restrictive.

For example:
http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content

>  [and Techniques should never be normative.]

Normative techniques would seem to be necessary to synchronize
practice between authoring tools and user tools. Take the example Jon
Gunderson is pushing us to answer: "How does the AT or UA know from
the markup that something is a navbar?" (so that go-to and
escape-from methods can be furnished for this object)" Authors won't
do what the browsers and AT don't support, and vice versa. Agreements
in the form of consensus conventions are the W3C way out of this
chicken-and-egg dilemma. How do you justify the above statement? It
seems straight backwards.

If the techniques are not normative, how will anybody on one side of
the equation believe that the other side will fulfil the contract?

In one model of progress, practices evolve from experimental
techniques to known-good techniques to normative techniques to hard
technology (embedded in and enforced by the technology platform).
Normative techniques are an essential stage in the life-cycle of
technological practice.

>2.	Techniques documents may provide multiple techniques and those
>techniques may differ based on user agent assumptions. For example, we
could
>have 2 techniques: 1. how to make scripts accessible for user agents and
>assist. tech that support scripts 2.  how to write content in such a way
>that if scripts are turned off the content degrades gracefully (i.e., still
>usable w/out scripting).  however, these two techniques are not mutually
>exclusive and one or the other is used depending on what technology choices
>are made.
>
>5) Tests not set baseline

Without agreed methods of observing the de-jure normative
functional outcomes, will not the guidelines be unenforceably vague?

>
>Tests will not set a baseline.  Multiple tests may be provided to
correspond
>to multiple techniques.
>
>
>Clarifications:
>
>
>1.	Scripting is used as an example because that has come up often.
>These assumptions also apply to plug-ins, etc.
>2.	Functional outcomes  - may require tweaks of existing guidelines or
>success criteria
>3.	Conformance claims are not addressed by the resolutions from 21
>March 2005. This requires future work.
>
>
>
>
>
>
>Action and timeline items from Face to Face:
>
>
>Before 24 March telecon
>
>
>*	Each person think about consequences from resolutions from 21 March
>2005
>
>
>At 24 March telecon
>
>
>*	Discuss consequences from resolutions of 21 March 2005
>*	Discuss long-term plan
>
>
>By 28 March
>
>
>*	Mike [Gregg, Michael, John] - Impact assessment per guideline and
>success criteria
>*	Michael [Becky, Ben] - Impact assessment for techniques (classes of
>techniques: conformance, informative, additional)
>
>
>At 31 March telecon
>
>
>*	Consider for adoption resolutions from 21 March 2005

Adopting the above stated level of abstraction is dubious in the
absence of a fully fleshed out proposal about the profilable
conformance assessment scheme.

Al

>
>*	Impact assessment per guideline and success criteria
>*	Impact assessment for techniques (classes of techniques:
>conformance, informative, additional)
>*	Status reports on Guideline 4.2 proposal and conformance claim
>assessment/proposal
>
>
>By 4 April
>
>
>*	Wendy [Ben, Mike] - Proposal to discuss/solve conformance claims
>(impact assessment)
>*	Loretta [Mike, David, Andi] - Revisit guideline 4.2 issue summary
>and generate new proposal for Guideline 4.2
>
>
>At 7 April telecon
>
>
>*	Proposal for Guideline 4.2 (from LGR, MLB, DMD, ASW)
>*	Conformance claim assessment/proposal
>
>
>By 11 April
>
>
>*	John [Ben, Michael, Wendy, Gregg, David, Becky] User analysis for
>structure and structure proposal/prototype for 1.1, 1.3, 2.4, 3.1, and new
>4.2
>
>
>14 April telecon
>
>
>*	Discussion of structure prototype
>
>
>By September - be stable enough for WAB Cluster work to move forward on
>evaluation suite.  Minimum: Candidate Recommendation?? (check timeline)
>
>
>
>
>
>
>
>
>
>
>Gregg
>
>------------------------
>
>Gregg C Vanderheiden Ph.D.
>Professor - Depts of Ind. Engr. & BioMed Engr.
>Director - Trace R & D Center
>University of Wisconsin-Madison
>< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848 
>For a list of our list discussions http://trace.wisc.edu/lists/
>
>  <http://trace.wisc.edu:8080/mailman/listinfo/> 
>
>
>
>
>
>Received on Wednesday, 23 March 2005 05:18:46 GMT
>
>     * This message: [ Message body ]
>     * Next message: Shadi Abou-Zahra: "Re: Key results and 
>recommendations from Face to Face"
>     * Previous message: Michael Cooper: "[techs] CANCELLED 
>Techniques Teleconference 23 March 2005"
>     * Next in thread: Shadi Abou-Zahra: "Re: Key results and 
>recommendations from Face to Face"
>     * Reply: Shadi Abou-Zahra: "Re: Key results and recommendations 
>from Face to Face"
>     * Maybe reply: lguarino@adobe.com: "Re: Key results and 
>recommendations from Face to Face"
>     * Maybe reply: Michael Cooper: "RE: Key results and 
>recommendations from Face to Face"
>     * Maybe reply: Michael Cooper: "RE: Key results and 
>recommendations from Face to Face"
>
>     * Mail actions: [ respond to this message ] [ mail a new topic ]
>     * Contemporary messages sorted: [ by date ] [ by thread ] [ by 
>subject ] [ by author ]
>     * Help: [ How to use the archives ] [ Search in the archives ]
>
>This archive was generated by hypermail 2.2.0 + w3c-0.30 : 
>Wednesday, 23 March 2005 05:18:48 GMT

Received on Friday, 25 March 2005 02:17:07 UTC