Guideline 2.2 - Open issues summary and proposals

Guideline 2.2 (8th october WD wording)
--------------------------------------
Allow users to control time limits on their reading or interaction unless
specific real-time events or rules of competition make such control
impossible.
--------------------------------------
Level 1 Success Criteria for Guideline 2.2
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:
[I] 
- the user is allowed to deactivate the time limit or; 

- 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 or; 

- the user is warned before time expires, allowed to extend the time limit
with a simple action (for example, "hit any key") and given at least 10
seconds to respond or;

- the time limit is an important part of a real-time event (for example, an
auction), and no alternative to the time limit is possible or;

- the time limit is part of an activity where timing is essential (for
example, competitive gaming or time-based testing) and time limits can not
be extended further without invalidating the activity.

Level 2 Success Criteria for Guideline 2.2 
The user is allowed to turn off content that blinks for more than 3 seconds.
[I] 
The user is allowed to pause and/or permanently stop moving or time-based
content. [I] 

Level 3 Success Criteria for Guideline 2.2 
The content has been designed in a way that any time limits in the content
would pass level 1, success criteria 1 for this guideline without
exceptions. [V] 
Editorial Note: Real time events would not be allowed with this wording. Do
we want to accept them?

Any non-emergency interruptions, such as the availability of updated
content, can be postponed and/or suppressed by the user. [V] 
-----------------------------------


Introduction to open issues summary
-----------------------------------
This guideline intends to speak about time limits, which are very difficult
to define in an absolute and objective way; in the actual wording there are
many parameters (ten times, three seconds, ten seconds) whose value is (or
may be perceived as) arbitrary. Probably those numbers are not valid and
really useful for all kinds of applications and users, and maybe any value
instead of the actual ones will have only a partial effectiveness.

So, in my opinion, the main issue for this guideline is not linked to any
particular success criterion: should we really try and find the best
compromise values for each parameter? On the other hand, can this guideline
give only strong but not subjective indications like "no blink at all" or
"no moving content at all"?  

In other words, should WCAG 2.0 be based on variable and subjective
paramaters, or should they propose universal guidelines? I have no final
answer, but maybe we should limit the usage of subjectivity and offer to any
developer a solid and objective point of reference; too many times web
professionals  give their personal reading of WCAG 1.0, and we should do our
best to avoid it in WCAG 2.0 so that all the new guidelines can be simply
implemented and not interpreted or guessed. And we should always consider
that web (and not-Web) accessibility is becoming a great business all over
the world that needs clear and not ambiguous rules.

Fixing this essential point will downsize many of the open issues - listed
below - for this guideline; I think our discussion should focalize on this
primary issue at first.


Guideline 2.2 (Time limits) Open Issues
---------------------------------------

- 627. Proposed wording for Guideline 2.2, SC 1
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#627

After a first rewording proposal, Andi Snow-Weaver proposed to increase the
10 second threshold to 20 seconds; this issue has been discussed in the Jan.
29 2004 telecon, and many comments were made on it, but no final resolution
has been taken.

My 2 cents:
In a chat room 20 seconds can be not enough, and the same is for 30 seconds,
and so on... Different users can require different timeouts. We could simply
cut off all the numerical limits by saying:
* the user is allowed to adjust the time limit
* the user is warned before time expires and given the chance to extend the
time limit


- 789. simplify definition of content that blinks?
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#789

This issue is about the definition of blinking and its application in the
level 2 SC and Gregg seems concerned about determining the blinking time
limits. Once again, maybe no limits? 


- 800. Authors can't control server timeouts
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#800

Is "time limits on their reading" meant to include server timeouts? In
general, server administrators, not content authors, control server
timeouts. Propose rewording this guideline as "Allow users to control time
limits on reading or interaction that are part of the functionality of the
content unless specific real-time events or rules of competition make such
control impossible."


- 801. SC should not be provided if excluded by checkpoint itself
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#801

The fourth and fifth sub-bullets concern time limits that are due to
real-time events or competition. The Guideline excludes these types of time
limits with the phrase "...unless specific real-time events or rules of
competition make such control impossible."

My 2 cents: 
We could erase the phrase "...unless specific real-time events or rules of
competition make such control impossible."; so the exceptions will be
handled in the sub-bullets


- 802. Rewording of benefits
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#802

Here there's a reasonable rewording about benefits of guideline 2.2: 
1-"People with reading disabilities, cognitive disabilities, and learning
disabilities who may need more time to read and comprehend written text will
be given additional time to read the information." 
2-"People with physical disabilities can have sufficient time to process and
read information before it is refreshed."


- 803. Example not applicable
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#803

Examples of content that must meet the success criteria, last sub-bullet -
"shutdown or deactivation of a resource if activity is not received in a set
amount of time" sounds like server timeouts which are not under the control
of the content. 


- 843. Blinking content criterion should apply to all content that blinks
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#843

AbI-Project puts in evidence that saying "The user is allowed to turn off
content that blinks for more than 3 seconds" is not enough; this SC should
be applied to all blinkng content.

This is another issue that would not exist if we removed all the numerical
parameters.


- 856. what determines whether a user is allowed to turn off content?
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#856

Here the question is: What determines whether the "user is allowed to turn
off content or pause"? 


- 857. questions about time-out, etc.
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#857

Abl-Project asks: essential time-outs (e.g. automatic refreshs, automatic
redirects) are only allowed if they can be controlled by the user. Is this
correct? If yes, what determines whether they can be postponed/suppressed by
the user?


- 879. Default timeout doesn't exist
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#879

Access Board puts in evidence that the concept of "default timeout" has no
sense, so talking about its multiples has no meaning. A good solution could
be allowing the user to request more time when the time is about to expire


- 880. Should blinking and movement be covered?
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#880

Is this section is saying that a user should be able to freeze any kind of
dynamic content? If so, all live presentations could be frozen or resumed by
the viewer. And more... Considering blinking events as timed events is not
appropriate. Then, the guidelines should cover the need to avoid movement in
pages until they can be frozen.

My opinion is that we should avoid all temporary concepts in WCAG 2.0;
saying "until user agents..." only adds problems in understanding and
implementing such guidelines; we will never have the ideal situation where
all user agents will permit to froze movement in pages, so all we can do is
forbid movement in pages.


- 929. application of time limits to business process
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#929

This is about the exception "the time limit is part of an activity where
timing is essential (for example, competitive gaming or time-based testing)
and time limits can not be extended further without invalidating the
activity." 

If a business process requires a specific activity and time can not be
extended, can a company use this exception? For exmaple,a c ashier needs to
close their account every night. If they don't finish the transcation, the
system will shut it down. According to accounting you have to close the day
at  midnight. The business process has to end there. They will get a warning
but can not extend the time.

I think this is a case where the exception can be applied.


- 943. Why 10 times the default?
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#943

James Craig says: Guideline 2.2, Level 1 Success Criteria, Number 1, second
bullet... How was the "at least ten times" decided?

Same as before: if we admit that "default timeout" concept has sense (I do
not think so), "at least ten times" is just a starting point on which we
should think a lot; once again the problem is about fixing numerical
references and thresholds which - imho - have no sense at all.


- 987. Add people who use an interpreter to the benefits 
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#987

RNID writes: We would welcome some mention of the extra time that maybe
required by people who are using an interpreter to help them with some of
the content on a site, in order to raise awareness among designers that this
is one group who they should cater for. This mention would be best placed in
the "Benefits of [Guideline 2.2]" section, e.g. in the last sentence: ".by
an assistive technology, voice browser, or a sign-language interpreter
relating audio content to a user"


- 1044. Suggestions for time-limits guideline
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#1044

Here we can find a mix of suggestions from Harvey, some of them still based
on numeric "arbitrary" thresholds, others on real time events.


- 1092. Time limits in Guideline 2.2 are still too small
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#1092

The same as above... Any time we try and determine a fixed number or
multiple, some good exception can be raised about it. 

Why not simply allowing the user to request more time when it is going to
expire?


- 1093. Guideline 2.2, SC 1 & 3 are too similar.
http://trace.wisc.edu/bugzilla_wcag/issuereports/time-limits_issues.php#1093

It is not clear how SC level 1 item 1 and level 3 item 1 differ. How does
this guideline apply if there is no reading or interaction required, for
example a server-side redirect (which includes an HTML page with most
servers but users are not required to read this because the user agent
connects to the new location automatically) or a client-side redirect
depending on factors which the user cannot influence (for example the
availability of a plugin)? The time expiration warning is an extreme change
in context which another guideline does not allow. This seems to
contradicting requirements.



Best regards,

Roberto Castaldo
-----------------------------------
www.Webaccessibile.Org coordinator
IWA/HWG Member
rcastaldo@webaccessibile.org
r.castaldo@iol.it
Mobile 348 3700161
Icq 178709294
----------------------------------- 
 

Received on Thursday, 28 October 2004 15:51:37 UTC