This document is a snapshot of the 50 issues resolved by the User Agent Accessibility Guidelines Working Group as part of the third last call review of the 9 April 2001 UAAG 1.0.
Previous issues lists:
This document last modified: $Date: 2001/08/30 16:29:31 $ by $Author: ijacobs $
This checkpoint talks about controlling particular animations on an individual basis. This is not practical with SMIL and SVG as this goes against the basic data models inherent in the languages. In SMIL and SVG (and QuickTime), there are time containers which are masters over time-based content such as individual animations. The time container is the master that drives the animation as a slave. The animation just responds to commands such as "update yourself to what you should look like X.Y seconds into the animation". The only thing that is reasonable is to allow the ability to pause, accelerate or decelerate the time containers. However, if you have nested time containers, things can still get very complicated as the nested time containers themselves are just slaves to their parent time containers. Selecting these nested time containers would require extensive user interface work on the part of UA developers which would represent large amounts of work just to support this checkpoint.
Refer to proposal based on discussion with SVG representatives on 28 June: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0010.html
This checkpoint is unimplementable as written for language built on the SMIL2 timing model. There is no way for a UA to be able to tell whether user input is restricted to a finite time interval. In fact, it is not possible to know whether user input is happening at all in many cases. SVG in particular responds to low-level user events such as keypresses and pointer device actions. It cannot distinguish keypresses which operate a game console versus keypresses which are entries into a simulated "form". In a general sense, the same is true for any language that supports interactivity and animation. There is no way that a UA can make up for content that isn't structured to allow pausing. This checkpoint should be removed from UAAG. This is a WCAG item only. The only possible feature that a UA might be able to provide in this area is the ability to pause the "root timeline" via keyboard action or to accelerate/decelerate the root timeline, where the root timeline is the clock maintained by the root time container element which starts at "document begin". In SMIL, this would be the <smil> element. In a stand-alone SVG document, this would be the outermost <svg> element. (There is no feasible way to pause any of the subordinate timelines.)
Refer to discussion at 28 June teleconf http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0002
See comments from Al Gilman summarizing some issues: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0103.html
Proposal: - Harmonize this with checkpoint in G6 that says "provide api access to controls. if that not possible, then allow programmatic interaction with functionalities available through the UI.
- Accept definitions of applet in plug-in in 25 May draft.
- No change: conventions are important at a P2 level.
- Fast playback is not required.
- Fast playback should be implemented (technique).
- Checkpoint 4.3 does apply to all regions (same for 4.2, 4.2). The format may not allow background to be set at a global level, but it doesn't matter to the user: the background color has to be "color X" everywhere.
- Single key mode would satisfy 11.4: You enter single key mode, and thereafter you have single key bindings.
- User should be able to enter/leave single key mode with a single key binding.
I think that we should clarify that the user agent can satisfy this checkpoint by entering a "single-key mode"; I would hope that this mode can be activated by a single key.
This means that, for example, the required bindings might not be single-key by default, but very easily, the user agent could provide a single key mode and satisfy the pertinent requirements.
I don't believe that this is inconsistent with 11.4 today, because the single-key binding requirements are not default requirements.
- When default values are inherited through the operating system settings, the user agent is not required to satisfy the default settings requirements.
For checkpoints 7.2, 10.3, 10.7, if the user agent inherits default settings from the operating environment, and if the user can configure them at that level, then the user agent satisfies the checkpoint. For 10.3, the user agent doesn't have to ensure that the differ from one another if they are inherited (and configurable) at the operating environment level. The user agent documentation should explain to the user how to change the defaults at the operating environment level.
For checkpoint 12.3, if the user agent inherits the default input configuration from the operating environment, and if they are documented for the operating environment, then the user agent satisfies the checkpoint. The user agent documentation should explain where to find out information about the default bindings in the operating environment documentation.
Proposal from Ian: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0079.html
- 1.2 is only about input device event handlers only.
Resolved: - 9.5
a) This is not about input device events.
b) This checkpoint should say that this is about any events related to the change of focus (either set or remove). This may include "onchange", but probably should not by specification.
c) Change brief description at beginning of checkpoint.
Imagine a presentation with 80 audio clips in a row (this could be done in SMIL with a <seq> element). Should the position indicator account for all 80? Or each one, one at a time? I wouldn't want the user agent to have to go out to the Web to get duration information about all 80 clips in advance in order to build a proportional position indicator. Instead, I think it would be reasonable to display in that case something like "First of 80 clips, 20% of first clip".
I think we should state explicitly that do *not* specify how such cases should be handled, only that the user have some indication of time elapse.
Suppose you have a text stream that is animated across the bottom of the screen. How does the user agent render that as motionless text? Does it have to wait for the entire stream to render it all as motionless text? What if there's a lot of text content, does it have to render it all in one viewport?
Proposal: The UA does not have to (should not?) wait for the entire stream. It can render pieces of the stream as motionless text (e.g., as subtitles are usually rendered in movies).
IJ: It is my understanding that our document allows conformance for a subset of all formats implemented by the user agent. For instance, the claimant might choose to claim conformance for HTML and PNG, but not for JPEG, even if it implements JPEG. Imagine a media player that implements 20 formats. A developer may not wish to claim conformance for all 20, and shouldn't be required to. IJ: I think that "for all" needs to be restricted to "for all that are part of the conformance claim". I think the same change needs to be made for checkpoint 2.2 ("For all text formats..."),
Refer to comments from Al: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0061.html
IJ: Imagine some content where two interactive streams are playing at the same time, but they are not explicitly synchronized with each other (the synchronization case is covered by 2.6). When the user agent pauses (per 2.4) to allow for user input related to the first stream, what should happen to the second stream? Should it be paused as well, or should it continue? When would the user agent recognize that two streams are synchronized or not (e.g., in SMIL would the <par> element suffice to indicate synchronization?) AG: in SMIL you always know the synchronization requirements across streams. So the SMIL player knows if you can pause one component independently or not. If the two media objects are referenced from the same SMIL file, the answer to this question is given by the SMIL markup and the semantics of that markup. <http://www.w3.org/TR/smil20/smil-timing.html#adef-syncBehavior>http://www .w3.org/TR/smil20/smil-timing.html#adef-syncBehavior
Beyond that, it should be the smallest super-presentation (where the collection of all open windows in a windowing system is a super-presentation) for which there are sync constraints to require it. So the whole screen doesn't have to stop when you stop one thing, necessarily.
In many situations, dynamic content may be accompanied by banner advertisements, for instance. Imagine a presentation where the top of the presentation is occupied by a series of eighty banner ads, one after the other, each lasting 30 seconds. It would seem that pausing the presentation every thirty seconds to allow for user input (for ads or some other content) would not make for a very positive user experience. In short, dynamic content with frequent and numerous opportunities for interaction would not be very usable if paused so frequently. Consider also a stock ticker, where each symbol is a link to that company's home page (or data about that company). How would 2.4 work in this case?
Proposal: No change
It's not clear that all animated image formats make sense with the requirements of checkpoint 3.2. For instance, those animated images "in a box" make sense (e.g., with respect to placeholders that are also "box-like"), but other animated SVG images may not be "box-like".
There may be some cases where certain animations are authored in a way that makes certain requirements not really apply. For instance, it's possible to author an SVG animation where the animation changes based on user input. What does "fast forward" mean for such an image (checkpoint 4.5). In other cases, there may be interdependencies among animations that make the element-level control of 4.4 difficult or impossible (these are the animations that are not "box-like")..
Proposal from Ian http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0079.html
Proposal: a "selection" label (instead of an applicability provision)?
#490: Series of minor clarifications 1) Accept.
4) Definition of "empty" string: no *characters*. GR: People are
afraid that pages won't validate if no spaces. I have proposed
techniques DP: If three spaces are not considered an empty string,
then the screen reader will not know that there is anything
- Accept as we are matching WCAG 1.0 requirements: null alt is considered valid.
- Our focus requirements of G9 mean that people can get to the links.
- Information is available through the DOM and can find out that images are present.
- Empty string has no characters (including spaces).
- Put in techniques document to allow configuration in case of spaces alone. 5) Accept.
10) "Indicate the viewport's position relative to rendered content."
12) Accept. But :
- Don't emphasize single-user environment.
- Change available profiles to available default profiles or those created by the user.
15) Accept. Someone might receive claim by email, or might be on
CD-ROM. People won't make a conformance claim and hide it from
- Add (e.g., on the Web, on CD-ROM, etc.).
- Not just 8.2, but also Guideline 6. Resolved: - Added to well-formed claim requirements that claim must include information that enables the user to identify the user agent (e.g., version for a particular natural language).
According to our definition document source, HTTP headers are part of the document source. But are they part of content?
The answer is no, not according to our document. We say that the document object is generally derived from the document source (and possibly the result of repair, etc.). The user agent is not required to transfer all of the document source to content (i.e., the document object).
We say that content is the document object. And that conditional content is content. Therefore, conditional content does not include Web resources in other formats (content negotiation) or languages (language negotiation) that the user agent could access but has not due to the user's configuration.
Proposal: Add the following Note to the beginning of the glossary: "This is a normative glossary, although some of the terms (or parts of explanations of terms) do not affect conformance." I don't think it's worth trying to identify the normative and non-normative parts of the glossary. Or rather, it might be worth it, but I don't want to do it right now.
22a) Change "all changes" to "important changes". This allows some filtering, and probably requires no more interpretation than "all changes" (i.e., it is no more vague thatn 12.5 already is). This doesn't address the problem of confidential information, but I don't think we can do much about that. Instead, it allows developers to satisfy the checkpoint by providing a reasonable list of important changes.
22b) Make this checkpoint a Priority 3 checkpoint. [This part of the proposal can be considered separately.] As a result of issue 373 , we chose not to make this checkpoint a P1 checkpoint (since the full documentation is available, so having the changes available separately is not a P1 requirement). However, I am not convinced that having the list of changes available merits even priority 2.  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#373
21a) In checkpoint 8.1, change the statement to: "For the purposes of this document, the accessibility features of a specification are those identified as such and those that enable the author to satisfy the requirements of the "Web Content Accessibility Guidelines 1.0" [WCAG10], whatever the priority." Editorial: Should this read "and those" or "or those"?
21b) Harmonize the language of Guideline 12 Notes as follows: "For the purposes of this document, features that benefit or affect accessibility are:
19c) I'd like to factor 21b into one Note (e.g., 12.2) then cross-reference it from the other checkpoints in Guideline 12.
What if the content is being rendered in black and white (or more likely, different pieces of content are being rendered in different shades of grey)? This checkpoint is designed so that users with some color deficiencies can hope to distinguish selection from focus, etc. by default. Can users with color deficiencies distinguish black from grey? (Obviously, it would be hard for anyone to distinguish two similar shades of grey. We don't talk about "contrast" in any of the checkpoints, because we don't have any requirements that rely on color by default.)
I don't know whether "greying out" disabled elements would be considered a sufficient mechanism for distinguishing, for example, "enabled" from "disabled" elements. Similarly, is a "bold" font distinguishable from "regular" font?
Refer to proposal http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0220.html
A user can still navigate to event handlers and activate
potential events is the P1 requirement. Knowing what events are
available was considered P2 by the group.
See : http://www.w3.org/WAI/UA/2001/03/ua-minutes
Refer to similar comments based on discussion with Tantek Celik: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0073.html
Refer to comments from Rich on value of standard APIs http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0132.html