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...