W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Re: Analysis of Applicability in UAAG 1.0

From: Hansen, Eric <ehansen@ets.org>
Date: Wed, 23 Aug 2000 17:44:59 -0400
To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
Message-id: <B49B36B1086DD41187DC000077893CFB8B42A7@rosnt46.ets.org>
I think that Ian's analysis [5] will be very helpful in resolving this issue
of applicability.

A Misunderstanding 

At the outset I believe that I need to point out that Ian's memo [5]
reflects a fundamental misunderstanding about my earlier suggestion [3].
Hence, I will try to state more clearly what I meant.

In that memo, Ian says:

> My hope in doing this analysis was that I would
> conclude that applicability was not necessary and
> could be removed from the document. This was Eric's
> conclusion [3], though his conclusion is based on
> the premise that "a checkpoint is applicable to a 
> user agent if the checkpoint requires capabilities that
> the developer of the user agent intends for users 
> without any disability." I haven't been able to
> agree with that starting point since there are some
> requirements that are principally about features for
> users with disabilities (e.g., captions) and others
> that are required whether or not the developer intended
> them for users without disabilities (e.g., DOM support).

Ian's characterization of my proposed applicability rule is based on an
informal (and hence incomplete) statement of my proposed applicability rule.
Furthermore, I don't think that his memo reflects an understanding of my
usage of the term "capability."

Specifically, Ian quotes a sentence from [3] that said:

"The main applicability rule, informally stated, is that a checkpoint is
_applicable_ to a user agent if the checkpoint requires capabilities that
the developer of the user agent _intends_ for users _without_ any

But a more formal statement of the rule is needed. In my memo [3], it says:

"A more formal statement of the main applicability rule is that a checkpoint
is applicable if it requires capabilities that are intended for users
without any disability who using the user agent under near-ideal conditions.
Some of the near-ideal conditions for general-purpose graphical user agents
would include conditions such as the presence of a desktop computer with
color monitor, stereo speakers, keyboard, mouse, moderately quiet room."

Ian's memo does not reflect (a) the idea that a "capability" may include
both functionality and content nor (b) the idea that a capability can be met
in more than one way.

In essence, the intention behind my applicability rule is that a checkpoint
is applicable unless it fails to contribute to the goal of equal access.
Equal access (and this is my own characterization) means that the same
capabilities provided to people without disabilities are also provided to
people with disabilities. (The word "benefit" may be a good synonym for
"capability".) Those capabilities for people with disabilities can be
provided directly, via primary content and primary functionality, or
indirectly, via secondary content and secondary functionality. Where the
design goal of 'universal design' has for the most part been successfully
met, the primary content and primary functionality will be directly
accessible to people with disabilities (as well as to people without any
disability) and the need for secondary content and secondary functionality
will be relatively limited. 

The rule is intended to be considerate to developers of Web content and
developers of user agents by not requiring, at least at the Priority 1
level, capabilities that are not provided to people without disabilities.
One by-product of this rule that it prevents iterative development loops by
preventing requirements for "alternatives for alternatives". This rule, for
example, if applied in the context of Web content development means that one
is not required to provide equivalents for secondary content, (e.g.,
captions, auditory descriptions, collated text transcripts for sign language
videos where the videos themselves are secondary content). In other words,
if the author of the sign language videos intends that the videos are only
for people who are deaf, then the rule would mean that they are not required
to develop equivalents for it.  In the context of the UAAG, this rule might
mean that if for some user agent, the DOM (or any other capability required
by a checkpoint) were used only to present such unnecessary content (e.g.,
unnecessary equivalents) or unnecessary functionality, then that checkpoint
could be inapplicable. 

I think that it is worth emphasizing that the applicability section is not
the only place to apply these notions of equal access. Indeed, if they were
built into the checkpoints themselves, for example, then there would be
little if any need for them in the applicability section. 

An examination of the memo [3] show that my suggestion for radical
simplification of the applicability section was based on an assumption that
(a) the document is targeted at general-graphical purpose graphical Web
browsers, and (b) that the notions of primary content and primary
functionality are tied to "standard conditions" that happen to be
appropriate for general purpose graphical Web browsers. 

Comparison of My Proposal and Ian's Current Proposal

Both my proposal and Ian's approach are dealing with some of the same
variations in user agent situation but are dealing with them through
different mechanisms.

I have addressed that variation by dealing with most if not all them by (a)
focusing on a much narrower set of user agents (e.g., general-purpose
graphical user agent), (b) standard conditions, and (c) by adding one or
more checkpoints that require capabilities for presenting certain media
types (text, graphics, animation, video, audio). This approach virtually
eliminated the need for an applicability rule. Indeed, virtually the only
reason for my one applicability to "kick in" would be if some key
checkpoints are suboptimally phrased (i.e., such as by ignoring distinctions
between primary/second content/functionality where they would be useful). As
I have stated elsewhere, I like the idea of allowing very few inapplicable

Ian, on the other hand, intends the document to be used for a wider range of
user agent types and therefore has a greater need for applicability rules. 

Issues that form the core of Ian's section on applicability (1. Unsupported
content type, 2. Unsupported content role, 3. Unsupported rendering type, 4.
Urecognized or uncontrollable properties) would under my proposal be handled
mostly by my focus on a single kind of user agent and by providing
assumptions (i.e., standard conditions) that specify the basic content
types, content roles, rendering types, etc., that should be handled by a
general-purpose graphical user agent with multimedia capabilities.

Ian's approach allows some kind of analysis a wider range of different kinds
of user whereas my approach focuses on one kind of user agent. 

Ian's approach is more _descriptive_ and my approach is more _prescriptive_.
For example, Ian's approach doesn't try to say what media types a user agent
should or must provide and whereas mine does.

Ian's approach allows the meanings of "conformance" and "accessibility" to
diverge more than does my approach. Under my approach, differences in
conformance rating translate more readily to real differences in
accessibility and in Ian's approach, differences in conformance rating only
translate into real differences in accessibility if additional conditions
are met (e.g., not too many inapplicable checkpoints, comparison is between
user agents of the same type, etc.).

I think that one of the chief advantages of my approach is that it aligns
the concepts of "conformance" and "accessibility". It also has the advantage
of eliminating more of the applicability section.

I think that the chief advantage of Ian's approach has the advantage of
being more in keeping with the historical vision for the UAAG document as
something intended for a wide variety of user agents. 

A Peek at My Revised Standard Conditions

I think that it would be useful to say briefly again what might be
appropriate "standard conditions" that would allow the applicability section
to be virtually eliminated. This assumes that the focus of the document is
on "general-purpose graphical user agents with basic multimedia

1. A color visual display monitor about 14 to 17 inches diagonal
2. Visual display capabilities capable of presenting text, graphics,
animation, and motion video.
3. Stereo two speakers for output capable of outputting prerecorded audio,
synthesized speech, and system sounds.
4. A pointing device (e.g., mouse) and keyboard for input.
5. Quick response time for accessing information both from local storage
devices and via the Internet.
6. System operation by one person at a time seated in front of the display
7. Moderately quiet room.
8. Moderately good room illumination.
9. Unlimited time per session, though usually measured in minutes or hours.
10. Computer properly handles WIMP [spell out] interface

Note 1. By the way, as I have indicated before, a checkpoint requiring text,
graphics, animation, and motion video capabilities would be a valuable
complement to Condition 2.)

Note 2. See
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html for my
older version of standard conditions. (I have eliminated reference to
compatibility to assistive technologies since I have been assured that
existing checkpoints handle that as well as it can be done at this time.)

Note 3. An assumption underlying this approach is that primary content
(content for people without any disability) can be adequately presented via
visual and auditory means and does not require other means. The importance
of this assumption under my approach is actually lower than it is for the
current approach of the UAAG document.

Note 4. The more detailed one makes these standard conditions, the more one
is potentially able to reduce the number of checkpoints that could be


I think that Ian's approach and mine are essentially different strategies
meeting a similar goal. However, his strategy is more in keeping with the
approach that the working group has been pursuing for some time, that of
allowing analysis of many different kinds of user agents. (Nevertheless, I
notice that in [1], Ian characterizes the UAAG document as having a "scope"
that "has been narrowed to address general purpose user agents meant to
interact with assistive technologies". I think that this narrowing is
healthy and it reflects something of a merging of the approaches.)

Perhaps further discussion will reveal a need for a solution more along the
lines that I suggested, but at this point I am content to have a solution
that does not entirely eliminate the applicability section.

Furthermore, barring other issues that push me in a different direction, I
don't know that it is essential to make this distinction about
primary/secondary content/functionality in the applicability section. I
think that these distinctions would be more important if:
(a) WCAG recognized the distinction, which I don't think they do in any
formal way 
(b) if user agent developers were unhappy about the current lack of the
distinction, or 
(c) if there were a better consensus about the importance and meaning of the

Regarding point (c) I am concerned about inadvertently and prematurely
codifying one representation of that scheme before a general consensus can
be reached on it. I think that probably WCAG is the proper forum for working
out a consensus. So I suppose that we should only try to the make the
distinctions in UAAG where absolutely necessary.

I suppose that if some checkpoints must "always" apply, then they would be
clearly flagged as such in the document. I suppose that one could designate
such checkpoints as having a Priority 0 (zero) but off-hand I don't think I
favor that approach. 

[1] http://www.w3.org/WAI/UA/2000/08/uaag10-applic
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0031.html
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0225.html
[4] http://www.w3.org/WAI/UA/WD-UAAG10-20000818
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0291.html

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Wednesday, August 23, 2000 11:31 AM
> To: w3c-wai-ua@w3.org
> Subject: Analysis of Applicability in UAAG 1.0
> Hello,
> In light of recent discussion about applicability, a request
> from Charles [2] to review the use of the term in the document,
> and a proposal from Eric [3] to simplify the model, I have
> attempted to analyze how we use the concept of 
> applicability in the document. The analysis [1] has three 
> parts:
>   1) Links to background discussions and issues.
>   2) Summary of the six applicability provisions in
>      the 18 August draft [4].
>   3) Breakdown of how the checkpoints seem to be
>      covered by those provisions. 
>      a) Some of the checkpoints seem unaffected and
>         thus would always apply.
>      b) Two of the provisions seem unnecessary and
>         can be removed: unsupported technologies,
>         unsupported communication.
>      c) The other four provisions can be stated
>         more succinctly and, according to this
>         analysis, should be left in the document.:
>         content type, content role, content properties,
>         and rendering support.
> My hope in doing this analysis was that I would
> conclude that applicability was not necessary and
> could be removed from the document. This was Eric's
> conclusion [3], though his conclusion is based on
> the premise that "a checkpoint is applicable to a 
> user agent if the checkpoint requires capabilities that
> the developer of the user agent intends for users 
> without any disability." I haven't been able to
> agree with that starting point since there are some
> requirements that are principally about features for
> users with disabilities (e.g., captions) and others
> that are required whether or not the developer intended
> them for users without disabilities (e.g., DOM support).
> Thus, while I believe that we can get rid of two
> of the applicability provisions, so far I have not
> been convinced that we can get rid of the remaining 
> four. I'm still hoping we can!
>  - Ian
> [1] http://www.w3.org/WAI/UA/2000/08/uaag10-applic
> [2] 
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0031.html
> [3] 
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0225.html
> [4] http://www.w3.org/WAI/UA/WD-UAAG10-20000818
> -- 
> Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> Tel:                         +1 831 457-2842
> Cell:                        +1 917 450-8783

Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090
Received on Wednesday, 23 August 2000 17:45:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:27 UTC