Summary of discussion related to baseline and techniques

In the set of proposed resolution sent 23 March [1], it says:

    1. Techniques can not be more restrictive than guidelines otherwise
    techniques become normative. [and Techniques should never be normative.]
    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.

[1] <http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0642.html>

What follows are 15 issues or statements with proposed actions.

*Issue *#1

    It may be unclear to some people that UAAG 1.0 has normative,
    sufficient techniques. These techniques are included in the
    specification and are non-technology specific. In the UAAG 1.0
    Techniques document (non-normative) technology-specific examples
    provide more information.


*Action*: Ask people to look at UAAG 1.0's sufficient techniques.
===

*Issue *#2

    There may have been confusion about the use of the term,
    "normative." The WCAG WG used the term to mean, "included in a W3C
    Recommendation and not in a W3C Working Group Note." In other words,
    our Techniques Documents are not on the W3C Recommendation track,
    they will be published as W3C Working Group Notes and therefore do
    not directly "effect" conformance.


*Action*: clarify use of "normative" with Al
*Action*: Determine if the existing definition of "normative" in the 
WCAG 2.0 glossary is sufficient. Current definition: "Required for 
conformance."
*Action*: refer to the definition in future discussions to avoid 
misinterpretations due to use of terms.
===

*Issue #3*

    There may be an assumption (or a belief) that Success Criteria are
    too vague and that we should strive to provide UAAG 1.0-like
    sufficient techniques. However, I think it could be argued that our
    success criteria are similar to the UAAG 1.0 sufficient techniques.
    In other words, I think {WCAG 2.0 success criteria are to WCAG 2.0
    Guidelines} as {UAAG 1.0 sufficient techniques are to UAAG 1.0
    provisions}.


*Action*: determine if our success criteria address the needs identified 
with UAAG 1.0 sufficient techniques or if further research or discussion 
is needed.
===

*Issue #4*

    There seems to be an assumption or belief that the only way to make
    progress on all fronts (authors, authoring tools, user agents,
    evaluation/repair tools) is for normative techniques.


*Action*: The use of "normative" is in question.
*Action*: Discuss other models of progress that do not include normative 
techniques and assumptions about most likely paths for progress and 
development in the future. Examples to consider are RSS and XHTML 
Friends Network which were codified at a grass roots level. Since the 
specifications are not produced by a consortium/standards-body, are they 
normative? Also, open source development, such as Firefox, which is also 
community-based and not based on traditional assumptions of progress.
===

*Issue #5*

    "We are striving for success criteria that are written as testable
    assertions about content in its encoded form and to provide
    sufficient and testable techniques for encoding that content. It
    makes sense to think of WCAG as specifying success criteria for
    content as encoded for the Web and to think of the techniques
    documents as providing advice about how to do the actual encoding.
    The tests then verify whether the encoding has been done correctly. "


*Action*: Discuss adoption as a "consensus item."
===

*Issue #6*

    "Standard" used as both "the way most people do it" and "the way you
    must do it to conform." Suggestion to use "conventional" or
    "typical" for "the way most people do it."

*Action*: discuss definitions of standard and typical as possible 
consensus items.
===

*Issue #7*
Proposed definition for the term, "conventional and supported manner" as

    1. A manner prescribed in a technical specification defining the
    technologies used to implement the content.
    2. A manner which has become customary within the community of Web
    content developers at large, or among specialists in the design of
    accessible content.
    With a claim that: "Supported" would have to be defined in terms of
    implementation by user agents or other applicable tools (e.g.,
    content validation and testing software). Again, it would have to be
    decided what the minimum necessary level of implementation was,
    bringing us back to the difficult question of user agent support.

*Action*: discuss proposal.
===

*Issue #8*

    "The baseline responsibility falls to authors and publishers who
    know their audiences. Authors will adjust baseline using a variety
    of data: access logs, published data, word of mouth, client
    requirements, and financial constraints. "

*Action*: Discuss where decision makers will get information and what 
information they will need.
===

*Issue #9*

    "How do authors identify the level at which they have set their
    baseline? Moreover, how do they claim compliance if their baseline
    is below WCAG published baseline? Is it possible to test varying
    baselines?"

*Action*: Discuss.
*Action*: Ask Neil what he meant by, "WCAG published baseline."
===

*Issue #10*

    "The most that should be required by WCAG 2.0 is that there either
    exist a UAAG 1.0-conformant implementation of the technologies
    relied upon by the content; or such repair techniques be implemented
    as to compensate for the shortfall of at least one implementation
    from UAAG 1.0.
    Informative advice regarding user agent support should be provided
    in techniques.Widespread availability of implementations is
    desirable but should not be part of any conformance requirement at
    least at level 1 and preferably not at all."

*Action*: discuss this proposal
===

*Issue #11*

    In order to be practically useful a technique would have to be
    adopted by authors and authoring tools. It would also have to be
    recognized by user agents and assistive technologies.

*Action*: Agreement that these pieces are essential to adoption and 
determination of "success" of a technique. Discuss. Sounds like 
technique sorting that Ben started.
===

*Issue #12*

    the techniques doc can neither make something 'required' by
    including it or make it not acceptable by omitting it.

*Action*: Adopt as consensus item?
===

*Issue #13*

    "Requirement" is another word that seems to cause confusion. Believe
    that we typically use the term to indicate if a testable assertion
    must be satisfied in order to claim conformance. Also assumption
    that conformance is measured against testable assertions in a
    normative document.

*Action*: Discuss. Adopt/write definitions?
===

*Issue #14*

    There were suggestions for how to handle success criteria for which
    there does not exist a technique that is implementable today.
    Response was that we can't publish guidelines that can't be met. We
    need to answer "what can't be done?" However, if we decide to remove
    those testable assertions which "can not be done, doesn't that
    create a slippery slope? What does "can't be done mean?" 1. can't be
    done easily, 2. can't be done today but will be possible in 2 years
    3. others?

*Action*: discuss. consensus should result in documentable 
resolution/consensus item.
===

*Issue #15*
Related to issues 10 and 11. Seemed a good restatement/summary of 
previous issues.

    if WCAG techniques were to step in at this point and recommend one
    usage as the norm, then we would be trying to set a standard in the
    techniques rather than recording established facts, with the
    expectation that software and content developers would follow what
    was in the techniques. Of course it might be argued that the
    techniques would just be making one of these methods better known;
    but the problem is that there aren't really, in this case, two or
    more acceptable methods; the technique will only work if it's
    adopted by tool and user agent developers. Having an agreed upon
    technique is almost more important than what the technique is. The
    issue I understood Al to be raising is how these issues would be
    settled at the technology-specific level if WCAG didn't provide
    normative requirements at this level. Such a problem is distinct
    from the so-called "baseline" issue, but it does raise important
    questions.

*Action*: Discuss.

A complete summary of statements that these are gleaned from is 
available at: <http://www.w3.org/WAI/GL/2005/03/summary-key-results.html>

Best,
--wendy

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--