W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2001

RE: [Issue 516] Is ordered rendering required to satisfy checkpoint 2.4?

From: Denis Anson <danson@miseri.edu>
Date: Thu, 26 Jul 2001 00:46:48 -0700
To: "Ian B. Jacobs" <ij@w3.org>, <jferraio@adobe.com>, <lilley@w3.org>, <dean@w3.org>, <w3c-wai-ua@w3.org>
Message-ID: <MABBJAAJBBFHFPAHFOBJEEGECCAA.danson@miseri.edu>
Ian,

I think that there may be other reasonable scenarios as well.

There are two components to the issue of time dependent links for the person
with cognitive limitations: the first is reaction time (can I activate the
link before it disappears), and the second is recognition time (can I tell
that there is a link there before it disappears).  A person with cognitive
issues will likely have involvement in both compnents of this issue.  As a
result, various scenarios may "appear" a bit different.

In scenario 1, where the links are presented without context, it might be
very difficult to connect the link with its intended action, since the
mental processes that provide meaning to the link are not operating *at the
time* of the link.

In scenario 2, the process of manually advancing provides an additional
cognitive load that might make it impossile to process the information being
provided.

In scenario 3, the stopping for a link would indicate to the user that some
input is needed, and would cue that links should be examined.
(Additionally, in many cases, the user would know that the link was about to
disappear, so would be cued to look for links on the objects that are about
to pass out of view.)

To some extent, the issues of processing time are handled by checkpoints 4.4
and 4.5, which allow slowed presentation and rewind capabilities.  The
remaining issue is to assure that the user knows that a link is there.  For
a static document, you can tab through active elements, so the fact that you
can navigate to an element tells you that it is active.  One of the big
issues that we are dealing with here is the time required to recognize and
respond to a link in a multimedia presentation.  So, an additional way to
deal with the issue might be to be able to configure the user agent so that
it highlights animated links in a way that the user will choose, and
presents the animation slower when a link is on the screen, combined with
the ability to rewind to pick up a link that just went past. (This is
already P1 in 4.5)  A user style sheet, if style sheets had the ability to
control rendering of the SVG presentation, might do the job.

Denis Anson

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Ian B. Jacobs
Sent: Wednesday, July 25, 2001 9:20 AM
To: jferraio@adobe.com; lilley@w3.org; dean@w3.org; w3c-wai-ua@w3.org
Subject: [Issue 516] Is ordered rendering required to satisfy checkpoint
2.4?


Hello,

After the 19 July teleconference, I spoke with Dean Jackson about
issue 516 [2]: "2.4: Checkpoint doesn't make sense for SMIL 2.0".
In the 14 July draft [3], the first provision of the checkpoint
is:

  "For content where user input is only possible within a finite
  time interval controlled by the user agent, allow 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."

At the 19 July teleconference, there was a proposal to delete the
second sentence. It was suggested that a sufficient technique
would be to allow time-independent interaction.

I'd like to examine three scenarios more closely:

  Scenario 1: The user agent renders content with no time line.
  All content is independent of time and is unordered (except for
  document order). All interaction is possible immediately (since
  there is no time line). This is like an HTML document or an SVG
  document where the animation elements have been ignored.

For the next two scenarios, imagine a presentation that may be
paused and resumed manually by the user (like a videocassette
player). The user may interact with the document (e.g., links,
user focus events, etc.) in either the paused or play state.

  Scenario 2: Time line, but no automatic advance. In this
  scenario, nothing happens automatically: the user must step
  through the entire presentation manually. Thus, order is
  preserved, and all time intervals are infinite since the user
  advances manually.  This would "solve" the problem we are
  trying to solve, but would probably be unwieldly because the
  user would have to step through the entire presentation.

  Scenario 3: Time line, with semi-automatic advance. In this
  scenario, the animation proceeds until there is a finite amount
  of time for user interaction. In this scenario, the desired
  user agent behavior is to pause automatically to allow for user
  input, and resume automatic play upon explicit request from the
  user.

(There is a fourth scenario: the user agent should follow the
timing and rendering rules of the specification. Of course, the
UA should do that in general, except for where we require
additional functionality.)

I was under the impression by the end of the 19 July teleconf
that people may have been satisfied with some variation on
the first scenario, but it may not have been clear what the
implications are: order is lost, and that may mean substantial loss
of meaning. I do not think that this is the proper scope of the
checkpoint, as the semantics of the presentation should be
preserved as much as possible.

I am interested in feedback from the Working Group about which
scenario they expected checkpoint 2.4 to cover. It may be
possible to rewrite 2.4 to cover scenario 3, but still to remove
the technique for pausing infinitely. I welcome suggestions on
how to preserve order and remove time-dependence.

--------------------------
On implementing scenario 3
--------------------------

Dean and I talked about ways in which an SVG viewer might
implement the third scenario. We talked about the implementation
having two components (for the purposes of this discussion): an
animation engine and a user interface component. As I understand
the model, the viewer operates as follows:

 a) The animation engine's job is to calculate positions of
 graphical objects. For each increment on the time line, the
 animation engine calculates the position of each displayed
 object.

 b) After the animation engine has calculated positions, the user
 interface component redraws the objects at their new positions.

 c) Loop until done.

Here's how we imagined it would be feasible to implement scenario
3.  It assumes that there's a mechanism that allows the user to
manually pause and resume a presentation.

 1) The animation engine knows when it's at the end of a time
 interval. After all, it uses this information as part of its
 calculations to determine the position of graphical objects.

 2) When the animation engine is at the end of a time interval,
 it calculates which animated elements will be affected. This is
 known through markup (either by parent/child relationship or by
 href). Furthermore, the only elements we are interested in here
 are those that are known by specification to have associated
 behaviors. The animation can designate a set of elements using
 xpath, for example.

 3) The animation engine tells the UI component to pause the user
 agent and highlight the elements that are affected.

 4) Thus, the user agent automatically enters "paused mode",
 allowing the user to interact with links, etc (some of which
 have been highlighted to emphasize that they are
 time-dependent).  The user can manually resume the presentation
 when the user wishes.

I am interested in feedback from developers about whether this
makes sense.

 - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0136
[2] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#516
[3] http://www.w3.org/WAI/UA/WD-UAAG10-20010714/

--
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Cell:                    +1 917 450-8783
Received on Thursday, 26 July 2001 07:46:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:58 GMT