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

"Checkpoint applicability", "Native support", etc.

From: Hansen, Eric <ehansen@ets.org>
Date: Thu, 10 Aug 2000 04:51:20 -0400
To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
Cc: "Hansen, Eric" <ehansen@ets.org>
Message-id: <B49B36B1086DD41187DC000077893CFB8B424A@rosnt46.ets.org>
Date: 9 August 2000
To: UAAG List
From: Eric Hansen
Re: "Checkpoint applicability", "Native support", etc.

I would like to propose some clarifications, particularly in the areas of
"Checkpoint applicability" and "Native support". 

PR#294: Native support and downloadable modules
  http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#294

PR#309: Applicability needs review: how to tell when checkpoint 
        MUST be followed.
  http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#309


I believe that the problems can be corrected as shown below with very little
change to checkpoints.
====

Suggestion 1: Simplify the section on Applicability.

I think that the section on "Checkpoint applicability" in UAAG 28 July 2000
confuses rather enlightens. I think that it will tend to scare people into
thinking that the checkpoints themselves are not complete because the
section implies that in order to properly "apply" the correct checkpoints
they need deep understanding of these complex cases. I think that the cases
are not only overly complex but are irrelevant and perhaps misleading. In a
sense, I think that people may be put off by lack of clarity of the
Applicability section. For example, they may wonder if the lack of clarity
was a way of inhibiting people from availing themselves of legitimate
waivers from checkpoint requirements. 

I believe that the entire Applicability section can be considerably reduced
and simplified. (The old Applicability section is included in the Appendix
for this memo.)  The following is my revision.

New:

"Checkpoint applicability"

"The goal of the checkpoint applicability rules is to ensure that developers
of user agents are required to adhere to only those checkpoints that are
_necessary_ to ensure that individuals with disabilities have, to the extent
possible, equivalent access to user agent capabilities that are enjoyed by
people without any disability. Those capabilities (functionality and
information) for people without any disability must be made available to
people _with_ disabilities either directly or indirectly, through
alternative means.

"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
disability. (This does not mean that the developer of the user agent intends
the capability _exclusively_ for people without any disability, but rather
that these are a set of capabilities that are sufficient to allow a user
without any disability to obtain the full benefit of the user agent.) It is
expected that for most, if not all, general-purpose graphical Web browsers,
virtually all checkpoints will be applicable since most of their
capabilities are intended for general audiences, a substantial portion of
which have no disability. The rationale for this rule, as noted above, is
that the checkpoints require functionality and information that will help
ensure that individuals with disabilities have access to the essentially the
same capabilities (directly or indirectly) as are provided to individuals
_without_ any disability.

"An applicability rule that supports the main rule is that any capability
"provided" or "offered" by the user agent is assumed to be "intended" for
the user _without_ any disability unless documentation justifies the claim
that it not merely as an accessibility feature but that it is a capability
intended _specifically_ [Note: I think that the word "exclusively" is too
stringent in this context.] for users _with_ disabilities." [Note: This rule
is designed to prevent cases in which one might improperly claim that
virtually all capabilities are intended for people with disabilities and
that therefore no checkpoints are applicable.]

"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.
Furthermore, other conditions would include quick and compatible
communications with any necessary assistive technologies. This document does
not attempt to anticipate the full range of conditions that would be
near-ideal for the diversity of user agents. However, it is likely that
these same conditions of "quick and compatible communications with any
necessary assistive technologies" would likely be relevant for a wide
variety of user agents.

"One implication of the main rule is that a checkpoint is not applicable if
it refers solely to capabilities that, in a given user agent, are
exclusively for people _with_ disabilities. 

"An obvious but extremely important implication of this applicability rule
is that a checkpoint is "not applicable" if is refers exclusively to
capabilities that are _not offered by the user agent at all_.

"See the Techniques document for further examples. [Optional]"

Comment 1:

You will notice that in a relatively short amount of prose I attempt to not
only tell what the rules are but also to explain the rationale and
implications. Perhaps what I have written is longer than it need be, partly
because I am trying to _justify_ the change (to you-all!) and well as _make_
the change. 

Comment 2:

I use the term "capabilities" as encompassing both "content" and
"functionality". I think that we mean both content (i.e., information) and
functionality so I think that we need this overarching term.

Comment 3: 

If we have concerns about letting developers of assistive technologies "off
the hook" remember that: (a) our document is optimized for and intended
primarily for "general-graphical graphical Web browsers" so it natural and
appropriate that some checkpoints not apply to special-purpose user agents
specifically for people with disabilities  (b) there is plenty of work that
needs to be done to make special-purpose user agents, e.g., mathematics on
the Web for people who are blind, etc., that we don't need to burden
developers of such user agents with additional accessibility requirements.

Comment 4:

More detail on the concept of standard conditions is found at:

http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html

====

Suggestion 2: Remove or delete the summary examples from "Checkpoint
applicability".

I think that the summary examples as well as the sentence following the
examples should be deleted or removed. Possibly some version might be
warranted for the Techniques. Following  are justifications for this
suggestion. Each point is followed by my comments.

"To summarize, a checkpoint (or portion of a checkpoint) applies to a user
agent unless at least one of the following is true:"

#1. "It refers solely to an unsupported input or output device interface.
Note that if the device interface is supported at all, it must be supported
accessibly for all functionalities of the user agent (and not just a subset
of functionalities)." 

My comment: Not necessary. The capability is not offered to anyone.
Furthermore, the second sentence ("Note that..."), if relevant, would belong
in the checkpoints, not in this section. 
 
#2. "It includes requirements about the purpose of content (e.g.,
transcript, caption, text equivalent, etc.) that the user agent cannot
recognize through markup. For instance, HTML user agents can recognize
"alt", OBJECT content, or NOFRAMES content as providing equivalents for
other content since these are specified by the markup language. HTML user
agents are not expected to recognize that an image description embedded in a
paragraph is a text equivalent for the image."

My comment: Not necessary. The capability is not offered to anyone. The
statement about not needing to recognize a text equivalent that is embedded
in a paragraph, if relevant, belongs in a checkpoint. I am not sure that we
need to say that anywhere since the only equivalents that the user agent can
recognize are those that are marked by the author as such. I have argue in
another context that even if the actual text equivalent is embedded in
primary content, it should still be addressable. If necessary, some of the
material might belong in Techniques. 

#3. "It includes requirements about a content type (script, image, video,
sound, applet, etc.) that the user agent either does not recognize or
recognizes but does not support natively."

My comment: Not necessary. The capability for such recognition is not
offered to anyone. See later suggestion about the term "natively".

#4. "It requires control of properties of an embedded object (e.g., video or
animation rate) that may not be controlled or accessed by the user agent."

My comment: Not necessary. The capability is not offered to anyone.

#5. "It refers to unsupported technologies that are not required by this
document. For instance, all conforming user agents are required to support
the W3C Document Object Model [DOM2]. However, user agents are not required
to support a synchronized multimedia markup language such as SMIL 1.0
[SMIL]. If they do, the checkpoints that refer to synchronized multimedia
apply."

My comment: Not necessary. This point seems to have several problems. (1)
Regarding the first sentence, the _checkpoints themselves_ should make
crystal clear which technologies are "required" and which ones are not so
there is no need to finesse the issue here. (2) I think that the last two
sentences about SMIL are already covered by checkpoint 6.1, which seems
clear enough. ("6.1 Implement the accessibility features of all supported
specifications (markup languages, style sheet languages, metadata languages,
graphics formats, etc.)"). If we want to underscore the fact that when we
say "supported" we do not necessarily mean "required" then that can be
stated in a notes attached to the relevant checkpoints. (3) I do not
understand why the word "unsupported" appears in the first sentence; isn't
it reason enough for an exclusion that the technology is "not required"
(later in that sentence). In summary, I think that this point is very
confusing.

#6. "It refers to communication with other software but no communication is
possible on the system housing the user agent (e.g., a kiosk with no
infrared port for communication with assistive technologies)."

My comment: Not necessary. Having this point here seems to be very
misleading. The UAAG guidelines document is about software -- not hardware!
All the general-purpose graphical Web browsers that I know about are
software. I think that it really confuses things to even mention hardware
like kiosks.

#7. (This is the closing sentence).  "Each checkpoint requirement must be
satisfied by making information or functionalities available through the
user agent's user interface unless the checkpoint explicitly states that the
requirement must be met by making information available through an
Application Programming Interface (API)."

My comment: Not necessary. I think that relevant checkpoints are quite
explicit about how they must make information available (API versus user
interface). This point will scare people into thinking that the checkpoints
themselves are not explicit about what they intend.

====

Suggestion 3: Mention applicability, at least "softly", in the Abstract.

I think that a good first step to clarifying the role of "applicability" in
the guidelines is by invoking the concept of "applicability" in the Abstract
(and any other relevant locations).

Old (UAAG 28 July 2000):

"Abstract
"The guidelines in this document explain to developers how to design user
agents that are accessible to people with disabilities. User agents include
graphical desktop browsers, multimedia players, text browsers, voice
browsers, plug-ins, and other assistive technologies that provide access to
Web content. While these guidelines primarily address the accessibility of
general-purpose graphical user agents, the principles presented apply to
other types of user agents as well. Following these principles will help
make the Web accessible to users with disabilities and will benefit all
users."

New:

"Abstract
"The guidelines in this document explain to developers how to design 'user
agents' (technologies that provide access to Web content) that are
accessible to people with disabilities. Virtually all requirements of this
document apply [or "are applicable"] to general-purpose graphical desktop
browsers. Many of the requirements also apply to other user agents, such as
text browsers, voice browsers, multimedia players, and other technologies
that provide access to Web content. Following the principles presented in
this document will help make the Web accessible to users with disabilities
and will benefit all users."

Comment 1: 

The revised material defines the term "user agent" in first sentence. The
term is so general and largely unknown that I think it needs to be defined
right at the start.

Comment 2:

Hopefully it is true that all or "virtually all" requirements _do_ apply to
general-purpose graphical desktop Web browsers. If they don't, then there
may be a problem with the document.

Comment 3:

The revised version does not say "assistive technologies"; it just says
"technologies". The term "assistive technologies" may cause readers to
incorrectly infer that the UAAG is about hardware, which it is not.
Furthermore, "assistive technologies" may be seen as partially overlapping
with "voice browsers" and "text browsers", which could add confusion.

====

Suggestion 4: Seriously consider removing all references to the term
"natively".

I think that there is no reason to refer to the concept of "natively" in the
document. The term rightly does not appear in any checkpoint. I think that
the word natively is a "leftover" from a time when it was not clear whether
we were considering each user agent _in isolation_ or with other user
agents. We determined (rightly, I think) that we needed to consider each
user agent in isolation. To focus people's attention on the term is
confusing and unnecessary.

====

Suggestion 5: Seriously consider giving explicit permission to create a
single user agent out of more than one user agent.

Actually, I see no reason why developer, if she or he desires, should not
treat two or more cooperating user agents (i.e., a general-purpose graphical
user agent plus a multimedia player plus some special-purpose
disability-access user agent, etc.) as a single user agent. First of all,
this is the way it happens in real life; for example, MS Internet Explorers
uses lots of special purpose plug-ins. Second, this would encourage
cooperation between developers on disability access issues. It might be
possible, for example, for two user agents, one or more of which is
non-compliant when analyzed singly, but together constitute a "super" user
agent that is compliant. Such a possibility would encourage cooperation
between developers of user agents. Third, this would encourage involvement
by lots of developers of special-purpose user agents (assistive
technologies). Without this change, they may feel left out because they do
not address all disabilities or because few checkpoints are applicable to
them. But if they can cooperate with other user agents to form a combined
"super" user agent, then they can join the party. It would be a win-win
situation. I suppose that one could not say anything about this issue in
this document and leave it up to others to decide if they want to allow it.
Nevertheless, my feeling is that it makes a lot of sense and if others
agree, then we should explicitly allow it in the document.

====

Suggestion 6: Add a checkpoint or so about easy installation for people with
disabilities.

We should consider adding a checkpoint or so that requires easy installation
of user agent software for people with disabilities. It occurred to me that
this is missing, but it becomes especially important when we consider
allowing people to analyze multiple user agents as a single one. I have
further thoughts but will not write them now. I would be happy to discuss.

====

Suggestion 7: Remove the reference to "assistive technologies" in checkpoint
1.5.

I think that "assistive technologies" (and its variations) need not and must
not appear in checkpoint 1.5 (i.e., the normative part) or any other
checkpoint. One reason is that people may incorrectly assume that because
the checkpoint refers to requirements that are exclusively for people with
disabilities, such as those relating to "assistive technologies", that the
checkpoint is somehow not applicable.

Fortunately, it appears checkpoint 1.5 is the only checkpoint that uses that
term and it is in no way essential. In my opinion, this checkpoint also has
other problems, such as misuse of the term of the term "text equivalent".
Let us consider basic fix. 

Old (UAAG 28 July 2000):

"1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
that is part of the user agent's user interface also has a text equivalent
in the user interface. This text equivalent must be available to assistive
technologies through an API. [Priority 1]"  

Partial Fix 1:

"1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
that is part of the user agent's user interface also has a text equivalent
available in the user interface. [Priority 1]"  

Comment 1: 

There are already checkpoints that ensure that the text equivalents will be
available through the interface (e.g., checkpoints 2.1, 2.2, and 2.4) and
checkpoint 1.1 ensures that what is available through the user interface is
also available through API. So that second sentence -- the one that refers
to assistive technology -- is completely unnecessary. 

Comment 2:

As noted above, other fixes are also needed. One problem is that it misuses
the term "text equivalent". We can correct part of the problem as follows:

Partial Fix 2:

"1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
that is part of the user agent's user interface also has a text equivalent.
[Priority 1]"  

I removed the last part of the sentence because a text equivalent is
"pre-rendering content" so it usually doesn't make sense to talk about "text
equivalent available in the user interface".

I wonder if what was really meant was to emphasize that visual messages
should have an auditory equivalent and auditory messages should have a
visual equivalent.  I suppose that there may have been a desire to emphasize
this in the UAAG document since some of these messages seem to be generated
by the user agent itself or the operating system than by the Web content
itself. Unless someone can explain the intention of the checkpoint, I think
that this checkpoint is not necessary at all since it is adequately covered
by other checkpoints.

Therefore I suggest deleting it. Even if it is not deleted, I strongly urge
removal of reference to assistive technologies.

====

Suggestion 7: Keep mention of  "compatibility and quick communication with
assistive technology" out of any checkpoint.

This is not actually a problem at this time since, I don't think that they
are mentioned in checkpoints. This is more for future reference.
"[C]ompatibility and quick communication with assistive technology" are part
of the "near-ideal conditions" (that I think are more properly called
"standard conditions") and therefore should not be found in any checkpoint.
These are things that are and should remain outside the scope of the
checkpoints themselves.

====

Appendix: Old (UAAG 28 July 2000) Section on Applicability:

Checkpoint applicability

Not every checkpoint or guideline is applicable to every user agent.
Generally, a user agent must adhere to checkpoints that ensure accessibility
of functionalities that it offers to users and it must implement required
functionalities natively. If the user agent supports keyboard input, it must
support accessible keyboard input. If the user agent supports images, it
must ensure access to each image or an equivalent alternative specified by
the author. If a user agent supports style sheets, it must implement the
accessibility features of the style sheet language. If the user agent
supports frames, it must ensure access to frame alternatives specified by
the author. In short, if a user agent offers a functionality, it must ensure
that people with disabilities have access to that functionality or an
equivalent alternative.

Not all user agents support every content type, markup language feature,
input or output device interface, etc. When a content type, feature, or
device interface is not supported, checkpoints with requirements related to
it do not apply to the user agent. Thus, if a user agent supports style
sheets at all, all checkpoints related to style sheet accessibility apply.
If a user agent does not support style sheets at all, the checkpoints do not
apply.

The applicability of checkpoints related to markup language features is
determined similarly. If a user agent supports tables, it must support the
accessibility features of the language related to tables (and so on, for
images, frames, video, links, etc.). The Techniques document includes
information about the accessibility features of W3C languages such as HTML,
CSS, and SMIL.

To summarize, a checkpoint (or portion of a checkpoint) applies to a user
agent unless at least one of the following is true:

	It refers solely to an unsupported input or output device interface.
Note that if the device interface is supported at all, it must be supported
accessibly for all functionalities of the user agent (and not just a subset
of functionalities). 

	It includes requirements about the purpose of content (e.g.,
transcript, caption, text equivalent, etc.) that the user agent cannot
recognize through markup. For instance, HTML user agents can recognize
"alt", OBJECT content, or NOFRAMES content as providing equivalents for
other content since these are specified by the markup language. HTML user
agents are not expected to recognize that an image description embedded in a
paragraph is a text equivalent for the image. 

	It includes requirements about a content type (script, image, video,
sound, applet, etc.) that the user agent either does not recognize or
recognizes but does not support natively. 

	It requires control of properties of an embedded object (e.g., video
or animation rate) that may not be controlled or accessed by the user agent.


	It refers to unsupported technologies that are not required by this
document. For instance, all conforming user agents are required to support
the W3C Document Object Model [DOM2]. However, user agents are not required
to support a synchronized multimedia markup language such as SMIL 1.0
[SMIL]. If they do, the checkpoints that refer to synchronized multimedia
apply. 

	It refers to communication with other software but no communication
is possible on the system housing the user agent (e.g., a kiosk with no
infrared port for communication with assistive technologies) 

Each checkpoint requirement must be satisfied by making information or
functionalities available through the user agent's user interface unless the
checkpoint explicitly states that the requirement must be met by making
information available through an Application Programming Interface (API). 
<END OF MEMO>

===========================
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 Thursday, 10 August 2000 04:51:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:14 GMT