RE: Issues about UA Guidelines raised during MAC IE evaluation

See comments below:

Denis

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Ian Jacobs
Sent: Friday, July 14, 2000 9:56 AM
To: w3c-wai-ua@w3.org; tantek@cs.stanford.edu
Subject: Issues about UA Guidelines raised during MAC IE evaluation



ISSUES

Issue 1) Is the UA responsible for control of timed presentations
created
         by scripts?

   Checkpoint 2.2: For a presentation that requires user input within a
   specified time interval, allow the user to configure the
   user agent to pause the presentation automatically and await user
input
   before proceeding.

   Ambiguity: There was some confusion as to whether the word
"presentation"
   included timed user interface behavior (e.g., a menu that closes
after, say,
   5 seconds if the user has not activated a menu entry). To address
this, we
   should have a definition of "presentation". I think this fits into
our
   discussion of multimedia terms (refer to issue 289).

   Issue: Should the user agent be responsible for timed content changes
   that are due to scripts (e.g., a script causes some piece of active
   content to appear for 5 seconds then disappear)? My opinion is that
   scripts do not apply here. There is no way for the UA to know what
each
   script will do a priori. We do require that the UA allow the user to
turn
   of scripts. But this seems to be more of an authoring problem
   (and this is the same issue I think for even handlers - the UA
   doesn't know what they will do).

   No change may be required for the checkpoint, however, since the UA
is
   not required to satisfy the checkpoints in cases when it cannot
recognize
   the timing effect (this is part of applicability). It may be
worthwhile to
   add a note about scripts after the checkpoint.


Comment here:*******
Since scripts are interpreted, the agent that does the interpreting should
be responsible for timing events.  If the user agent is running a timer in
interpreting a script, the fact that it is doing so should be available to
the agent.  Any event that starts a timer, stops a timer, then rerenders the
screen should be recognizable, and interceptable at the point of changing
the rendering of the screen.  A "prompt before rerendering" flag might solve
a lot of the time-based issues.

End of comment ********

Issue 2) Native support

  The definition of "native support" begins:

        A user agent supports a feature natively if it does not require
        another piece of software (e.g., plug-in or external  program)
        for support.

   Question: The line between native support and optional modules may be
   blurry at times. Suppose that the MAC IE developers make available
   updates on the MAC IE home page [2] and allow users to update their
   browsers from the Web. Strictly speaking, this support would not
   be considered native since it required an extra download. However,
   since the browser builds in (or could build in) an option to select
   from available upgrades and install them automatically, it seemed
like
   it was "almost" native support - this would be little different from
   being able to install plug-ins available on a CD-ROM but not
installed
   by default.

   I think the WG should discuss the topic of the availability of
upgrades
   and the relationship to native support.

Start of comment ******

The ownership of the code that does the rendering seems to be the issue
here.  If IE is updated in a way that it has "ownership" of the revised
code, it becomes native.  The overall idea is to decide where the buck
stops.  If you wrote the code, the buck stops with you.  If IE contains code
that does rendering, as opposed to passing off that function, the buck stops
with IE.

End of comment *******

Issue 3) Repair functionalities required?

   Question: The UA Guidelines requires conformance to specifications.
However,
   it also requires in checkpoint 2.5 a repair functionality that is not
part
   of conformance to a specification:

      2.5 For non-text content that has no recognized text equivalent,
      generate a text equivalent from other author-supplied content.
      If the non-text content is included by URI reference, base the
      text equivalent on the URI reference and the content type of
      the resource.

   This document is asking the UA to repair broken markup, but the HTML
   specification doesn't require this. Although I doubt that there's
   much of an interoperability issue here, the question is pertinent:
   if we ask UAs to do things but don't provide a standard for doing
   so, we threaten interoperability.

   So the question is: should we require this repair functionality?
   What do we tell browser developers who ask "Where does it say in
   the markup language specification how to do this?"

Issue 4) Proposed to add "control" to checkpoints 4.2 (font family),
   and 4.3/4.4 (colors). You may need to override the color of a
specific
   element, for example.

Issue 5) Style v. content and background sounds.

   [Note: I believe Eric has already raised this point a number of
times.]
   Question: Some content is only meant to decorate. This includes
simple
   graphics, colors, animations, and sounds (namely background sounds).
   We require the UA to allow the user to control the volume, speed, and
   other aspects of animations and sounds. But it seems like this is
overkill
   for visual or sound content that is only meant for decoration.

   The author is required by WCAG 1.0 to include text equivalents
   for every non-text. It may be a bug in WCAG 1.0, but I don't think
this
   should be required for non-text content that is only used for
decoration.
   We don't require a text equivalent for the fact that the background
color
   of a page is pale yellow. Should we require a text equivalent for
   a background sound that adds to the browsing experience but is only
   *background sound*, i.e., decoration?

   At the 29 June teleconference [3], we discussed the fact that
"background
   audio" means audio that starts automatically on load. I would like to
now
   argue instead (or perhaps in addition, but I don't think that on-load
is
   a key characteristic) that background audio means audio that only
serves
   a decorative function.

   [3]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0532.html

   So the question is: in the UA Guideilnes, we should require control
of
   audio and animation that act as content, not as decoration. The
problem
   is how to recognize the difference - I don't know how the UA would be
   able to tell the difference. This is a very strong argument, in my
opinion,
   for using style sheets to achieve these effects, since then the user
   agent really does know that the effect is stylistic only.

   Therefore I propose the following:
      - For checkpoints that require configuration to not render
animations
        (3.3 and 3.4) that the checkpoint apply to all animations. This
        will be easier for developers, I believe, and no distinction is
        between decoration and content is required at this level since
the
        control pertains to movement.

      - For global audio control (4.8), I think this applies to all
audio
        content.

      - For checkpoints that require control of animations and audio
        (4.5, 4.6) we should reduce the scope for those animations and
        audio that are not meant for style. In the techniques document
        we would indicate that style sheets and known markup to cause
        background images (that could be aniamted) and background sounds
        do not require start / stop, etc. control.

Start of comment ******

The problem here is that it is very possible for the "decoration" to render
a page inaccessible if it isn't possible to turn them off, or change the
volume, for example.  And, since it is generally impossible to distinguish
between a purely decorative element and a content element, reduced scope
becomes almost impossible.

If I have a page that contains both decorative sounds and informative
sounds, how would I turn off just the decorative ones unless I have an
item-by-item degree of control?

End of comment *******

Issue 6) Navigation of active elements.

   Question: HTML specifies a "tabindex" attribute so that authors may
   identity the sequential navigation order of certain elements. If a
   user agent supports tabindex 100%, does this establish the set of
   elements that are considered active for HTML? (refer to definition
   of active element and checkpoint 7.3 and 7.4). The definition of
active
   element reads:

     "In HTML 4.01 [HTML4] documents, for example, active elements
      include links, image maps, form controls, element instances
      with a value for the "longdesc" attribute, and element
      instances with scripts (event handlers) explicitly associated
      with them (e.g., through the various "on" attributes)."

   (MAC IE 5 does not allow navigation of elements with event handlers
   attached., but does for other elements.)

   Similarly, checkpoint 1.4 requires device-independent
   activation of elements with event handlers attached:

       1.4 Ensure that the user can interact with all active elements
       in a device-independent manner.

   The question of repair functionality is also raised again:
   is the user agent required to allow keyboard activation of an
   event handler specified by the author to be for the mouse?

   I don't have a proposal for addressing the issue of navigation to
   and activation of elements that have scripts attached (and all this
   in a device-independent manner).

   IMPORTANT: We also need to clarify that a some elements may not
   be active at all times. For instance, if support for scripts is
turned
   off, then event handlers are useless and navigation to them should
not
   be required. Similarly, the "disabled" attribute in HTML 4 (which may
   be toggled through scripting) specifies that an otherwise active
   element is not currently active.

Issue 7) Important elements (checkpoint 7.6).

  Proposal: In the techniques document, I propose that we list for HTML,
  SMIL, and other languages what we consider the important elements to
  be. If the list is "normative", then it needs to go in the Guidelines
  document. And then there's a editorial question of how to include a
long
  list of elements in the guidelines...

Received on Friday, 14 July 2000 15:06:44 UTC