- From: Al Gilman <asgilman@iamdigex.net>
- Date: Tue, 14 Nov 2000 19:36:14 -0500
- To: Ian Jacobs <ij@w3.org>
- Cc: w3c-wai-ua@w3.org
** SUMMARY
1. Job of the UAAG.
The mission of the UAAG is to articulate a profile of guidelines for User
Agents which accomplish reasonable accommodation for people with disabilities.
The selection criteria for UAAG provisions (guidelines and checkpoints) is to
pick the _most reasonable_ provisions which deliver _sufficient accommodation_
for people with disabilities. Note that "most reasonable" does not
necessarily
equate to "least capable."
In examining whether the accommodation is sufficient, all that is relevant is
how the provisions affect users with disabilities.
In examining what is the most reasonable way to achieve this benefit, however,
the scope of pertinent factors widens. Here the relevant criteria are cost
and
benefit as viewed by the User Agent implementer considering all costs and all
benefits (to all users).
This is why the most reasonable accommodation is not always the design feature
which delivers the least functionality sufficient to meet the needs of people
with disabilities. If there is an alternative design feature which delivers
comparable access and attractive cost and benefit differentials vs. the
minimalist approach, then it is a more reasonable accommodation and it should
be preferred. This can be the result of less cost, more general benfit, or
great enough improvement in general benefit so that the pain after considering
the gain is more desirable.
2. Connection to disability concerns:
Yes, there should be a clear and documented connection, a rationale, for each
guideline and checkpoint in terms of how it affects users with disabilities.
3. Documentation of the connection
In two parts:
a) in the "the guidelines" section of the Recommendation document:
Each _normative_ provision (guideline and checkpoint) is _accompanied_ by a
brief, _informative_ summary of the rationale for this provision. The
following example is from the WCAG:
[quote]
Guideline 2. Don't rely on color alone.
[114]Next guideline: 3 [115]Previous guideline: 1 [116]Go to contents
Ensure that text and graphics are understandable when viewed without
color.
If color alone is used to convey information, people who cannot
differentiate between certain colors and users with devices that have
non-color or non-visual displays will not receive the information.
When foreground and background colors are too close to the same hue,
they may not provide sufficient contrast when viewed using monochrome
displays or by people with different types of color deficits.
[end quote]
Note how in this example the normative statement of the guideline is set
off as
an exhibit, and the heuristic explanation comes in a following, separate
paragraph.
The terms used in the normative statement of the checkpoint itself should
preferably be general usage already familiar to the reader. If it is
necessary
to use narrow technical terms to make the statement of the checkpoint
sufficiently crisp, the _concepts_ used should be those specific to the
technicalities of building User Agent software, not specific to the human
factors measurement of person-with-disability consequences. It is helpful to
explain the usage in the normative clauses in a Glossary if there are terms
(words or phrases) used in the normative language in narrow technical senses.
Note also that in this example, the rationale is only provided for the
guideline. The rationale for the checkpoints is the same, and is inherited,
not repeated or specialized.
b) elsewhere ad_lib; in informative annexes and by informative reference to
other documents:
Details of the rationale are in a variety of places. The key point is that
the
rationale is informative, not normative.
Dependency of the informative rationale summary on the WAI notes discussing
the
accessibility features of various W3C formats is appropriate, and
references to
these notes should be used to reduce the burden of writing the guidelines
document where they will help do that. In addition, some details may only
appear in the summary of the review process which goes up to the Director's
desk with the finished process and the request for change of status. In
particular there are higher standards for defending the rationale where
comments have been overruled than in other cases.
** DETAILS
At 12:27 PM 2000-11-14 -0500, Ian Jacobs wrote:
>Al Gilman wrote:
>>
>> The glossary entry "equivalent (for content)" employs a concept of an
>> "equivalency target" which is set apart from "the equivalents" for said
>> "equivalency target."
>
>[snip]
>
>> In no way did the WCAG mean to indicate that equivalence, as it relates to
>> accessibility in content, only applies when one user is a person with a
>> disability, or one of the alternative equivalents is incorporated for the
>> express purpose of making the ensemble accessible. These are included in
the
>> range of "equivalent alternatives" [or equivalently, "alternative
equivalents]
>> but do not restrict these terms to those cases.
>
>Al,
>
>Our mandate is to create for user agent developers
>a set of requirements known to improve accessibility.
>Each requirement must have a known impact on accessibility,
>otherwise we have exceeded our charter.
>
AG::
Point one: standard of proof.
For 'known' substitute 'believed' or 'trusted.' You don't need scientific
proof. What you need here is rough consensus. This is potentially weaker
than
the U.S. Civil Law requirement of the unanimous agreement of the jury that the
preponderance of evidence supports the verdict. But the "preponderance of
evidence" test is very close to what we should be trying to follow. If the
preponderance of evidence supports the idea that following the rule has a
significant positive impact, then the rule is justified.
Point two: universal design.
In the discussions of the UAAG, Universal Design has sometimes been
misrepresented as "designing things to meet the needs of people with
disabilities." This misses an essential aspect of Universal Design.
Universal
Design strives to meet the needs of people with disabilities not by designing
product or service features which are disability-specific, but rather by
incorporating design rules or features which are simpler and "just better" for
a broader segment of the user population.
The Center for Universal Design Home page
<http://www.design.ncsu.edu/cud>http://www.design.ncsu.edu/cud/
UD/DA considerations for The Grid
<http://trace.wisc.edu/docs/ud4grid>http://trace.wisc.edu/docs/ud4grid/
The model for universally designed checkpoints is that a) they are sufficient
conditions for success in the disability scenarios we understand or can
articulate, and b) the difference between (1) just being successful in the
identified disability scenarios and (2) satisfying the checkpoint adopted for
the document is a win-win deal; a friendly amendment in the collective rough
consensus combining inputs of both providers and consumers.
In the Universal Design community, there is a general expectation that usually
the list of rules imposed will be shorter, the individual rules will be
simpler
and broader, and the benefits of the rules will be broader than just the
disability impact alone.
The charter does not prevent the UAAG from proposing rules (checkpoints) which
deliver more benefit than just the benefit to people with disabilities. For
reasons of economy of effort (the general topic of the UAAG is an immense
task)
the document should not impose rules that have no articulable justification in
terms of disability benefit. But the test here is:
"If there is a disability scenario where imposing the set of checkpoints with
this one deleted delivers significantly reduced usability, then there is a
disability justification for the checkpoint."
An example of the application of Universal Design would be to say that if
there
are rules A and B which match the needs of two disability scenarios exactly,
and a rule C which is sufficient to meet the needs of both scenarios, and the
implementation burden of implementing C vs. A and B is not significantly
worse,
and there is either a cost savings or a collateral benefit to non-disabled
persons, then the Working Group and document _should_ impose rule C in
preference to Rules A and B. (See also the discussion of SMIL, SWITCH,
captions and language alternatives below at "** Example.")
>One of the ways in which the last call UAAG 1.0 ensures that
>requirements are relevant to accessibility is to "bind"
>the accessibility impact within definitions. This, I believe,
>is the essence of the debate we are having on the terms
>equivalent, text element, etc. These terms have build-in
>accessibility implications, which seems to be the heart
>of your objection. So "text equivalent" means more than
>"B is made of text and equals A", it means "B is understandable
>to users with disabilities because of the following assumptions,
>and B equals A". If WCAG talks about "text equivalents" and they
>are not accessible to users with disabilities, what's the point
>of talking about them? WCAG won't have done its job if its
>requirements don't promote accessibility. UAAG is in the
>same boat.
>
>It is possible to remove the access portions from
>the definitions of equivalent, text element, text equivalent,
>etc. However, there are immediate implications to using the
>same words without the accessibility binding. If document A is
>the French translation of document B, they can be functional
>equivalents. But is it within the scope of UAWG charter
>to require user agent developers to provide easy access
>to translated materials?
Yes, if the rule imposed on the user agents which covers both translations and
data of assistive purpose without making a distinction is easier to implement
and/or of significantly greater general benefit. This is the case in SMIL
(see
example at end).
>
>Questions:
>
> - Do you think that we need to ensure the binding of each
> requirement to one or more accessibility issuse?
>
[Note: The traditional term is 'tracing,' not 'binding,' when talking about
the
association of a rule with its justification or rationale. But yes, they need
to have a connection and the documentation needs to make the connection
obvious.]
Yes, each guideline and checkpoint in the UAAG should be clearly associated
with a disability-specific benefit and motivation. But the rationale for
selecting a particular form of requirement may be based on a combination of
factors including not only the disability-specific benefit, but also costs to
the implementer and benefits to other users without disabilities. The overall
decision factors include reasonableness factors as well as accommodation
factors, so benefits to other groups may be considered under "what's most
reasonable?"
> - If we change the definitions, where do you think we could
> best "recapture" the bindings to accessibility?
>
This is a two-part story.
The primary strategy is something roughly on the order of what we did in WCAG
1.0. Here there is a rhythm (pattern) where for each guideline or checkpoint
there are separate statements of what the [in that case content constructor]
should do, followed (usually immediately) by a brief summary of why this is of
accessibility concern -- the linkage to the access-based motivation. But
it is
clear that the 'what' is normative, and focuses on the content, not the
disability, and the 'why' which follows is informative, not normative. It
motivates but does not modify the 'what' that precedes it.
Another important piece of capturing and publishing the justification or
rationale has to do with the answers to review comments. What goes in the
actual checkpoints should be definitive. It should stand on its own as a
reasonably clear and definitive statement of _what_ the content should be like
in the WCAG case or _what_ functionality the User Agent should provide in the
UAAG case. The rationale which follows in the Recommendation [UAAG] document
itself is summary and heuristic, not definitive. For the details of the
rationale, the Director [making the decision to elevate] and the implementer
[complaining to her boss about why she has to do this] may be expected to have
to do some fairly complicated tracing to find the details of the argument for
this 'what' in the record of the working group process. It is not enough to
say 'the group agreed on this' but the reasoning that the group relied on does
not all have to be in the Guidelines document by any means.
The principal place where the record of the rationale gets tested is where the
Group decides to ignore a comment in a review. Negative-ballot-response is
the
IEEE jargon for this. The Director will expect the Working Group to
articulate
their reasoning in a clear and compelling way if they wish to proceed with
some
decision over the objection of a commentor. This is true whether the comment
from within or without the working group, the WAI, and the W3C membership.
The standard for documenting rules that are not contested in review is not so
stringent in practice. That is why there is so much emphasis on tracking
negative comments; they raise the bar for documenting your rationale. The
group can always propose to the W3C language in a Recommendation which goes
against some comment or another. But in this case the Director and the
process
demand a clear documented articulation of the reasoning behind the decision.
** Example:
I want to illustrate this with an example, because the discussion above is all
in generalities.
The example I would like to talk about is captions vs. translations and the
constructs of the SMIL format.
In SMIL we persuaded the SYMM working group to practice a little universal
design along the lines described above. The SWITCH construct in SMIL is used
to introduce alternatives, or elective content. The purpose of SWITCH is to
support client-side content control or decisions as to which of several
alternatives will actually be incorporated in what is displayed during the
course of playing the integrated presentation.
The SWITCH construct is used both for assitive tracks, captions and auditory
descriptions, and for language alternatives for use with a multilingual
audience.
There are test variables such as "system-captions" that are pretty closely
linked with disability scenarios, but they are not restricted or specific to
the disability scenarios. You turn captions on to have a quiet TV in a noisy
bar, too. So these test variables are not limited to disability application.
Furthermore, there is an extension capability for user-defined test variables,
so we cannot guarantee to enumerate all test variables that are important for
disability access from just the ones pre-defined in the format specification.
Considering all these factors, the appropriate level of generality at which to
interpret the spirit of UAAG checkpoint 2.3 for SMIL is at the level of the
SWITCH construct and the alternatives contained within a SWITCH; not in terms
of specific test variables. The more general rule here is simpler to
understand and implement, and it is the least rule which is guaranteed to give
you coverage of all access-related cases because of the possibility of user
test variables.
One of the macro-principles of the UAAG is that "Implementing what is in the
format definition is the first line of defence." In this case, what is in the
format is a method of defining alternatives. This method gets applied both
for
access purposes and for language purposes. But there is no gain to give the
user agent a rule that says "when SWITCH is used for access data, then the
rules of UAAG checkpoint 2.3 apply, but not when it is used for language
diversity." No, the rule should be "When SWITCH is used in SMIL to create
alternatives, the user must have the ultimate control over show/hide decisions
so they have access to all the alternatives (as implied by the SWITCH markup)
among the various presentation resources." This is sufficient to give the
user
access to captions and auditory descriptions. It also ensures access to
language variants. There are reasons why access to the language variants
is an
accessibility issue, but I don't want to rely on that argument for the
moment.
The point here is that the broader rule that relates directly and simply to
the
features that are in the language is much less of a burden on the User Agent
developers than it would be to try to separate the assitive applications of
the
SWITCH construct in SMIL and require only the necessary behavior in the
disability-specific cases.
Note that this directly affects the current work of the WAI-PF group as we
advise the HTML working group on the functional reform of XHTML to design
XHTML
2.0. It has been our general intent to encourage them to prefer features like
SWITCH that deliver a broadly useful capability which meets or exceeds the
requirements of people with disabilities. In the process we are angling to
make disability access to web information less dependent on features like the
ALT and LONGDESC in HTML 4.01 which are of limited utility outside their
assistive use. This is based on trying to meet the most needs with the fewest
rules. We hope that the UAAG will be a force contributing to this process of
simplification, because gaining widespread adoption of the numerous, rather
narrow features and rules in HTML 4.01 and WCAG 1.0 has not been a total and
instant success.
Al
>Thanks Al,
>
> _ Ian
>
>--
>Ian Jacobs (jacobs@w3.org)
<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
>Tel: +1 831 457-2842
>Cell: +1 917 450-8783
>
Received on Tuesday, 14 November 2000 19:05:09 UTC