- From: Hansen, Eric <ehansen@ets.org>
- Date: Wed, 23 Aug 2000 17:44:59 -0400
- To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
I think that Ian's analysis [5] will be very helpful in resolving this issue of applicability. A Misunderstanding At the outset I believe that I need to point out that Ian's memo [5] reflects a fundamental misunderstanding about my earlier suggestion [3]. Hence, I will try to state more clearly what I meant. In that memo, Ian says: > My hope in doing this analysis was that I would > conclude that applicability was not necessary and > could be removed from the document. This was Eric's > conclusion [3], though his conclusion is based on > the premise 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." I haven't been able to > agree with that starting point since there are some > requirements that are principally about features for > users with disabilities (e.g., captions) and others > that are required whether or not the developer intended > them for users without disabilities (e.g., DOM support). Ian's characterization of my proposed applicability rule is based on an informal (and hence incomplete) statement of my proposed applicability rule. Furthermore, I don't think that his memo reflects an understanding of my usage of the term "capability." Specifically, Ian quotes a sentence from [3] that said: "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." But a more formal statement of the rule is needed. In my memo [3], it says: "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." Ian's memo does not reflect (a) the idea that a "capability" may include both functionality and content nor (b) the idea that a capability can be met in more than one way. In essence, the intention behind my applicability rule is that a checkpoint is applicable unless it fails to contribute to the goal of equal access. Equal access (and this is my own characterization) means that the same capabilities provided to people without disabilities are also provided to people with disabilities. (The word "benefit" may be a good synonym for "capability".) Those capabilities for people with disabilities can be provided directly, via primary content and primary functionality, or indirectly, via secondary content and secondary functionality. Where the design goal of 'universal design' has for the most part been successfully met, the primary content and primary functionality will be directly accessible to people with disabilities (as well as to people without any disability) and the need for secondary content and secondary functionality will be relatively limited. The rule is intended to be considerate to developers of Web content and developers of user agents by not requiring, at least at the Priority 1 level, capabilities that are not provided to people without disabilities. One by-product of this rule that it prevents iterative development loops by preventing requirements for "alternatives for alternatives". This rule, for example, if applied in the context of Web content development means that one is not required to provide equivalents for secondary content, (e.g., captions, auditory descriptions, collated text transcripts for sign language videos where the videos themselves are secondary content). In other words, if the author of the sign language videos intends that the videos are only for people who are deaf, then the rule would mean that they are not required to develop equivalents for it. In the context of the UAAG, this rule might mean that if for some user agent, the DOM (or any other capability required by a checkpoint) were used only to present such unnecessary content (e.g., unnecessary equivalents) or unnecessary functionality, then that checkpoint could be inapplicable. I think that it is worth emphasizing that the applicability section is not the only place to apply these notions of equal access. Indeed, if they were built into the checkpoints themselves, for example, then there would be little if any need for them in the applicability section. An examination of the memo [3] show that my suggestion for radical simplification of the applicability section was based on an assumption that (a) the document is targeted at general-graphical purpose graphical Web browsers, and (b) that the notions of primary content and primary functionality are tied to "standard conditions" that happen to be appropriate for general purpose graphical Web browsers. Comparison of My Proposal and Ian's Current Proposal Both my proposal and Ian's approach are dealing with some of the same variations in user agent situation but are dealing with them through different mechanisms. I have addressed that variation by dealing with most if not all them by (a) focusing on a much narrower set of user agents (e.g., general-purpose graphical user agent), (b) standard conditions, and (c) by adding one or more checkpoints that require capabilities for presenting certain media types (text, graphics, animation, video, audio). This approach virtually eliminated the need for an applicability rule. Indeed, virtually the only reason for my one applicability to "kick in" would be if some key checkpoints are suboptimally phrased (i.e., such as by ignoring distinctions between primary/second content/functionality where they would be useful). As I have stated elsewhere, I like the idea of allowing very few inapplicable checkpoints. Ian, on the other hand, intends the document to be used for a wider range of user agent types and therefore has a greater need for applicability rules. Issues that form the core of Ian's section on applicability (1. Unsupported content type, 2. Unsupported content role, 3. Unsupported rendering type, 4. Urecognized or uncontrollable properties) would under my proposal be handled mostly by my focus on a single kind of user agent and by providing assumptions (i.e., standard conditions) that specify the basic content types, content roles, rendering types, etc., that should be handled by a general-purpose graphical user agent with multimedia capabilities. Ian's approach allows some kind of analysis a wider range of different kinds of user whereas my approach focuses on one kind of user agent. Ian's approach is more _descriptive_ and my approach is more _prescriptive_. For example, Ian's approach doesn't try to say what media types a user agent should or must provide and whereas mine does. Ian's approach allows the meanings of "conformance" and "accessibility" to diverge more than does my approach. Under my approach, differences in conformance rating translate more readily to real differences in accessibility and in Ian's approach, differences in conformance rating only translate into real differences in accessibility if additional conditions are met (e.g., not too many inapplicable checkpoints, comparison is between user agents of the same type, etc.). I think that one of the chief advantages of my approach is that it aligns the concepts of "conformance" and "accessibility". It also has the advantage of eliminating more of the applicability section. I think that the chief advantage of Ian's approach has the advantage of being more in keeping with the historical vision for the UAAG document as something intended for a wide variety of user agents. A Peek at My Revised Standard Conditions I think that it would be useful to say briefly again what might be appropriate "standard conditions" that would allow the applicability section to be virtually eliminated. This assumes that the focus of the document is on "general-purpose graphical user agents with basic multimedia capabilities". 1. A color visual display monitor about 14 to 17 inches diagonal measurement. 2. Visual display capabilities capable of presenting text, graphics, animation, and motion video. 3. Stereo two speakers for output capable of outputting prerecorded audio, synthesized speech, and system sounds. 4. A pointing device (e.g., mouse) and keyboard for input. 5. Quick response time for accessing information both from local storage devices and via the Internet. 6. System operation by one person at a time seated in front of the display monitor. 7. Moderately quiet room. 8. Moderately good room illumination. 9. Unlimited time per session, though usually measured in minutes or hours. 10. Computer properly handles WIMP [spell out] interface Note 1. By the way, as I have indicated before, a checkpoint requiring text, graphics, animation, and motion video capabilities would be a valuable complement to Condition 2.) Note 2. See http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html for my older version of standard conditions. (I have eliminated reference to compatibility to assistive technologies since I have been assured that existing checkpoints handle that as well as it can be done at this time.) Note 3. An assumption underlying this approach is that primary content (content for people without any disability) can be adequately presented via visual and auditory means and does not require other means. The importance of this assumption under my approach is actually lower than it is for the current approach of the UAAG document. Note 4. The more detailed one makes these standard conditions, the more one is potentially able to reduce the number of checkpoints that could be inapplicable. Conclusion I think that Ian's approach and mine are essentially different strategies meeting a similar goal. However, his strategy is more in keeping with the approach that the working group has been pursuing for some time, that of allowing analysis of many different kinds of user agents. (Nevertheless, I notice that in [1], Ian characterizes the UAAG document as having a "scope" that "has been narrowed to address general purpose user agents meant to interact with assistive technologies". I think that this narrowing is healthy and it reflects something of a merging of the approaches.) Perhaps further discussion will reveal a need for a solution more along the lines that I suggested, but at this point I am content to have a solution that does not entirely eliminate the applicability section. Furthermore, barring other issues that push me in a different direction, I don't know that it is essential to make this distinction about primary/secondary content/functionality in the applicability section. I think that these distinctions would be more important if: (a) WCAG recognized the distinction, which I don't think they do in any formal way (b) if user agent developers were unhappy about the current lack of the distinction, or (c) if there were a better consensus about the importance and meaning of the terms. Regarding point (c) I am concerned about inadvertently and prematurely codifying one representation of that scheme before a general consensus can be reached on it. I think that probably WCAG is the proper forum for working out a consensus. So I suppose that we should only try to the make the distinctions in UAAG where absolutely necessary. I suppose that if some checkpoints must "always" apply, then they would be clearly flagged as such in the document. I suppose that one could designate such checkpoints as having a Priority 0 (zero) but off-hand I don't think I favor that approach. [1] http://www.w3.org/WAI/UA/2000/08/uaag10-applic [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0031.html [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0225.html [4] http://www.w3.org/WAI/UA/WD-UAAG10-20000818 [5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0291.html > -----Original Message----- > From: Ian Jacobs [mailto:ij@w3.org] > Sent: Wednesday, August 23, 2000 11:31 AM > To: w3c-wai-ua@w3.org > Subject: Analysis of Applicability in UAAG 1.0 > > > Hello, > > In light of recent discussion about applicability, a request > from Charles [2] to review the use of the term in the document, > and a proposal from Eric [3] to simplify the model, I have > attempted to analyze how we use the concept of > applicability in the document. The analysis [1] has three > parts: > > 1) Links to background discussions and issues. > 2) Summary of the six applicability provisions in > the 18 August draft [4]. > 3) Breakdown of how the checkpoints seem to be > covered by those provisions. > > a) Some of the checkpoints seem unaffected and > thus would always apply. > > b) Two of the provisions seem unnecessary and > can be removed: unsupported technologies, > unsupported communication. > > c) The other four provisions can be stated > more succinctly and, according to this > analysis, should be left in the document.: > content type, content role, content properties, > and rendering support. > > My hope in doing this analysis was that I would > conclude that applicability was not necessary and > could be removed from the document. This was Eric's > conclusion [3], though his conclusion is based on > the premise 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." I haven't been able to > agree with that starting point since there are some > requirements that are principally about features for > users with disabilities (e.g., captions) and others > that are required whether or not the developer intended > them for users without disabilities (e.g., DOM support). > > Thus, while I believe that we can get rid of two > of the applicability provisions, so far I have not > been convinced that we can get rid of the remaining > four. I'm still hoping we can! > > - Ian > > [1] http://www.w3.org/WAI/UA/2000/08/uaag10-applic > [2] > http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0031.html > [3] > http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0225.html > [4] http://www.w3.org/WAI/UA/WD-UAAG10-20000818 > > -- > Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs > Tel: +1 831 457-2842 > Cell: +1 917 450-8783 =========================== 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 Wednesday, 23 August 2000 17:45:16 UTC