- From: Denis Anson <danson@miseri.edu>
- Date: Thu, 29 Mar 2001 15:21:04 -0500
- To: "'Ian Jacobs'" <ij@w3.org>
- Cc: <w3c-wai-ua@w3.org>
If you go to http://www.landware.com/products/gotype/gotypeps.html, you will find information about the GoType! Keyboard for the Palm platform. This device adds keyboard functionality to the Palm device, adding an keyboard API to all input that isn't normally built in to the device. The keyboard is delivered with software that is installed on the Palm to allow the keyboard to communicate with the standard Palm applications. This is a custom API that doesn't fit under the rubric of either accessibility API or system API, so fits under the proposed revised 6.6. It also can be used to make the Palm accessible to those who use, for example, a head-stick to type, and wouldn't ordinarily have access to the Palm platform. Denis Anson, MS, OTR/L Assistant Professor College Misericordia 301 Lake St. Dallas, PA 18612 -----Original Message----- From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Ian Jacobs Sent: Thursday, March 29, 2001 1:45 PM To: Greg Lowney Cc: w3c-wai-ua@w3.org Subject: Re: Responses to Greg Lowney issues raised during second last call of UAAG 1.0 Hi Greg, Thanks for the thorough review. I have a couple of requests: a) Please indicate whether we can consider substantial comments during, rather than before, last call review. b) Please indicate any strong objections you have that you wish us to carry forward on the Recommendation track. You may want to wait until the WG has had a chance to evaluate your comments. Note that we have instituted an issues list [1] for things to do after UAAG 1.0. We will add to that list any proposals or ideas that we do not address in this version of UAAG. [1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-new.html Thank you, - Ian Reference document: http://www.w3.org/WAI/UA/WD-UAAG10-20010323/. ------------------------------------------ My replies to your comments (labeled "GL") ------------------------------------------ Note: Sorry folks, this email is pretty long. I suggest that we break issues into smaller emails for subsequent discussion. I've split my comments (labeled "IJ2") into five sections: 1) Substantive new issues / new information / proposals 2) Editorial new issues / new information / proposals 3) Substantive disagreement with no new information 4) Editorial disagreement with no new information 5) Agreement Here's why: a) I think that we should fix editorial comments to the extent possible before we go to last call. b) I don't think we should spend more time discussing issues where there is no new information, and you should register an objection where you feel strongly. c) For new issues, we should either try to address quickly or move to the "future stuff" issues list. Similarly, for new information about old issues, we should see whether we want to discuss further. If we don't, you should register an objection where you feel strongly. My proposals are indicated by "IJ-proposal" ==================================================== Substantive new issues / new information / proposals ==================================================== --------------- Issue 393 (Second Last Call): Checkpoint 1.2: Change to P2 for exposing through other programmatic means. <IJ> This requirement was folded into a new checkpoint: "6.6 Implement standard accessibility APIs (e.g., of the operating environment). Where these APIs do not enable the user agent to satisfy the requirements of this document, use the standard input and output APIs of the operating environment." [Priority 1] Thus, while the priority of implementing standard i/o APIs was not changed to Priority 1, the Working Group agreed that it was more important to first use available accessibility APIs (which are higher level than the i/o APIs) and to only use the i/o APIs in failure mode. </IJ> <GL> This is much better. However, if the platform does not let AT monitor standard I/O APIs, then using these I/O APIs should not cause the UA to conform with this checkpoint. I would recommend adding a third sentence, as follows: <GL 6.6> "Implement standard accessibility APIs (e.g., of the operating environment). Where these APIs do not enable the user agent to satisfy the requirements of this document, use the standard input and output APIs of the operating environment. Where these APIs do not enable the user agent to satisfy the requirements of this document, provide UA-specific APIs that meet these requirements." </GL 6.6> </GL> <IJ2> I support your proposal. I think your intention is currently covered by 6.6 in conjunction with 6.4: 6.4 Provide programmatic read and write access to user agent user interface controls. [Priority 1] User agent only. Note: Per checkpoint 6.6, provide programmatic access through standard APIs (e.g., platform-independent APIs such as the W3C DOM; standard APIs defined for a specific operating system; and conventions for programming languages, plug-ins, virtual machine environments, etc.). This checkpoint requires user agents to provide programmatic access even in the absence of a standard API for doing so. IJ-proposal: However, I would like to adopt your proposal for the following reason: I think the cascade: * Standard accessibility API * Standard device API * Some (non-standard) API should apply to other checkpoints than 6.4. We last modified checkpoint 6.4 as a result of issue 457[1] in order to clarify that even when a standard API didn't exist, communication through an API was required. [1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#457 However, the following checkpoints also include the phrase "using standard APIs" and it's not clear whether access is required even where standard APIs don't exist: 6.3 For markup languages other than HTML and XML, provide programmatic access to content using standard APIs (e.g., platform-independent APIs and standard APIs for the operating environment). 6.5 Using standard APIs, provide programmatic alert of changes to content, user interface controls, selection, content focus, and user interface focus. Does the WG agree that these functionalities should also be provided, even in the absence of a standard API? If so, then it makes sense to adopt Greg's proposal and to factor out the "standard API" part out of 6.3 and 6.5. The difference between 6.3/6.4/6.5 and 6.6 is "standard API" versus "standard accessibility API". Is that a substantial difference? Note that checkpoint 6.7 "trumps" 6.6 because it always requires standard APIs for the keyboard. </IJ2> --------------- Issue 414 (Second Last Call): Checkpoint 7.3: Need stronger min requirements <IJ> There has been no increase in the minimal navigation requirements for what is now checkpoint 9.2: "9.2 Allow the user to move the content focus to any enabled element in the viewport. If the author has not specified a navigation order, allow at least forward sequential navigation to each element, in document order. The user agent may also include disabled elements in the navigation order." One reason that there has not been an increase is that there are other navigation requirements in the document (search, structured navigation). Thus, this checkpoint alone does not guarantee simple access (but it does meet the definition of a P1 checkpoint), but we anticipate that access will be possible by the sum of the navigation requirements. Please feel free to suggest alternative minimal requirements. </IJ> <GL> Your point is well taken, that search and structural navigation are covered under a separate checkpoint (9.9). However, those are only Pri 2. I would argue that reasonable keyboard access to enabled elements is a baseline requirement for accessibility, and single-direction, sequential navigation alone would not satisfy that. I would not want a UA to earn single-A compliance with only this level of keyboard navigation. </GL> <IJ2> As you note below, checkpoints 9.2 and 9.3 (move focus to enable element, activate) are both P1. </IJ2> <GL> I consider the ability to move backwards, or the ability to undo the last navigation, to be considerable help in reducing the amount of work required to recover from navigating past your intended destination. For example, take the case where you want to activate the last link in a list. In a UA that only supports forward navigation between active elements using the TAB key, you press TAB repeatedly hearing the items in the list, but you cannot tell that you're at the last one until you press TAB and hear something clearly outside the list. To continue, you must back up one link. Without the ability to navigate in reverse order or undo a navigation command, the user would have to cycle all the way through the document, which could require over a hundred commands. </GL> I note that the requirement to support structural navigation (9.9) does require both forward and backward directions. Therefore, I would conclude that either (a) you should add backwards navigation to 9.2, or else (b) consider 9.2 just a special case of 9.9, by explicitly mentioning enabled elements as important structural elements, or (c) increase 9.9 from Pri 2 to Pri 1. </GL> <IJ2> In the past, the WG has not agreed to adding reverse navigation as a minimal requirement for checkpoint 9.2. Perhaps in light of your discussion, the WG will want to reconsider or reconfirm that decision. </IJ2> --------------- Issue 418 (Second Last Call): Checkpoint 7.5: Search should include alt text. <IJ> The Working Group felt that any rendered content should be part of the search, but undrendered content should not since this would be disorienting to the user. Instead, other requirements of the document require access to all content, and when rendered, that content is subject to the search requirement. </IJ> <GL> I disagree: I think it is equally disorienting to be able to see text on the screen and yet not find it with search just because, unbeknownst to you, it's represented by an image of text. However, I can live with it. But maybe make it a lower priority recommendation to provide an option to search non-rendered equivalents? </GL> <IJ2> Our search requirement is on text characters only, not images that display text. Therefore, the search requirement wouldn't find the image in question. I would oppose adding a non-text-based search at this time. I would also oppose adding a requiremen to search on unrendered content at this time, not only because we already agreed not to, but because I don't think we have any experience with this. </IJ2> --------------- Issue 426 (Second Last Call): Checkpoint 9.8: Clarify that brief sequences satisfy this checkpoint <IJ> This is now checkpoint 11.4. In both the 9 March 2001 draft and the 23 October draft, this checkpoint does not make any requirements about the complexity of bindings because those requirements are addressed by other checkpoints. Thus, no change was required. </IJ> <GL> I don't understand the resolution: it seems clearly to describe bindings of a single keystroke. I would recommend extending this to include brief key sequences. It does not seem possible to allow the user to bind a majority of the functions to single, unmodified keystrokes-there are a very limited number of keys available for this purpose, if you don't want to interfere with the user's ability to type in normal text. </GL> <IJ2> The WG is already considering this problem as issue 468 http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#468 </IJ2> --------------- Issue 429 (Second Last Call): New requirement: documentation of API for querying preferences. <IJ> The Working Group did not add these requirements today for two reasons: - There is no known interoperable API for exchanging user preferences. The Working Group intends to pursue this (e.g., with the DOM WG) after UAAG 1.0. - The benefit to accessibility has not been studied. </IJ> <GL> I disagree with this resolution on two counts. First, my major goal is to make sure that people writing add-ons and plug-ins for specific user agents can make them accessible. Thus, I'm not worried about the need for API that works across multiple user agents. Second, I think my example makes clear that without this, every add-on and plug-in will have to provide its own means of allowing users to set configuration parameters that affect accessibility. In many cases there will be no convenient place to put UI for this, and in any case it will end up with gross inconsistency between components. </GL> <IJ2> You distinguish plug-in (which I presume to mean "in process") from other types of communication. Is there a technical reason to distinguish in-process from out of process? I think the question of interoperability still applies (since interoperation is still required in-process). Do you have any examples of such an API? For instance, if browser preferences are stored in the Windows registry, I would consider that an instance of your request. Similarly, on X Windows, XResources configuration files offer a configuration standard. </IJ2> --------------- Issue 442 (Second Last Call): Checkpoint 9.4: Does this include default mouse click behavior? <IJ> Yes it does, but only if you are claiming conformance for the pointing device. </IJ> <GL> (1) OK with this since it's only priority 2. However, I have never seen any browser allow reconfiguring of mouse input mappings. I still think it should be priority 3, but I won't argue about it. </GL> <IJ2> They may not do it, but I don't know that it's a bad idea. Suppose that I have to do "shift-left-mouse" to accomplish something that I would like to accomplish instead with a right click alone. That seems useful. </IJ2> <GL> (2) Why limit this only to the same input modality? In theory you should be able to access all functionality using either mouse or keyboard. <GL> <IJ2> This device-independent operation is ensured by other requirements of the document. But for example, you might not easily remap 100 key bindings to a 3-button mouse. So we keep the reconfiguration requirement to a per-device requirement. </IJ2> <GL> In addition, mapping input to underlying functionality should be a valid way to comply, rather than mapping one input to another input, which is an indirect mapping to an underlying functionality. For example, if clicking the secondary mouse button brings up a shortcut menu for the selected object, then the user should be able to bind that feature to a keystroke, key combination, or key sequence to bring up that same menu for the object with the focus. </GL> <IJ2> Yes, I agree. And that requirement is made by checkpoint 1.1. </IJ2> <GL> (3) I do not understand why you allow the UA to refuse to remap bindings just because they are standard for the operating environment. The standard bindings may not be appropriate for some users, and therefore I would recommend that the UA allow the user to override them. </GL> <IJ2> If this is the case, the operating environment should let the user remap the keys to something more useful at the operating environment level first. </IJ2> --------------- New Issue Regarding checkpoint 10.2: <GL> This checkpoint says "Ensure that all of the default highlight styles for the selection, content focus, enabled elements, recently visited links, and fee links (1) do not rely on color alone, and (2) differ from each other, and not by color alone. [Priority 1] Both content and user agent." I do not agree that this should be Priority 1. I believe that nearly all checkpoints that merely describe default behavior should be priority 2 or lower. I consider it not merely infeasible but actually impossible to create a default configuration that satisfies every user. Therefore we have to assume that users will be able to successfully change the configuration. Therefore minimal standards for UA should be to provide these options, and choosing a good default should be part considered "beyond the minimum." The exception to this is behavior that affects the user's ability to change the UA's configuration; therefore, accessible behavior of the user agent's user interface can be required as part of the minimum standard. </GL> <IJ2> I find this comment very interesting! There are a few checkpoints that make requirements for default configurations: 7.2 (P1), 10.2 (P1), 10.7 (P1), 11.5 (P2). I think that the reason we made 10.2 and 10.7 P1 checkpoints is that the user may not easily perceive the problem. I agree that as long as the user can override the default, this is less severe than the exception you cite ("by virtue of the inaccessibility of the default configuration, the user can't make the necessary change"). Just to make sure, can the user override the configs required in 7.2, 10.2, 10.7, and 11.5? 7.2, 11.5 (input configurations): Override possible at *P2* level in checkpoint 11.3. 10.2, 10.7: (highlighting): Configuration P1 in checkpoint 10.6 for selection/focus and *P2* in 10.3 for fee links, etc. So in essence, it would seem that the WG has chosen the opposite of what you suggest: The top priority is that these mechanisms be (reasonably) accessible by default, and that the configuration requirement is a lower priority. I think that the Working Group should discuss these two models. On a side note: IJ-proposal: The "For user agents" label is broken in checkpoint 10.6, since the requirement pertains to selection and *content focus*. It should be "For content only". </IJ2> --------------- New Issue Regarding checkpoints 6.3, 6.4, and 6.5:. <GL> I am having second thoughts about requiring standard API as a Priority 1 requirement. I think that the minimum, priority 1 requirement should be to expose this information through *any* API. If they do it through a standard API that is even better, so I would make that Priority 2. You may disagree, but I think it would be a positive thing for users if it would cause some UA to expose their content through an existing native object model, when they would otherwise not expose it at all because of the high cost of implementing an entirely separate, standard API. It is better to have an awkward solution than no solution at all. </GL> <IJ2> This is also an interesting proposal. I think that the Working Group has argued in the past that "some API" is not sufficient because it makes implementation more difficult for AT developers. The Working Group should confirm its decision. </IJ2> ================================================== Editorial new issues / new information / proposals ================================================== --------------- Issue 395 (Second Last Call): Checkpoint 3.8: Make images optional <IJ> The requirement now includes a configuration for placeholders. Please refer to checkpoint 3.7 in the 9 March draft.I agree with this solution. </IJ> <GL> However, I am not happy with the phrase "on activation" in the final sentence, "When placeholders are rendered, allow the user to view the original author-supplied content on activation of each placeholder." I'm not sure what this means in practice. In the fragment, <A HREF="#a"><IMG SRC="b.jpg"></A>, what does it mean to activate the IMG element in order to view the associated file b.jpg?</GL> <IJ2> One answer to your point is to say "activation, in the case of a placeholder, means replacement with the original content." This is consistent with saying, for example, "activation, in the case of an HTML A element, usually replaces the current resource with another in the same viewport." As the definition of "activation" says: "The effect of activation depends on the type of enabled element or user interface control." IJ-proposal: However, I would not object (and would consider it editorial) to changing the sentence to something like: "When placeholders are rendered, allow the user to view the original author-supplied content associated with each placeholder." Note also our open issue 467: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#467 </IJ2> <GL> Normally one would put the focus on the A element, and activate that, which would jump to another location. If UA were required to provide keyboard focus not only to the link but also to any content inside the link, it would make navigation more cumbersome. </GL> <IJ2> I don't think that's the only way one might implement this. How do people implement longdesc today? That's another case of two-links-in-one. </IJ2> <GL> Also, the process of downloading an image should not be linked to activating the image, should it? </GL> <IJ2> I'm not sure why not. Or I'm not sure I understand your point. </IJ2> <GL> This applies to other checkpoints as well. </GL> --------------- Issue 399 (Second Last Call): Checkpoint 4.7: Implementation experience for this? <IJ> The Quicktime player allows positioning (but not when captions are streamed; only when they are downloaded and played). The RealPlayer does not (yet) support caption positioning for SMIL, but the SMIL specification itself allows this. We are working on getting more implementation experience/commitments. In the meantime, the Working Group resolved to maintain this as a P1 requirement. </IJ> <GL> OK. However, in the sentence "Allow the user to choose from among the same range of positions available to the author (e.g., the range of positions allowed by the markup or style language)," should that read "from among all positions available to the author" to avoid implying that the UA must support EXACTLY the same range of positions and not a superset of those positioned available to authors? For example, the UA should be able to let the user move the captions to a window outside the viewport, which may not be an option available to the content author. Perhaps this can be clarified in a note or in the techniques document. </GL> <IJ2> IJ-proposal: I agree that the wording of what is now checkpoint 4.6 could be clarified to something like: 4.6 For graphical viewports, allow the user to position text transcripts, collated text transcripts, and captions in the viewport. Allow the user to choose from at least the range of positions available to the author (e.g., the range of positions allowed by the markup or style language). [Priority 1] Content only. </IJ2> --------------- Issue 409 (Second Last Call): Checkpoint 4.20: If frames are not opened, what is result? <IJ> The following Note has been added to checkpoint 5.3: "If a viewport (e.g., a frame set) contains other viewports, these requirements only apply to the outermost container viewport." </IJ> <GL> The resolution proposed is fine, but not directly responding to my comment. Despite Ian's statement above, the checkpoint wording makes it sounds like the UA *is* forced to suppress opening frames if the user does not confirm the action through one means or another. My question is, is the purpose of this checkpoint to "alert the user" when a new frame is opening, by making them take some action in response to some notification? Or is it to ensure that UA "allow the user to [only] open [the viewport] on demand", which amounts to encouraging users to prevent new frames from opening by declining some offer? If it's only the former, there are other ways of notifying the user that are not so intrusive, such as a standard sound. If the latter, I still wonder if users will be very confused when the decline to let the viewport open and then find that the content they're trying to read does not make sense. </GL> <IJ2> The requirement is actually to prevent new viewports from opening. The accessibility issue is information overload (and possibly also navigation complexity among viewports). "Disorientation due to sudden changes" has been associated more with changes to focus, so that's covered in 5.1 As to user confusion, 5.3 includes the requirement to allow the user to open the viewport on demand, so the user should be able to go back and get it if they decide they need it. I would note that in the context of a synchronized presentation, where the timing of the opening of the viewport is critical to the presentation, then the user can break the author's intention by suppressing the viewport creation. We are covered in this case to a certain extent by checkpoints in Guideline 4 about controlling presentations, but I suspect there are some scenarios we haven't yet understood or discussed. Nonetheless, I don't think that the current checkpoint is therefore wrong, only that it may not address all possible scenarios where opening viewports present problems to users. </IJ2> --------------- Issue 430 (Second Last Call): Checkpoint 3.2: Animations, not just animated images <IJ> There are several checkpoints related to animations in UAAG 1.0: 3.2, 3.3, 4.4, 4.5, and 4.7, 4.8. The Working Group felt that the requirement of checkpoint 3.2 was about turning off rendering of a block of content that might be be visually disorienting, but not because of the motion; just because of the quantity of information. Thus, checkpoint 3.2 has been limited to "video and animated images", while checkpoints 4.4, 4.5, 4.7, and 4.8 (which are about motion) have been broadened to include all classes of animations, as you suggested. Furthermore, a definition of "animation" has been added to the document to clarify what is expected. </IJ> <GL> I appreciate the expanded definition of animation. The current checkpoints allow the user to replace different types of complex presentations with placeholders. These are split up between checkpoints 3.2 (animated images, video, and audio), 3.3 (animated text), and 3.7 (static images). However, three examples of "animation" are given: sequential images, scrolling text, and displacing objects. The first two are covered by checkpoints 3.2 and 3.3, respectively, but where is the third type covered? </GL> <IJ2> Checkpoints 4.4, 4.5, 4.7, and 4.8. The checkpoints in Guideline 3 are really about suppressing blocks of content that may be disorienting. For animations, we only include specific subclasses (animated images, animated text, video). The most general class of animation (moving ball) did not lend itself to placeholder replacement. </IJ2> <GL> Also, with regard to 3.2, I'm still not sure why "quantity of information" is more of a problem with an animated image than with animated text. It seems like, in many cases, they two are indistinguishable by the user and therefore should have the same accessibility requirements. </GL> <IJ2> My understanding is that there is a difference to some users with cognitive disabilities between visually displayed images/graphics and visually displayed text. Our goal is not to suppres the rendering of all content, only images. (Thus, the requirements of 3.3 are not to suppress rendering of text, only to stop the motion/blinking.) </IJ2> --------------- Issue 432 (Second Last Call): Checkpoint 3.4: Overlaps with 3.2 <IJ> The Working Group disagrees that blinking images and animated images are the same: blinking is an on/off effect. There is no requirement to slow down this blinking effect (only to stop it). There are requirements to slow down animation effects, so that users can understand the changes to content. </IJ> <GL> Actually the checkpoint to "Allow the user to configure the user agent to render blinking images as motionless images" seems to have been removed, making this point moot. </GL> <IJ2> Yes. Sorry I missed that in my summary. We deleted that checkpoint starting in the 26 January draft for a couple of reasons: a) The WG was not aware of blinking images on the Web. b) Even if they are on the Web, checkpoint 3.2 (animated images) seems to cover the requirement sufficiently. </IJ2> <GL> It might be worthwhile modifying the definition of 'placeholder' to include the example of using the first significant frame of an animated image as the placeholder for the animated image. </GL> <IJ2> IJ-proposed: I agree with the proposal. </IJ2> --------------- New Issue Regarding checkpoint 10.3: <GL> Instead of "The highlight mechanism must not rely on color alone," it would be more accurate to say, "One or more highlight options must be provided that do not rely on color alone." The current wording could be interpreted as meaning that the user must not be allowed to select a highlighting option which relies solely on color. </GL> <IJ2> The checkpoints are written to make minimal requirements. This checkpoint only requires one mechanism, in which case it must not rely on color alone. The user agent may always implement more than one mechanism. We do use the "at least" formulation in other checkpoints. I have no objection to making the suggested editorial change. </IJ2> ================================================ Substantive disagreement with no new information ================================================ --------------- Issue 396 (Second Last Call): New requirement: Allow user to override absolute values <IJ> The Working Group resolved not to include general resizing requirements in UAAG 1.0 (though there are requirements for resizing text). This is now clearly listed as one of the limitations of UAAG 1.0 (refer to section 1.3 of the document). Some specifications (e.g., SVG) will allow for resizing as part of conformance to those specifications. </IJ> <GL> I do not believe this is necessarily difficult to solve, at least in specific cases such as absolute sizes of elements. I consider this a very major deficiency in the guidelines. </GL> <IJ2> We did not have a technical reason for not adding this requirement. We simply decided to stop adding requirements to the document after a certain point (so that we would someday finish...). </IJ2> --------------- Issue 403 (Second Last Call): Checkpoint 4.12: Need to require override of author-specified speeds. <IJ> We did not add this requirement (for user control of author-supplied rate changes) for the following reasons: 1) If speech engine allows user override, that's the speech engine's functionality, not the UA's. 2) We don't require content transformations to strip out author-supplied rate changes before sending to the speech engine. </IJ> <GL> I can live with this, but I disagree with it. As for reason #1, certainly the UA would not be required to support speech rates outside the range supported by the speech engine. However, they should support the full range of rates supported by the engine. That is definitely UA functionality. As for #2, *why* don't you require UA to strip out, or replace, author-supplied rate changes before sending to the speech engine when the speech rate is specified using a standard markup? This seems easy enough to do. Are there other factors you are not mentioning? </GL> <IJ2> @@ Point 1: Point 2: </IJ2> --------------- Issue 415 (Second Last Call): Definition of active element: too broad (checkpoint 7.4) <IJ> There have been a number of changes related to the term "active element". In fact, the term has been deleted from the document and replaced with other terms (with clearer entries in the glossary): * Interactive element * Enabled element. Furthermore, the definition of "enabled element" states: "For the requirements of this document, user selection does not constitute user interaction with enabled elements." </IJ> <GL> I'm still confused. The definition says "An enabled element is a piece of content that is subject to user activation through the user interface or indirectly through an API. The set of elements that a user agent enables is generally derived from, but is not limited to, the set of interactive elements defined by implemented markup languages." There are two problems with this. The first problem is that the first sentence defines 'enabled element' in terms of 'activation', but the latter term is defined as "To trigger one or more behaviors associated with an enabled element." Term 1 is defined by referring to term 2, and term 2 is defined by referring to term 1, and thus we have a cyclical definition. The second problem is similar. 'Enabled elements' are said to be a superset of 'interactive elements defined by implemented markup languages,' but an 'interactive element' is defined as a 'piece of content that is intended, by specification, to be an enabled element in some user sessions.' Thus, enabled elements are said to be a superset of all elements that are intended to be able to be enabled elements. I guess the additional enabled elements that are not interactive elements must be things that the UA makes enabled *against* the intentions of the specification language. Sounds suspicious to me. </GL> <IJ2> I will work to clear up the definitions. I think the first problem can be cleared up by changing the definition of enabled element to (something like): "Enabled element: A piece of content with associated behaviors that may be activated through the UI or through an API" "Activate: To trigger the behaviors associated with either an enabled element or a user interface control." Note addition (and distinction) of UI control. </IJ2> --------------- Issue 435 (Second Last Call): Checkpoint 4.14: Is this for content only or UI as well? <IJ> Content only. There has been no change to the document. However, based on my comments for issue #413, I think additional clarification may be required. </IJ> <GL> Please clarify why the user should not have control over attributes of synthesized speech used as part of the UA's UI. </GL> <IJ2> No technical reason, only that the WG chose not to generalize our content requirements to the user interface (I can't locate the resolution right now, but could if pressed). Instead, we resolved to add the following to the (Techniques) document: "Much of the rationale behind the content requirements of User Agent Accessibility Guidelines 1.0 also makes sense for the user agent user interface (e.g., allow the user to turn off any blinking or moving user interface components)." </IJ2> --------------- Issue 440 (Second Last Call): Checkpoint 7.5: Should min reqs be moved to techniques? <IJ> The Working Group believes that the details of the required search functionality (now checkpoint 9.8) are minimal requirements, and thus belong in the checkpoint. </IJ> <GL> (1) OK to leave, although I think it is too detailed and specific. </GL> <IJ2> This is the list of search requirements the WG considered "essential". </IJ2> <GL> (2) Should add the option or mechanism to start search from the beginning of the document rather than from the current selection or focus. There is no easy way to do this in IE today. Or is there already a requirement to provide an easy way to move the "focus" or start of search to the beginning or end of the document. (3) Should provide distinct alerts for the three situations listed; the user should be able to easily tell whether they have searched all the content, or whether they merely reached the end of the document and now need to wrap to the beginning. (4) There are a lot of additional variations that could be included as priority 3. For example, should add the ability to search backwards through content, possibly as a priority 3 checkpoint. That is part of forgiveness, allowing the user to avoid having to start over if they accidentally go one search too far. (5) If the user has not indicated a start position for the search, the search should start from the beginning of that portion in the viewport (as far as the user agent is concerned-it does not have to deal with whether portions of its window is obscured by other applications or operating systems windows). (6) Should ideally provide the option of searching through alternative representations (such as ALT text) and source (e.g. you know the page was found by a search engine looking for a specific term, but normal search cannot find it, it would be nice to have it inform you that it found the text in metadata or other non-rendered portions of the source. This would be lower priority. </GL> <IJ2> All of this should go in the Techniques document. </IJ2> --------------- Issue 441 (Second Last Call): New requirement (part of 8.5): Add information about the resource being at the same or a different domain. <IJ> This was not added. However, there is a requirement to provide information about whether the link is internal to the same resource. </IJ> <GL> I disagree with this decision but can live with it. <GL> <IJ2> Ok. </IJ2> ============================================== Editorial disagreement with no new information ============================================== --------------- Issue 389 (Second Last Call): Conformance: Hard to test conformance in an objective fashion. <IJ> We've done a lot to improve the document in terms of conformance since the last call draft, including the following: a) Introduction of content type labels and input modality labels to allow greater flexibility in conformance. b) Clarifying checkpoints (notably those of Guideline 1). However, as you recall from our 25 January 2001 discussion [4] you maintained your concern that the Guidelines are not technology-specific, making it difficult to objectively measure conformance. We will take these comments to the Director, but for now we have left the Guidelines (and conformance scheme) technology-independent, as was the case for WCAG 1.0 and ATAG 1.0. </IJ> <GL> I am still concerned that there may be places where the Note text adds details that apparently will be taken as a legally binding extension to the checkpoint wording itself, and how examples given in Techniques can confuse things by not distinguishing examples from recommendations. However, I'll have to see if I can find an example. </GL> --------------- Issue 438 (Second Last Call): Checkpoint 7.3: For some devices, is direct navigation of active elements sufficient? <IJ> This has been clarified because the checkpoints of what is now Guideline 9 have been made much more specific to the content focus (whatever input devices are used to control the content focus). There are no requirements in the document for direct navigation through a pointing device, but if the user agent allows the user to move the focus with the pointing device, the desired functionality is achieved. </IJ> <GL> (1) I can live with this; I understand the reason for it, but I still feel that you're heaping so many expectations on the UA that none will ever conform to this level. That is to say, no UA will conform with respect to pointing devices. (2) Where it says "The user agent may also include disabled elements in the navigation order," the key factor is that the user should be able to move only to active elements. The ability to move to inactive elements can be a user-controllable option, but should not be unalterable behavior. </GL> <IJ2> Unless I have misunderstood the comment, your requirement is covered at a P2 level by checkpoint 9.7. Note that it was considered a P1 requirement to get to the enabled elements at all (with possibly other elements in between), and a P2 requirement to get to them without "interruption" by disabled elements. </IJ2> ========= Agreement ========= --------------- Issue 392 (Second Last Call): Checkpoint 1.4: Overly broad <IJ> This is a conformance issue: a claim of conformance may include any number of software components. Therefore, a user agent alone might not satisfy one of the requirements, but the user agent in conjunction with another piece of software (e.g., an on-screen keyboard that comes with the OS) might. There is no longer a notion of "what is the responsibility of the user agent, the operating system, and third-party accessibility aids"; there are simply requirements that must be met, by whatever means the claimant has available. </IJ> <GL> The new wording is fine. However, I'm worried about this approach whitewashing the difference between a UA that is designed to be accessible, and one that uses inaccessible design but has at least one dedicated third-party vendor who creates a hack solution. I believe we owe it to customers trying to make purchasing decisions to help clarify this, and we also owe it to customers who want a wide range of AT products for use with their UA. </GL> <IJ2> I think our conformance claim requirements will help inform consumers. I do not have other suggestions at this time. </IJ2> --------------- Issue 398 (Second Last Call): Checkpoint 4.5 (4.6, 4.8, 4.9): Need definition of "not recognized as style" <IJ> There were two changes to the document: a) The following statement in checkpoint 4.4 et al. is clearer: "The user agent is not required to satisfy this checkpoint for audio and animations whose recognized role is to create a purely stylistic effect." b) The Note of checkpoint 4.4 states: "Note: Purely stylistic effects include background sounds, decorative animated images, and effects caused by style sheets. The style exception of this checkpoint is based on the assumption that authors have satisfied the requirements of the "Web Content Accessibility Guidelines 1.0" [WCAG10] not to convey information through style alone (e.g., through color alone or style sheets alone)." </IJ> <GL> Acceptable, but I'm not wholly comfortable with saying that the UA can avoid making accessible anything that is authored in a way that is supposed to be reserved for purely stylistic touches, because we all know that authors abuse these mechanisms. </GL> <IJ2> We have acknowledged the potential for abuse by authors, but we explicitly excluded this repair for this checkpoint. </IJ2> <GL> In many cases authors will convey information using background sounds or sounds specified in style sheets, and it would be to the user's benefit to be able to have access to and control over those sounds. </GL> <IJ2> (Checkpoints 4.7 and 4.8 address this at a P2 level.) </IJ2> --------------- Issue 400 (Second Last Call): Checkpoint 4.11: Why limited to sources synchronized to play simultanously? <IJ> The answer is that the requirement for independent volume control is not necessary when sources of audio may be played one after the other. In that case, global control suffices (another checkpoint). Thus, this is an expression of the minimal functional requirement. We added a Note to checkpoint 4.10: "Note: Sounds that play at different times are distinguishable and therefore independent control of their volumes is not part of this checkpoint (volume control per checkpoint 4.9 suffices). The user agent may satisfy this checkpoint by allowing the user to control independently the volumes of all distinct audio sources. The user control required by this checkpoint includes the ability to override author-specified volumes for the relevant sources of audio." </IJ> <GL> Acceptable. However, note that there are at least three good reasons for strongly recommending that all sounds are independently configurable: (1) sounds which are not synchronized may end up playing simultaneously, and (2) if the user cannot anticipate when a sound will play they cannot adjust the global volume control at appropriate times to affect this sound, and (3) it is extremely inconvenient for the user to have to frequently adjust global volume to accommodate sounds about to be played, especially when this leads them to frequently switch back and forth between different volume settings. Therefore I would recommend making this a separate Pri 3 checkpoint. </GL> <IJ2> What if, instead, we strengthen the Note after 4.10. Change "may" to "should" in: "The user agent may satisfy this checkpoint by allowing the user to control independently the volumes of all distinct audio sources. I am not very much in favor of adding checkpoints at this time. I would like to include your rationale in the Techniques document for 4.10 in any case. </IJ2> --------------- Issue 406 (Second Last Call): Checkpoint 4.18: Lower to Priority 3 <IJ> The Working Group felt that the orientation problems were significant enough that this checkpoint (now 5.1) should remain a priority 2 checkpoint. </IJ> <GL> I disagree, but I can live with it. However, you should then add a requirement that says the UA must notify the user when opening or closing viewports, when that is not the direct result of explicit user request. After all, it is worse for the UA to open a new window and not tell the user than it is to open a window and move focus to it. </GL> <IJ2> I believe that both of those requirements are already covered in the document: For notification (in fact, prompting) before opening, checkpoint 5.3. For notification (in fact, prompting) before closing, checkpoint 5.6. (In both cases, when not on explicit user request). </IJ2> --------------- Issue 407 (Second Last Call): Checkpoint 4.20: Include requirement to control automatic closing of viewports <IJ> This is now checkpoint 5.6 (Priority 3). </IJ> <GL> Fine. But is there a checkpoint that recommends UA use standard system notification or alert mechanisms when doing things like closing viewports? </GL> <IJ2> That is covered (P2 level) by checkpoint 7.3: 7.3 Follow operating environment conventions that benefit accessibility. IJ-proposal: Change "that benefit accessibility" to "that do not interfere with accessibility". [I make this proposal only for checkpoint 7.3 and not for checkpoints in Guideline 12.] </IJ2> --------------- Issue 413 (Second Last Call): Checkpoint 6.2: Does this only apply to content? <IJ> Yes, this applies only to content. There has been no change to the document because it was considered that the label in the document "Checkpoints for content" was sufficient, but given other changes to the document subsequently, I think this requires an additional (editorial) clarification to the checkpoint. (I will write a proposal to the Working Group.) </IJ> <GL> I'll wait to see your proposed modifications, but I strongly favor writing all checkpoints so that their meanings are not significantly changed when quoted out of context. I consider relying on headings outside the checkpoint itself to be dangerous, even if the headings are present in every guidelines document and summary published by the W3C, because they will be quoted out of context on occasion. </GL> <IJ2> This is done as of the 23 March 2001 draft: we have labels in each checkpoint. IJ-proposal: I think the label for 10.2 should read "For content only" instead of "For content and user agent". This is because the highlight styles for selection, content focus, etc. only refer to interacting styles within content. It is possible to have selection and focus in the UI, but that's not what this checkpoint is intending to address. I consider this editorial and will fix it. </IJ2> --------------- Issue 424 (Second Last Call): Checkpoint 9.3: Do author-specified shortcuts include active elements that take mouse input? <IJ> Bindings accomplished through scripting are not part of the requirements of this document. This is covered by our "applicability" provision in general. Furthermore, the following statement has been added to section 3.2 of the document (as an example of when one would consider applicability): "Some input device behavior may be controlled by scripts in a manner that the user agent cannot recognize." </IJ> <GL> I disagree with this resolution. In many cases the UA knows when an object handles different types of input events. For example, with javascript the UA knows if the script declares a handler for onClick events. Thus, it is entirely reasonable for it to provide keyboard mechanisms for putting focus on and simulating mouse input to these elements. </GL> <IJ2> Actually, I think we are in agreement, but I expressed the resolution incorrectly. Just because something is in a script doesn't exclude it from the requirements of the document. It is more likely that knowledge embedded in scripts will be harder for the user agent to recognize. However, it is not impossible, and there are many things done in scripts (e.g., opening a viewport) where the user agent knows very well what is about to happen. The case you site is an example of what the user agent should recognize. Therefore, I think our document already reflects your expectation. </IJ2> -- Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783
Received on Thursday, 29 March 2001 15:23:03 UTC