- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 10 Aug 2000 04:51:20 -0400
- To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
- Cc: "Hansen, Eric" <ehansen@ets.org>
Date: 9 August 2000 To: UAAG List From: Eric Hansen Re: "Checkpoint applicability", "Native support", etc. I would like to propose some clarifications, particularly in the areas of "Checkpoint applicability" and "Native support". PR#294: Native support and downloadable modules http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#294 PR#309: Applicability needs review: how to tell when checkpoint MUST be followed. http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#309 I believe that the problems can be corrected as shown below with very little change to checkpoints. ==== Suggestion 1: Simplify the section on Applicability. I think that the section on "Checkpoint applicability" in UAAG 28 July 2000 confuses rather enlightens. I think that it will tend to scare people into thinking that the checkpoints themselves are not complete because the section implies that in order to properly "apply" the correct checkpoints they need deep understanding of these complex cases. I think that the cases are not only overly complex but are irrelevant and perhaps misleading. In a sense, I think that people may be put off by lack of clarity of the Applicability section. For example, they may wonder if the lack of clarity was a way of inhibiting people from availing themselves of legitimate waivers from checkpoint requirements. I believe that the entire Applicability section can be considerably reduced and simplified. (The old Applicability section is included in the Appendix for this memo.) The following is my revision. New: "Checkpoint applicability" "The goal of the checkpoint applicability rules is to ensure that developers of user agents are required to adhere to only those checkpoints that are _necessary_ to ensure that individuals with disabilities have, to the extent possible, equivalent access to user agent capabilities that are enjoyed by people without any disability. Those capabilities (functionality and information) for people without any disability must be made available to people _with_ disabilities either directly or indirectly, through alternative means. "The main applicability rule, informally stated, is that a checkpoint is _applicable_ to a user agent if the checkpoint requires capabilities that the developer of the user agent _intends_ for users _without_ any disability. (This does not mean that the developer of the user agent intends the capability _exclusively_ for people without any disability, but rather that these are a set of capabilities that are sufficient to allow a user without any disability to obtain the full benefit of the user agent.) It is expected that for most, if not all, general-purpose graphical Web browsers, virtually all checkpoints will be applicable since most of their capabilities are intended for general audiences, a substantial portion of which have no disability. The rationale for this rule, as noted above, is that the checkpoints require functionality and information that will help ensure that individuals with disabilities have access to the essentially the same capabilities (directly or indirectly) as are provided to individuals _without_ any disability. "An applicability rule that supports the main rule is that any capability "provided" or "offered" by the user agent is assumed to be "intended" for the user _without_ any disability unless documentation justifies the claim that it not merely as an accessibility feature but that it is a capability intended _specifically_ [Note: I think that the word "exclusively" is too stringent in this context.] for users _with_ disabilities." [Note: This rule is designed to prevent cases in which one might improperly claim that virtually all capabilities are intended for people with disabilities and that therefore no checkpoints are applicable.] "A more formal statement of the main applicability rule is that a checkpoint is applicable if it requires capabilities that are intended for users without any disability who using the user agent under near-ideal conditions. Some of the near-ideal conditions for general-purpose graphical user agents would include conditions such as the presence of a desktop computer with color monitor, stereo speakers, keyboard, mouse, moderately quiet room. Furthermore, other conditions would include quick and compatible communications with any necessary assistive technologies. This document does not attempt to anticipate the full range of conditions that would be near-ideal for the diversity of user agents. However, it is likely that these same conditions of "quick and compatible communications with any necessary assistive technologies" would likely be relevant for a wide variety of user agents. "One implication of the main rule is that a checkpoint is not applicable if it refers solely to capabilities that, in a given user agent, are exclusively for people _with_ disabilities. "An obvious but extremely important implication of this applicability rule is that a checkpoint is "not applicable" if is refers exclusively to capabilities that are _not offered by the user agent at all_. "See the Techniques document for further examples. [Optional]" Comment 1: You will notice that in a relatively short amount of prose I attempt to not only tell what the rules are but also to explain the rationale and implications. Perhaps what I have written is longer than it need be, partly because I am trying to _justify_ the change (to you-all!) and well as _make_ the change. Comment 2: I use the term "capabilities" as encompassing both "content" and "functionality". I think that we mean both content (i.e., information) and functionality so I think that we need this overarching term. Comment 3: If we have concerns about letting developers of assistive technologies "off the hook" remember that: (a) our document is optimized for and intended primarily for "general-graphical graphical Web browsers" so it natural and appropriate that some checkpoints not apply to special-purpose user agents specifically for people with disabilities (b) there is plenty of work that needs to be done to make special-purpose user agents, e.g., mathematics on the Web for people who are blind, etc., that we don't need to burden developers of such user agents with additional accessibility requirements. Comment 4: More detail on the concept of standard conditions is found at: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html ==== Suggestion 2: Remove or delete the summary examples from "Checkpoint applicability". I think that the summary examples as well as the sentence following the examples should be deleted or removed. Possibly some version might be warranted for the Techniques. Following are justifications for this suggestion. Each point is followed by my comments. "To summarize, a checkpoint (or portion of a checkpoint) applies to a user agent unless at least one of the following is true:" #1. "It refers solely to an unsupported input or output device interface. Note that if the device interface is supported at all, it must be supported accessibly for all functionalities of the user agent (and not just a subset of functionalities)." My comment: Not necessary. The capability is not offered to anyone. Furthermore, the second sentence ("Note that..."), if relevant, would belong in the checkpoints, not in this section. #2. "It includes requirements about the purpose of content (e.g., transcript, caption, text equivalent, etc.) that the user agent cannot recognize through markup. For instance, HTML user agents can recognize "alt", OBJECT content, or NOFRAMES content as providing equivalents for other content since these are specified by the markup language. HTML user agents are not expected to recognize that an image description embedded in a paragraph is a text equivalent for the image." My comment: Not necessary. The capability is not offered to anyone. The statement about not needing to recognize a text equivalent that is embedded in a paragraph, if relevant, belongs in a checkpoint. I am not sure that we need to say that anywhere since the only equivalents that the user agent can recognize are those that are marked by the author as such. I have argue in another context that even if the actual text equivalent is embedded in primary content, it should still be addressable. If necessary, some of the material might belong in Techniques. #3. "It includes requirements about a content type (script, image, video, sound, applet, etc.) that the user agent either does not recognize or recognizes but does not support natively." My comment: Not necessary. The capability for such recognition is not offered to anyone. See later suggestion about the term "natively". #4. "It requires control of properties of an embedded object (e.g., video or animation rate) that may not be controlled or accessed by the user agent." My comment: Not necessary. The capability is not offered to anyone. #5. "It refers to unsupported technologies that are not required by this document. For instance, all conforming user agents are required to support the W3C Document Object Model [DOM2]. However, user agents are not required to support a synchronized multimedia markup language such as SMIL 1.0 [SMIL]. If they do, the checkpoints that refer to synchronized multimedia apply." My comment: Not necessary. This point seems to have several problems. (1) Regarding the first sentence, the _checkpoints themselves_ should make crystal clear which technologies are "required" and which ones are not so there is no need to finesse the issue here. (2) I think that the last two sentences about SMIL are already covered by checkpoint 6.1, which seems clear enough. ("6.1 Implement the accessibility features of all supported specifications (markup languages, style sheet languages, metadata languages, graphics formats, etc.)"). If we want to underscore the fact that when we say "supported" we do not necessarily mean "required" then that can be stated in a notes attached to the relevant checkpoints. (3) I do not understand why the word "unsupported" appears in the first sentence; isn't it reason enough for an exclusion that the technology is "not required" (later in that sentence). In summary, I think that this point is very confusing. #6. "It refers to communication with other software but no communication is possible on the system housing the user agent (e.g., a kiosk with no infrared port for communication with assistive technologies)." My comment: Not necessary. Having this point here seems to be very misleading. The UAAG guidelines document is about software -- not hardware! All the general-purpose graphical Web browsers that I know about are software. I think that it really confuses things to even mention hardware like kiosks. #7. (This is the closing sentence). "Each checkpoint requirement must be satisfied by making information or functionalities available through the user agent's user interface unless the checkpoint explicitly states that the requirement must be met by making information available through an Application Programming Interface (API)." My comment: Not necessary. I think that relevant checkpoints are quite explicit about how they must make information available (API versus user interface). This point will scare people into thinking that the checkpoints themselves are not explicit about what they intend. ==== Suggestion 3: Mention applicability, at least "softly", in the Abstract. I think that a good first step to clarifying the role of "applicability" in the guidelines is by invoking the concept of "applicability" in the Abstract (and any other relevant locations). Old (UAAG 28 July 2000): "Abstract "The guidelines in this document explain to developers how to design user agents that are accessible to people with disabilities. User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers, plug-ins, and other assistive technologies that provide access to Web content. While these guidelines primarily address the accessibility of general-purpose graphical user agents, the principles presented apply to other types of user agents as well. Following these principles will help make the Web accessible to users with disabilities and will benefit all users." New: "Abstract "The guidelines in this document explain to developers how to design 'user agents' (technologies that provide access to Web content) that are accessible to people with disabilities. Virtually all requirements of this document apply [or "are applicable"] to general-purpose graphical desktop browsers. Many of the requirements also apply to other user agents, such as text browsers, voice browsers, multimedia players, and other technologies that provide access to Web content. Following the principles presented in this document will help make the Web accessible to users with disabilities and will benefit all users." Comment 1: The revised material defines the term "user agent" in first sentence. The term is so general and largely unknown that I think it needs to be defined right at the start. Comment 2: Hopefully it is true that all or "virtually all" requirements _do_ apply to general-purpose graphical desktop Web browsers. If they don't, then there may be a problem with the document. Comment 3: The revised version does not say "assistive technologies"; it just says "technologies". The term "assistive technologies" may cause readers to incorrectly infer that the UAAG is about hardware, which it is not. Furthermore, "assistive technologies" may be seen as partially overlapping with "voice browsers" and "text browsers", which could add confusion. ==== Suggestion 4: Seriously consider removing all references to the term "natively". I think that there is no reason to refer to the concept of "natively" in the document. The term rightly does not appear in any checkpoint. I think that the word natively is a "leftover" from a time when it was not clear whether we were considering each user agent _in isolation_ or with other user agents. We determined (rightly, I think) that we needed to consider each user agent in isolation. To focus people's attention on the term is confusing and unnecessary. ==== Suggestion 5: Seriously consider giving explicit permission to create a single user agent out of more than one user agent. Actually, I see no reason why developer, if she or he desires, should not treat two or more cooperating user agents (i.e., a general-purpose graphical user agent plus a multimedia player plus some special-purpose disability-access user agent, etc.) as a single user agent. First of all, this is the way it happens in real life; for example, MS Internet Explorers uses lots of special purpose plug-ins. Second, this would encourage cooperation between developers on disability access issues. It might be possible, for example, for two user agents, one or more of which is non-compliant when analyzed singly, but together constitute a "super" user agent that is compliant. Such a possibility would encourage cooperation between developers of user agents. Third, this would encourage involvement by lots of developers of special-purpose user agents (assistive technologies). Without this change, they may feel left out because they do not address all disabilities or because few checkpoints are applicable to them. But if they can cooperate with other user agents to form a combined "super" user agent, then they can join the party. It would be a win-win situation. I suppose that one could not say anything about this issue in this document and leave it up to others to decide if they want to allow it. Nevertheless, my feeling is that it makes a lot of sense and if others agree, then we should explicitly allow it in the document. ==== Suggestion 6: Add a checkpoint or so about easy installation for people with disabilities. We should consider adding a checkpoint or so that requires easy installation of user agent software for people with disabilities. It occurred to me that this is missing, but it becomes especially important when we consider allowing people to analyze multiple user agents as a single one. I have further thoughts but will not write them now. I would be happy to discuss. ==== Suggestion 7: Remove the reference to "assistive technologies" in checkpoint 1.5. I think that "assistive technologies" (and its variations) need not and must not appear in checkpoint 1.5 (i.e., the normative part) or any other checkpoint. One reason is that people may incorrectly assume that because the checkpoint refers to requirements that are exclusively for people with disabilities, such as those relating to "assistive technologies", that the checkpoint is somehow not applicable. Fortunately, it appears checkpoint 1.5 is the only checkpoint that uses that term and it is in no way essential. In my opinion, this checkpoint also has other problems, such as misuse of the term of the term "text equivalent". Let us consider basic fix. Old (UAAG 28 July 2000): "1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.) that is part of the user agent's user interface also has a text equivalent in the user interface. This text equivalent must be available to assistive technologies through an API. [Priority 1]" Partial Fix 1: "1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.) that is part of the user agent's user interface also has a text equivalent available in the user interface. [Priority 1]" Comment 1: There are already checkpoints that ensure that the text equivalents will be available through the interface (e.g., checkpoints 2.1, 2.2, and 2.4) and checkpoint 1.1 ensures that what is available through the user interface is also available through API. So that second sentence -- the one that refers to assistive technology -- is completely unnecessary. Comment 2: As noted above, other fixes are also needed. One problem is that it misuses the term "text equivalent". We can correct part of the problem as follows: Partial Fix 2: "1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.) that is part of the user agent's user interface also has a text equivalent. [Priority 1]" I removed the last part of the sentence because a text equivalent is "pre-rendering content" so it usually doesn't make sense to talk about "text equivalent available in the user interface". I wonder if what was really meant was to emphasize that visual messages should have an auditory equivalent and auditory messages should have a visual equivalent. I suppose that there may have been a desire to emphasize this in the UAAG document since some of these messages seem to be generated by the user agent itself or the operating system than by the Web content itself. Unless someone can explain the intention of the checkpoint, I think that this checkpoint is not necessary at all since it is adequately covered by other checkpoints. Therefore I suggest deleting it. Even if it is not deleted, I strongly urge removal of reference to assistive technologies. ==== Suggestion 7: Keep mention of "compatibility and quick communication with assistive technology" out of any checkpoint. This is not actually a problem at this time since, I don't think that they are mentioned in checkpoints. This is more for future reference. "[C]ompatibility and quick communication with assistive technology" are part of the "near-ideal conditions" (that I think are more properly called "standard conditions") and therefore should not be found in any checkpoint. These are things that are and should remain outside the scope of the checkpoints themselves. ==== Appendix: Old (UAAG 28 July 2000) Section on Applicability: Checkpoint applicability Not every checkpoint or guideline is applicable to every user agent. Generally, a user agent must adhere to checkpoints that ensure accessibility of functionalities that it offers to users and it must implement required functionalities natively. If the user agent supports keyboard input, it must support accessible keyboard input. If the user agent supports images, it must ensure access to each image or an equivalent alternative specified by the author. If a user agent supports style sheets, it must implement the accessibility features of the style sheet language. If the user agent supports frames, it must ensure access to frame alternatives specified by the author. In short, if a user agent offers a functionality, it must ensure that people with disabilities have access to that functionality or an equivalent alternative. Not all user agents support every content type, markup language feature, input or output device interface, etc. When a content type, feature, or device interface is not supported, checkpoints with requirements related to it do not apply to the user agent. Thus, if a user agent supports style sheets at all, all checkpoints related to style sheet accessibility apply. If a user agent does not support style sheets at all, the checkpoints do not apply. The applicability of checkpoints related to markup language features is determined similarly. If a user agent supports tables, it must support the accessibility features of the language related to tables (and so on, for images, frames, video, links, etc.). The Techniques document includes information about the accessibility features of W3C languages such as HTML, CSS, and SMIL. To summarize, a checkpoint (or portion of a checkpoint) applies to a user agent unless at least one of the following is true: · It refers solely to an unsupported input or output device interface. Note that if the device interface is supported at all, it must be supported accessibly for all functionalities of the user agent (and not just a subset of functionalities). · It includes requirements about the purpose of content (e.g., transcript, caption, text equivalent, etc.) that the user agent cannot recognize through markup. For instance, HTML user agents can recognize "alt", OBJECT content, or NOFRAMES content as providing equivalents for other content since these are specified by the markup language. HTML user agents are not expected to recognize that an image description embedded in a paragraph is a text equivalent for the image. · It includes requirements about a content type (script, image, video, sound, applet, etc.) that the user agent either does not recognize or recognizes but does not support natively. · It requires control of properties of an embedded object (e.g., video or animation rate) that may not be controlled or accessed by the user agent. · It refers to unsupported technologies that are not required by this document. For instance, all conforming user agents are required to support the W3C Document Object Model [DOM2]. However, user agents are not required to support a synchronized multimedia markup language such as SMIL 1.0 [SMIL]. If they do, the checkpoints that refer to synchronized multimedia apply. · It refers to communication with other software but no communication is possible on the system housing the user agent (e.g., a kiosk with no infrared port for communication with assistive technologies) Each checkpoint requirement must be satisfied by making information or functionalities available through the user agent's user interface unless the checkpoint explicitly states that the requirement must be met by making information available through an Application Programming Interface (API). <END OF MEMO> =========================== Eric G. Hansen, Ph.D. Development Scientist Educational Testing Service ETS 12-R Princeton, NJ 08541 609-734-5615 (Voice) E-mail: ehansen@ets.org (W) 609-734-5615 (Voice) FAX 609-734-1090
Received on Thursday, 10 August 2000 04:51:29 UTC