- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 14 Jul 2000 12:56:24 -0400
- To: w3c-wai-ua@w3.org, tantek@cs.stanford.edu
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