Re: Structure of deliverables: are we too PC for our own good?

Thank you for summarizing your understanding of the issues.  There is at least
one issue I feel that I don't find here, so let me float it and see what
people
think.

It is interesting that all the issues you list deal with what comes after part
(a).  

Part (a) is summarized as

>(a). Guidelines/checkpoints/success criteria, as published in the
>principal guidelines document. These are formulated in
>"technology-neutral", yet precise terms.

The idea that technology neutral terms are used here could be an issue.

At least, it contributes to making two things difficult.

It makes it difficult for the content development community to apply what is
said, and it makes it difficult to make precise statements.  The second
difficulty reaches P2 criticality at least in the area of ameliorating
barriers
affecting cognitive impairments.  More generally, it increases the cost of
producing work product.  The first difficulty reduces the effectiveness of
this
piece of the work product.  Cap it all by dubbing this part "the _principal_
document" and you start having a task description that is daunting enough to
engender a significant level of worker frustration.  And we may have been
observing some worker frustration.  Is the frustration built into the actual
objective, or is it an artifact introduced by our work rules?

I want to offer a little more discussion of why a "principal document" that
declines to name names in terms of technology [and, in fact, in terms of
disability] may not be the most effective strategy for this group.

Our objective is to propose a win-win deal to the content development
community.

A win for people with disabilities, because content produced pursuant to the
deal offered will work for them.  A win for content producers for two
reasons. 
For one thing, they have readily followed objective techniques to follow, and
don't have to learn arcana about lots of different disability groups.  For
another thing, there is the "canary in the mineshaft," or "curbcut" effect. 
Fixing things that are failure modes for people with disabilities does have
collateral usability benefits in the wider community.

Here I want to appeal to William Ury's teaching about how to discover, frame,
and sell a win-win deal in the course of a negotiation.  [Book: Getting Past
No]  What I want to focus on is the 'discovery phase' leading to
'stipulations'
in the language of judicial adversary processes in the U.S.  What this boils
down to is that one tries to maximize through mutual discovery a body of
assertions that both or all sides will accept or stipulate as agreed
a_priori. 
These things we don't have to argue about or for.  To get things
stipulated, it
really helps to be able to frame them as matters of fact.  If we can qualify
some statement in others' eyes as a matter of objective fact, that will appeal
to many people as cause to stipulate and not argue about those points.
This is
a long winded way to say, what we can convince ourselves are statements of
objective fact, and can state in a way that appeals to others as observations
of objective fact, are easy to get accepted.  Whatever we can cover that
way we
should, before we go after the more debatable points requiring judgement calls
or an appeal to abstract moral principles.  It could be that this is the best
way to characterize what we offer the web development community: that we have
collected and connected the relevant facts.  We have done their research for
them, and they can make informed decisions now because we eliminated the
research step.  All they have to do is skim the research report we produce and
formulate their plans in the light of what they learned.

Now, as a matter of judgement, it seems to me that it is extremely
difficult to
frame credible statements of objective fact in this area without naming names
as to both disability and technology.  Explanations of the interaction of
specific disabilities with specific technology usage are easy to state in a
way
that is easy to accept as fact.  Try to purge the statements of any trace of
specific disabilities or technology and one is left uttering "psychobabble."

Our major mission is to come up with a consolidated recommendation that has
broad and non-discriminatory benefit for all manner of people with
disabilities, and proposes strategies that work around conflicts between the
interests of different groups.  On the other hand, if we insist in our working
medium on euphemizing what we have to say by failing to name specific
disabilities and technologies, we may just have shot ourselves in the foot.

If our primary means of selling our recommendations is by appealing to their
basis in fact, and the facts are not recognizable as facts without naming
[disability and technology] names, then trying to frame precise statements of
the threshold of acceptable usage in disability- and technology-blind language
may not be in the cards.

Perhaps the primary things that users of our work product need to be able to
[on user election, that is to say on a 'pull' protocol basis...] get from it
are:

- for a given work task that they are assigned, to ascertain what advice of
ours pertains.

- for a given piece of advice of ours; if they wish, to review the reasoning
behind it.  This may mean some of each of the following:

+ traceability to a failure mode, if violating the advice leads to failure for
some condition
+ traceability to an optimization, if following the advice makes significant
contributions to usability and effectiveness across some range of conditions
+ comparison of the impacts on differently-affected groups, where we had to
engage in trades and balances reasoning to come up with a recommendation.

The units of advice may be technology-specific or technology-abstracted or
both, but including the technology-specific statement [or applicability, in an
index] of units of advice in the main body of work, the nominal scope of our
principal work product, will definitely help with the "find applicable advice"
step.

The backups at the ends of the "traceability" links are probably best
stated in
language which is specific as to disability condition and only as abstract
with
regard to technology as is clear.

The principal quality factor for our output could possibly be the ease with
which our readers move between the advice and rationale levels of exposition,
so that we get a user-directed depth of browse as they move through this
material.

By putting a major document and work division between the consolidated,
disability-and-technology-spanning advice and the
disabilty-and-technology-specific facts, we may be making our task
significantly more difficult, and more frustrating, than it really needs to
be.

Does this make any sense?

Al

At 02:23 AM 2001-09-07 , Jason White wrote:
>The following message attempts to summarize the open issues which have
>arisen with respect to the structure and composition of the working
>group's deliverables, in particular the role and status of techniques
>and associated requirements.
>
>Thanks are due to Gregg for his prompt and helpful review of this summary.
>
>
>Outline:
>
>The structure of this working group's deliverables is as follows:
>
>(a). Guidelines/checkpoints/success criteria, as published in the
>principal guidelines document. These are formulated in
>"technology-neutral", yet precise terms.
>
>(b). Concise, concrete explanations of how to meet each checkpoint. Some
>of these are, but others may not be, technology-specific (see the
>discussion below).
>
>(c). Miscellaneous commentary, code examples explanatory materials,
> and alternate ways to accomplish the strategies which again may be
>specific to particular technologies.
>
>HOW THESE RELATE TO 1.0
>In WCAG 1.0, layer (a) appears as a W3C Recommendation (Web Content
>Accessibility Guidelines 1.0), though it should be noted that the
>guidelines and checkpoints are not expressed in fully general terms
>and involve subtle technological assumptions and dependencies which
>have been largely eliminated in the WCAG 2.0 working drafts.
>
>Layers (b) and (c) are combined, at least conceptually, in techniques
>documents, though the means of satisfying checkpoints have not been
>expressed as concise and clearly identifiable assertions. In WCAG 1.0,
>there are no success criteria associated with each checkpoint.
>
>
>
>Open issues:
>
>1. What should appear in layer (b), and how should the requirements at
>   this level be organised? Obviously, some of the "implementation
>   strategies" are technology-specific (that is, they pertain to
>   particular standards and formats, such as (X)HTML, SVG, etc.).
>   However, there are checkpoints under guideline 3, and possibly
>   guideline 2 as well, which would be implemented in largely the same
>   manner irrespective of which technology is to be used. For example,
>   in applying checkpoint 3.3, the technology (HTML< PDF< SVG etc.)
>   is irrelevant to the way in which an author proceeds to satisfy the
>   checkpoint. In other cases, there are only trivial differences (for
>   instance, checkpoint 3.4 obviously involves the association of
>   sounds/images with content, but the markup code or other mechanism
>   with which to accomplish this is well known and there would be
>   little benefit in writing separate techniques for each technology
>   in relation to such a checkpoint). Rather, techniques related to
>   checkpoint 3.4 would need to explain under what circumstances
>   auditory/graphical supplements aid comprehension and how to design
>   them effectively.
>
>Similar issues arise in respect of checkpoint 1.1: although the
>mechanisms by which text equivalents are provided varies according to
>the technology which is used, the underlying conception of what
>constitutes an adequate "text equivalent" remains constant.
>
>In WCAG 1.0, these issues were addressed by writing a "core
>techniques" document which discussed issues and strategies of broad
>application that were not technology-specific, and a set of
>technology-specific documents (HTML, CSS, etc.).
>
>A comparable solution is needed for WCAG 2.0.
>
>2. How should the requirements of layer (b) be formulated?
>
>A central concern underlying discussions of WCAG 2.0 has been that the
>"implementation strategies" be expressed in clearer and more concise
>terms. For example, it has been argued that where there are
>alternative means of satisfying a checkpoint using a specific
>technology, it should be made plain to the reader exactly how many
>alternatives are provided, what they are, and whether each of them is
>sufficient (by itself or in specified combinations) to satisfy the
>success criteria stipulated in the guidelines, and hence the
>checkpoint itself.
>
>The working group needs to decide whether the strategies set forth in
>layer (b) should follow a prescribed format, and if so, what that
>format should be.
>
>3. Should layer (b) be included in one or more normative documents
>   (i.e., W3C Recommendations), or should it be informative only?
>
>Advantages of normativity:
>
>I. Developers who successfully implement relevant requirements from
>   layer (b) will thereby have some assurance that they have satisfied
>   the corresponding checkpoint or checkpoints.
>
>II. Layer (b), as part of a W3C Recommendation, would receive the same
>   close scrutiny and careful review as the guidelines themselves.
>
>Disadvantages of normativity:
>
>I. Normative documents are slow to change as technology evolves, due
>   to the requirements of the W3C process.
>
>II. If layer (b) were normative, this would complicate the over-all
>   conformance scheme of the guidelines, because it would be necessary
>   to deal with the possibility that an implementor could successfully
>   satisfy the success criteria associated with a checkpoint, but in
>   ways other than those prescribed in layer (b).
>
>III. The existence of success criteria in WCAG 2.0 provides greater
>   clarity regarding what must be achieved in order to satisfy each
>   checkpoint. This at least partially satisfies the need for
>   precision and certainty which motivates the desire, on the part of
>   some members of the group, that layer (b) be normative. Hence, it
>   may no longer be considered necessary to make layer (b) normative.
>
>IV. If the requirements in layer (b) do not provide complete
>   "implementation strategies" for satisfying each checkpoint, then it
>   would still be necessary for implementors to assess their content
>   by reference to the guidelines document itself, rather than solely
>   in relation to various "specific" (layer b) requirements. Thus
>   there may be little advantage to developers if layer (b) were
>   normative.
>
>4. What should layers (b) and (c) be called? The question which has
>   received most consideration in this context is, what should we call
>   layer (b)?
>
>Suggestions include:
>
>I. Techniques.
>
>II. Technology-specific checkpoints.
>
>III. Implementation strategies (or simply "strategies").
>
>IV. Checkpoint solutions.
>
>Observations:
>
>As noted above in connection with guidelines 2 and 3, many of the
>requirements in layer (b) are unlikely to be technology-specific;
>hence it would be misleading to refer to them all as
>"technology-specific checkpoints". Also, they may not be analogous to
>"checkpoints" as such, especially where several alternative strategies
>are given for achieving the same result.
>

Received on Saturday, 8 September 2001 15:19:44 UTC