Action Item on Checkpoint 2.2

There are currently 13 defects in Bugzilla for checkpoint 2.2. This note
summarizes the issues and provides proposals to address most of them.

=======================================

Checkpoint proposals

Current wording for Checkpoint 2.2

2.2 Users can control any time limits on their reading,
interaction, or responses unless control is not possible due to nature
of real-time events or competition.

In [626], John Slatin proposes:

2.2 Allow users to control time limits on their reading,
interaction, or responses unless specific real-time events or rules of
competition make such control impossible.

Proposal 626a
I propose deleting "or responses". Responses are interaction.
"Allow users to control time limits on their reading or interaction unless
specific real-time events or rules of competition make such control
impossible."

Proposal 626b
But what about server timeouts? Content developers have no control over
server timeouts.
"Allow users to control time limits on their interaction unless specific
real-time events or rules of competition make such control impossible."

In [683] Greg Lowney suggests that competition is really no different from
other "real
time events" already mentioned.

Proposal 683
"Allow users to control time limits on their interaction unless specific
real-time events, such as the rules of a competition, make such control
impossible."

==============================

Success Criteria issues and proposals

Level 1, success criteria 1:

Current wording for Level 1 success criteria # 1:

1. content is designed so that time limits are not an essential part of
interaction or at least one of the following is true for each time
limit:

* the user is allowed to deactivate the time limits,

* or the user is allowed to adjust the time limit over a wide range
which is at least ten times or default setting or average user's
preference,

* or the user is warned before time expires and given at least 10
seconds to extend the time limit,

* or the time limit is due to a real-time event (e.g. auction) and no
alternative to the time limit is possible,

* or the time limit is part of a competitive activity where timing is an
essential part of the activity (e.g. competitive gaming or time based
testing).


In [627], John Slatin proposes:

1. content is designed so that time limits are not an essential part of
interaction, or at least one of the following is true for each
interaction for which a time limit has been set:

*        the user is allowed to deactivate the time limit;

*        the user is allowed to adjust the time limit over a wide range
which is at least ten times the length of the default setting
[deleted "average user's preference" because there's no way for most
developers to determine this];

*        the user is warned before time expires and given at least 10
seconds to extend the time limit;
[John feels that 10 seconds isn't long
enough. MS Windows used to give you 15 seconds to accept changes to the
Display control panel, and it wasn't long enough to listen to the
entire dialog and then tab to the OK button.]
[Andi: there are a lot of variables that affect this: number of words in
the message, speed of the TTS engine which is dependent on the user's
settings, etc. Anything we choose here has the potential of either being
too little time for some users or impractical from a system performance
perspective. How about making it 20 seconds?]

*        the time limit is an important part of a real-time event such
as an auction, and no alternative to the time limit is possible;

*        the time limit is part of a competitive activity where
timing is an essential part of the activity (e.g. competitive gaming;

*        an online test must be completed within a set time which has
already been increased to accommodate people with disabilities who are
allowed by law to take additional time
[Andi: slight rewording proposal: "the time limit for an online test has
already been increased to accommodate people with disabilities who are
allowed by law to take additional time"]

In [593], Aries Arditi proposes adding an additional bullet to this success
criteria:

*        the user can control the presentation by eliciting phases
sequentially via keystrokes.
Andi: I propose covering this in Level 2 SC #2 below

========================================

Level 2 success criteria # 1

Current wording for Level 2 success criteria # 1

2. any blinking content can be turned off.

In [629], John Slatin proposes:

2.  blinking content can be turned off.

Proposal 629a
To be consistent with the wording in Level 1 SC # 1, I propose
"1.  the user is allowed to turn off blinking content"?

==============================

Level 2 success criteria # 2

Current wording for Level 2 success criteria # 2

1. any moving content can be paused

In [628], John Slatin proposes:

1.  moving content can be permanently or temporarily stopped using the
keyboard

Proposal 628a
Remove "using the keyboard." Permanently or temporarily stopping moving
content is functionality of the page which is covered under checkpoint 2.1.
1.   Moving content can be permanently or temporarily stopped

Proposal 628b
To be consistent with the wording in Level 1 success criteria # 1, I
propose
 "1.  the user is allowed to permanently or temporarily stop moving
content"

Proposal 628c
Do we need to add the following to cover [593] from Aries Arditi or is this
sufficiently covered in proposal 628b?
Proposal 593: 2. the user can control the presentation by eliciting phases
sequentially

=============================================

Level 3 success criteria # 1

Current wording for Level 3 success criteria # 1

1.  there are no time limits as a part of a competitive activity (content
has been redesigned so that time limits are not an essential part of
interaction.)
[Andi: Suggest removing this success criteria. If there are no time limits,
then guideline 2.2, which requires that users have control of time limits,
does not apply.]

In [684], Greg Lowney suggests adding another means of complying
with this criterion.

Proposal 684a
1. for time limits that are part of a competitive activity, one of the
following is true:

   * content has been redesigned so that time limits are not an essential
part of interaction.
   * an alternative method of accomplishing the same goal is provided which
meets the above exceptions.
Andi: Isn't this fundamentally implied for all requirements?

in [684], Greg Lowney suggests adding another means of complying
with this criterion: in a supervised or moderated setting (such as a
student taking a computer-based test), the person supervising or
moderating the experience is able to deactivate the time limit or adjust
the time limit over a wide range which is at least 10 times the average
user's preference.
Andi: I think this is covered in the Level 1 success criteria. Can't use
"the average user's preference" because page author has no way of knowing
this.

In [683], Greg Lowney suggests adding a note (either in the glossary
or in Guideline 2.2) to the effect that developers should take care to
give the user as much control as possible over any interaction that will
interrupt the user's task or train of thought. It is usually possible to
give the user the option of delaying or suppressing most interactions
that are triggered by external, real-time events, such as notice of
incoming email or the availability of updated content.

Proposal 683:
Andi: This reads like a new success criteria. Should we add Level 3 SC #2?
2.  the user is provided an option to delay or suppress interruptions
triggered by external, real-time events such as notice of incoming email or
the availability of updated content.

=====================================

Benefits

In [685] Greg Lowney suggests an addition to the first benefit

Proposal 685: "People with physical disabilities might not be able to move
quickly or accurately enough to interact with moving objects or may take
longer than usual to interact with the user interface elements."

=====================================

Examples

In [686], Greg Lowney suggests rewording the first example to clarify that
these types of content are not "exempt" from this checkpoint but must
conform to it.

Proposal 686:

"Examples of content that must meet the success criteria of this
checkpoint:"

Example 1

In [687}, Greg Lowney dislikes Example 1 which suggests that the user can
deactivate scripts in the browser as a way to stop blinking text that is
created with a client side script. Greg thinks that deactivating scripts an
extreme solution that should not be suggested because of function that
would be lost limiting the user's ability to carry out their work. He
recommends an example that is specific to this problem.

Question for the working group: Is disabling scripts a valid way to comply
with this checkpoint? If so, this example is fine. We could add a third
example (see proposal below) per Greg's suggestion. If disabling scripts is
not a valid way to comply with this checkpoint, then replace Example 1 with
the following:

Proposal for Example: Client-side scripting is used to create blinking
text. The site provides an
option that allows the user to disable the blinking text.

===============================

General issues

[174] Is there a way to allow individuals who are deaf-blind to perceive
and keep up with
accessible presentation of a real-time or interactive presentation?
Andi: For a real time presentation, you could have real time captioning
which includes spoken text, descriptions of significant audio, and
descriptions of significant visual presentations. But from a practical
perspecitve, it is hard to imagine how all of this real time describing
could keep up with the real time presentation. Seems like this should be
covered under checkpoint 1.2.

In [412], Kynn Bartlett writes:
By granting an exception for "competitive or realtime events" you are
making
a global value judgment which says "it's okay to be inaccessible if you
have
certain goals in mind." This is a bad idea, because the "loophole" in this
checkpoint essentially says, "...so it's accessible." Guess what: a
competition
is still inaccessible if it is time-based. The purpose of this document is
to define if a practice is accessible or inaccessible. Games don't
magically
become accessible by virtue of being games. Inaccessible coding should be
labeled inaccessible if it is, indeed, inaccessible. There should be no
loopholes.

Someone who requires six times as much time to do something doesn't
magically
speed up just because it's a competition -- the competition is still
inaccessible
to that person, and should be stated as such.
Andi: This goes to the ongoing discussion about standards vs. policy.

In [562], The U.S. Access Board writes:
We agree with this guideline and believe that the addition of the
qualifying
statement regarding realtime or competition is an excellent clarification.
Andi: Since the Access Board writes policy, they agree with this exception.

Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo

Received on Monday, 26 January 2004 11:22:26 UTC