- From: Al Gilman <asgilman@iamdigex.net>
- Date: Tue, 10 Jul 2001 23:35:50 -0400
- To: w3c-wai-ua@w3.org
At 01:53 PM 2001-07-09 , Jon Gunderson wrote: >I believe we have already talked about this issue. If the timing for the >input is not recognizable as a part of markup, then the user agent does not >have to provide the service. It may indicate a potential accessibility >problem in the SMIL 2.0 specification, if this type of user input >interaction cannot be identified by the user agent through the author >supplied markup. > [...] I think that there may be some other things to consider, here. It looks as though Issue 516 is subject to the same confusion about the scope of stopping and pausing as is Issue 517. In the SVG comments, it is suggested that some scopes _could be paused_ to allow arbitrary time for input, and I am not sure we ever meant more than what they say could be done. Also, there was discussion that SVG "can't tell if the keypress is for a simulated game console or for a form." That's fine. We don't care, either. If a keypress targeted to the game console is going to change the course of the play of the game, it is user input in the sense of 2.4. It is possible that the current language is overly specific, however. [quote] 2.4 Allow time-independent interaction. (P1) 1. For [92]content where user input is only possible within a finite time interval controlled by the user agent, allow [93]configuration to make the time interval "infinite". Do this by pausing automatically at the end of each time interval where user input is possible, and resuming automatically after the user has explicitly completed input. 2. In this configuration, alert the user when the session has been paused and which [94]enabled elements are time-sensitive. 3. When the user pauses a real-time presentation, the user agent may discard packets that continue to arrive during the pause. [end quote] If we were to abbreviate the checkpoint to the first sentence of sub-point 1. as follows: [hypothetical] 2.4 Allow time-independent interaction. (P1) 1. For [92]content where user input is only possible within a finite time interval controlled by the user agent, allow [93]configuration to make the time interval "infinite". [end hypothetical] The operational outcome of success is the same. And it allows for an asynchronous tree walk of the contents to visit the enabled elements as with event handlers in HTML. The "asynchronously walk the structure to visit the verbs" method is not allowed under the present text, where it explicitly requires detecting and autopausing on all events of the class "something enabled is going un-enabled right now." But it is hard to say that that method would not constitute "equivalent facilitation" and it meets the letter of the shortened checkpoint. We could try to check with someone who understands what's behind the SVG comments to see if we can first clear up the possible misunderstanding about stop/pause scoping, are we closer on 2.4? Would a "list of input opportunities" view be easy to generate, as opposed to the "pause on desensitization" as currently described? Al > > >Jon >Jon Gunderson, Ph.D., ATP >Coordinator of Assistive Communication and Information Technology >Division of Rehabilitation - Education Services >MC-574 >College of Applied Life Studies >University of Illinois at Urbana/Champaign >1207 S. Oak Street, Champaign, IL 61820 > >Voice: (217) 244-5870 >Fax: (217) 333-0248 > >E-mail: jongund@uiuc.edu > >WWW: <http://www.staff.uiuc.edu/~jongund>http://www.staff.uiuc.edu/~jongund >WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua >
Received on Tuesday, 10 July 2001 23:25:51 UTC