Issue #9 - RE: Summary of discussion related to baseline and techniques

Hi Wendy,

I won't be on tomorrow's telecon, so I'll try to answer the question here.

>Issue #9
>Action: Ask Neil what he meant by, "WCAG published baseline."

What did I mean by "WCAG published baseline"?

I'm probably stating the obvious, but with respect to "baseline", I am of
course referring to the current "baseline issue".

Indulge me for a minute while I reflect on some of the background behind my
original statement.

Whatever the outcome of the current discussions on baseline, the following
statement is probably true:
"The act of developing a technique that enables an author to satisfy a SC,
inherently involves making at least one UA assumption".

In an ideal world that assumption would be the same for all techniques i.e.
"The set of target UAs are assumed to conform to UAAG 1.0 level A". However,
even in our ideal world, UAAG 1.0 P1 checkpoints provide users with the
ability to alter UA state i.e. JavaScript on/off, CSS on/off etc. Therefore,
additional assumptions must also be made regarding UA state as well as the
set of target UAs. "Bang", goes our ideal world.

Where techniques are technology specific, (X)HTML, CSS etc., those
techniques must be tested across a range of UAs and in varying contexts. Is
it good enough to offer simple CSS techniques in isolation? Many are treated
differently by different UAs, as we all know, and differently again
depending on context i.e. the styling of parent, sibling and child elements
can affect the outcome of applying our technique(s) on our element(s)
differently across UAs.

If an author cannot satisfy a particular SC because he/she is unable to
implement a recommended technique and cannot find an alternative technique
that works in his/her target environment, are his/her assumptions about
his/her target environment incorrect? Is the WCAG technique broken or is the
SC impossible to satisfy? Is it just that WCAG and the author are operating
in different target environments and hence the SC or technique in question
is out of scope? How would the author know that he/she had made a different
baseline assumption to WCAG? Is it OK to make a different baseline
assumption? If it is and it has a detrimental effect on the outcomes, how
can he/she claim conformance?

So, what I was getting at was that WCAG must acknowledge *that* assumptions
are being made in developing techniques, it must state *where* assumptions
are made, *what* those assumptions are, and *how* they were derived (i.e.
the metrics, if any, upon which they are based). WCAG must also state the
test environment used when developing technology specific techniques. This
information must be documented and made available to authors either within a
separate WCAG deliverable or dispersed within existing deliverables. Either
way, the end result is a "published baseline".

The deliverables must also answer the questions raised (amongst others) in
the paragraphs above.

Hope that makes sense.

Regards,

Neil.
________________________________________
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Wendy Chisholm
Sent: 31 March 2005 02:30
To: wai-gl
Subject: 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/
/--

Received on Thursday, 31 March 2005 05:13:32 UTC