- From: Roberto Castaldo <r.castaldo@iol.it>
- Date: Thu, 28 Oct 2004 17:51:05 +0200
- To: <w3c-wai-gl@w3.org>
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