

Re: Issue 516: [...] summary review

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 12 Jul 2001 10:57:06 -0400
Message-Id: <200107121446.KAA2275797@smtp2.mail.iamworld.net>
To: w3c-wai-ua@w3.org
For reference.


      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.


My sense of the SVG objections, here, can be summarized in two main points:

a.  Pausing the individual sensitive element in the context of a larger
animated SVG does not make sense.

b.  What determines the time window in which the actions on an element in an
animated SVG are actually available to the user, with occlusion and indirect
binding taken into account, is possible, but hard, to determine in time to
pause the presentation at the end of sensitivity.  Order of magnitude to add
this function might be twice the effort as to create the module (SVG player)
that the functionality is being added to.  [Because it is technically
it is not clear that it is excused under the 'determinability' language of

[Just my sense of what they said, to make the response clearer.]


a.  Yes.  When one stops or pauses a time-based presentation, what is stopped
or paused is the entire synchronized presentation.  One is not assumed to be
able to do a 'stop' or 'pause' of sub-objects that the user cherry-picks
out of
the onrushing ensemble of presentation.  This is a communication glitch
UA WG and SVG WG that is shared with the comments about Checkpoints 4.4 and
(see issue 417).

Where the UAAG talks about stopping or pausing 'elements' the 'elements'
intended were independenly playable media objects (including synchronized
ensembles) concurrently embedded in an asynchronous context such as an HTML

b.  The proper test of P1 in this context is access to outcomes.  As in the
first, summary statement of the checkpoint,, "Allow time-independent

It is desirable that this required outcome be performed in a way that minimzes
changes in how the access to outcomes is mediated to the user.  Change the UI
as little as possible, that makes it work for them.  The specific method, of
pausing the presentation on the fly, as described in the sub-bullets starting
with "Do this by pausing..." is offered in this spirit.

However, that is not the only way to achieve time-independent access to the
outcomes.  A static menu of controls (probably with a web page look and feel)
that grants access to the same range of outcomes should be recognized as
meeting the P1 test in this regard.

There is plausible risk that the currently stated method, applied to an
animated SVG, would not only be a bear to implement, but would result in a
presentation that is of no earthly use to anyone, because of the incessant
pausing for too many incidental events.

In a classical SMIL context where the syncronized ensemble is composed of a
relatively small number of independently playable media objects, it may make
sense to employ the on-the-fly pausing technique.  But it should be
admitted in
the checkpoint that this is not the only way to accomplish the required

The idea that this specific method is not readily achievable in implementing
animated SVG is prima_facie plausible, and we are not the experts who could
second-guess the implementers with regard to this assertion.  Under the
circumstances, since the stated method is sufficient but not necessary to
remove the P1 barrier, the implementers should be given the benefit of the
doubt on the implementation unreasonableness and we should reword the
checkpoint to give implementers more latitude in which to effect equivalent

Received on Thursday, 12 July 2001 10:46:46 GMT
