Issues about UA Guidelines raised during MAC IE evaluation

Hello,

This week, I had the good fortune of evaluating the UA Guidelines
7 July draft [1] with Tantek Çelik, who is the lead developer
for Microsoft's MAC IE 5.0 [2]. The evaluation was very useful for
a number of reasons:

 - for getting feedback on the increased  precision of the checkpoints
 - for making suggestions about features that could be added to MAC IE 5
 - for identifying ambiguities or bugs in the spec.

We have finished 7 of 11 guidelines, and I hope we'll complete the
evaluation of the rest very soon. The results will appear in the next
implementation report.

Below, I summarize the seven issues that were raised.

 - Ian

[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707
[2] http://www.microsoft.com/mac/ie/

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783


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.

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.

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.

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 12:56:31 UTC