- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 03 Aug 2000 23:30:08 -0400
- To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
- Cc: "Hansen, Eric" <ehansen@ets.org>
Date: 3 August 2000 To: UA List From: Eric Hansen Re: "Primary Content", etc. - Response to Ian Jacobs Following shows my responses to Ian Jacob's 28 July response [2] to my 27 July memo entitled "'Primary Content', etc." [1]. Please note that Ian had not yet seen my 28 July memo ("Primary Content", etc. - Corrected!) [3]. IJ = Ian Jacobs EH = Eric Hansen ==== IJ: Eric, Thank you for taking the time to construct this compelling missive! I wouldn't have expected any "less" from you. <wink>. I've included the email in its entirety after my signature. I have some comments and questions about some of your more salient points: 1) Primary content is "content (meaning #1) that is intended for people without any disability who are operating under standard conditions." One thing I like about this definition is that the content's format doesn't matter. Text can be primary content and a video can be alternative content. EH: Correct. Though, in the corrected memo, I use the term "secondary content" instead of "alternative content". ==== 2) Distinguishing primary from alternative content sheds light on some (WCAG) requirements on authors. For example, I agree that there should not be a P1 requirement to provide a text equivalent for another (non-text) equivalent. EH: As noted above, in the corrected version of the memo ("Corrected!") I use the contrast primary/secondary as opposed to primary/alternative. (The more I think about the term "alternative" the more I am convinced that it means many things to many people and that it is far to loaded a term to reclaim and give a precise meaning....) Actually there are cases in which one should provide a text equivalent for "(non-text) equivalent" and my basic rule covers that situation. I would say that it should not be a P1 requirement to provide a text equivalent for: 1. Text-Accessible Primary Content, i.e., text element (possibly including a text equivalent) in primary content 2. Text-Accessible Secondary Content, i.e., text element (possibly including a text equivalent) in secondary content 3. Text-Inaccessible Secondary Content, i.e., non-text element in secondary content. Text equivalents are not necessary for cases 1 and 2 since the content is already accessible. Text equivalents are not essential (Priority 1) in case 3 since the content is secondary content. However, it should be a P1 requirement to provide a text equivalent for: 4. Text-Inaccessible Primary Content, i.e., non-text element in primary content. Suppose that the Web site is teaching the value of auditory description (an auditory equivalent of the visual track of a movie or animation); thus the auditory description is _intended_ to be presented to people without any disability. The auditory description is a non-text element (and also happens to be a non-text equivalent) and by current WCAG 1.0 checkpoint 1.1, a text equivalent should be provided. Yet I say that the requirement (at the P1 level) to provide a text equivalent for an auditory description depends only on whether the auditory description is primary or secondary content. If the auditory description is intended for people without any disability it is primary content, and a text equivalent of it needs to be provided. However, most of the time, one should not be required to provide a distinct text transcript (i.e., text equivalent) of it, since usually auditory descriptions are secondary content (they are not intended for users without any disability but are useful for people with blindness). ==== 3) For reference, here's Eric's revised WCAG checkpoint 1.1: "Ensure that every non-text element that, under standard conditions, would result in primary content has a text equivalent [Priority 1]." Comments and questions: 1) Are the only types of content primary and alternative? Your definitions suggest that this is the case. What is the default when there are no stylistic or semantic indications (in a spec or in metadata) to distinguish primary from alternative content? I think that in the absence of style and semantic information, you have to consider generic XML content either entirely primary or entirely alternative. Either case is problematic. EH: As the definition of "content" suggests, there are many usages of the term content. And even within one major meaning there seem to be facets. Some of the major axes upon which content can differ include, primary/secondary, text-accessible/text-inaccessible, important/unimportant, etc. Yet other information cannot be easily expressed as dichotomous data. Regarding "defaults", see in the corrected memo. I have added some possible rules that would allow a user agent to determine whether content should be assumed to be "primary" or "secondary" (instead of the term "alternative") in the absence of an explicit indication. In the case of XML, I think that that the construct of primary/secondary content needs to be built in. I would think it important in designing XML-based applications, especially those involving diverse media, to make provisions for marking content as primary/secondary. You alluded to yet finer distinctions about content. I will focus for a moment on marking of equivalents and their equivalency targets. These markings suggest a few finer distinctions. Equivalents should be marked with info about: 1. URI for content 2. URI for equivalency target 3. Type of Equivalent: [ regular text equivalent of classical multimedia presentation = default | captions for classical multimedia presentation | collated text transcript of classical multimedia presentation | etc.] 4. Priority for Equivalent: [ 1=default | 2 | 3 | NA ] 5. Reference Document for Priority: [ WCAG 1.0 = default | etc.] 6. Disability Status Profile For Which The Equivalent Is Suited [ Base on general mapping between "Type of Equivalent" and Disability Status = default | visual disabilities | hearing disabilities | etc. ] 7. Output Device Profile For Equivalent: [ Base on general mapping between "Type of Equivalent" and "Output Device Type" = default | etc. ] 8. URI For Output Style for Equivalent [ Base on general mapping between "Type of Equivalent" and "Output Style" = default | etc. ] Equivalency targets should be marked with info about: 1. Presentation Type: [ infer from MIME type = default [?] | classical multimedia | audio-only | visual-only | nonlinearizable table | image | etc. ] Note. If one wishes to integrate internationalization issues into the markup, these should also be added. ==== 2) I have a problem with this reformulation of 1.1. Content is primary based (in part) on author's intention. Your formulation of 1.1 suggests that content could become primary independently of the author's intention, just based on the user side conditions. If content that started primary doesn't end up primary, what is it? If primary is established from the author's vantage point, it sounds like it's either primary or it's not, independent of the user's operating conditions. EH: My reformulation of WCAG 1.0 checkpoint 1.1 was: ""Ensure that every non-text element that, under standard conditions, would result in primary content has a text equivalent [Priority 1]." My revised (3 August 2000) reformulation of WCAG checkpoint 1.1: "Ensure that every primary non-text element has a text equivalent. [Priority 1]". This revision makes two changes of note. First, this revised version corrects a bug by removing the phrase "under standard conditions". I had overlooked the fact that the "under standard conditions" provision is already an integral part of my definition of "primary content" and therefore did not need to be part of checkpoint 1.1. ("Primary content. The general definition of primary content is "content (meaning #1) that is intended for people without any disability who are operating under standard conditions." That is, primary content must allow users without any disability to obtain the essential benefit of a Web-based product or service when used under _standard conditions_.) Second, this revision also answers the question posed by Ian Jacobs as to whether, under my conception, content could become "primary" based on user-side considerations. I think that the answer to that question has to be "No". Specifically, I have concluded that, for the sake of convenient implementation, most if not all "style" information needs to be considered "disposable". Style (as opposed to "content") is something that tends to be more under user control and must be considered irrelevant in determining whether content is considered primary or secondary. The Need to Refine Our Definition of "Element". We need to discuss the extent to which we are truly all talking about the same thing when we refer to "element". I am not sure, for example, if the wide variety of things that I mean when I refer to a "text element" or "non-text element" can actually be pulled from a DOM2 representation. There is also the problem of how to handle multiple text elements and non-text elements may be found in what DOM2 considers a single glob. The Concept of "Important" Elements. This idea of generating a list of "important" element types (and therefore having some being designated as "unimportant") is interesting. It could have implications several checkpoints. For example, perhaps checkpoint 1.1 should read: "Ensure that every important primary non-text element has a text equivalent. [Priority 1]" If some element is unimportant, how can it be a Priority 1 requirement to do almost anything with it? I think that the designation of "important" element further underscores that need for a construct of "primary" (versus "secondary") content. A content author needs to be able to declare virtually any element "primary", based on whether it is important or essential for persons without any disability, overriding, in effect, the "importance" level that is based merely on the element type. ==== 3) What about alternatives of alternatives? Suppose I use nested OBJECT elements in HTML to say "Include this video, or if not, this image, or if not this other image, or if not this text." Is the first image only an alternative? Or is it a primary in some other context (having two alternatives)? The author has intended the image to be an alternative (in some sense) and therefore would not be required to provide a text equivalent. There may be shades of primary. Would that be confusing? EH: I think that you mean "equivalents" instead of "alternatives" (which is not a defined term!). In the case you cite, a user agent should recognize that, in the absence of explicit markup to indicate that the image and text are primary content, the image must be considered secondary content. I assume that it is reasonable for the nesting relationship to be used to indicate that the image and text are equivalents for the video. If this is the case, then in the absence of explicit designation as either primary or secondary content, they should be assumed to be secondary content. In summary, equivalents should be assumed to be secondary content if not explicitly designated otherwise. By the way, in my view, if the user agent recognizes both the image and the text as equivalents for the video, then it should probably give presentational priority to the text rather than to the image. Recall that the video (assuming it is "classical multimedia") requires captions, auditory descriptions, and collated text transcript. Also recall that except for the temporary requirement for prerecorded auditory descriptions, WCAG does not require any non-text equivalents. That means that the "image" is non-required (gratuitous, optional) and is less essential that the text, which presumably is a collated text transcript. ==== IJ: Basically, I would like to try to keep the notion of primary content but I want it to only make sense from the author's point of view. EH: I agree. ==== IJ: Does the model still work if primary content is always primary content and there's no WCAG 1.1 requirement for text equivalents for content that "results in primary content"? EH: OK to have primary content always primary content. I am not sure what you mean by "there's no WCAG 1.1 requirement for text equivalents for content that "results in primary content"". I think that the notion of primary content provides an essential clarification to checkpoint 1.1. Obviously, there would be plenty of instances in which there would be a "requirement for text equivalents for content that "results in primary content"", i.e., all cases in which the primary content contains non-text elements that lack text equivalents. ==== IJ: In other words, the author has to provide a text equivalent for any non-text primary content. Why does that break? EH: This sentence does not seem to match your preceding sentence. I assume that you mean that the "author has to provide a text equivalent for any primary non-text content that lacks a text equivalent." That does not seem broken. ==== IJ: The assumptions about standard conditions and available technology are good ones, but can they be constrained to the author's side and the author's determination of what is primary content? EH: Yes. The author should be able to assign the primary/secondary status of content. By the way, standard conditions need to specify availability of compatible text-to-speech capabilities and text-to-braille capabilities if they were called for by primary content. The system should also be able to linearize tables based on markup and simple heuristics. ==== IJ: I don't think that the user agent should be required to recognize content as being primary, but the user agent must be able to recognize alternatives; these are peer alternatives. Why should the user know what is primary (notably when what is most important to the user may not be primary to the author)? Does it benefit the user in any way to know what's primary? EH: I am not sure what you mean by "peer alternatives". Again, I think that the term "alternatives" is undefined. (If someone thinks that they know what the term "alternatives" might mean, I suggest that they present a definition to the list.) Unfortunately, the user agent will not be able to reliably recognize equivalents in all cases. I agree that it should be a top priority for WCAG to determine how to mark equivalents and their equivalency targets. The advantage to the user of having something marked up as "primary", from the user's point of view is that they know "I have right to know the meaning of this primary content -- either directly or from an text-accessible equivalent (or possibly a prerecorded auditory description if the equivalency target is a multimedia presentation) -- not merely in a 'source view', but in human understandable terms, in a way that is suited to my disability. Furthermore, I have the benefit of knowing that, from the author's point of view, this material marked as secondary content is non-essential, except for equivalents that also happen to be equivalents that are suited to my disability. Knowing what is primary and what is secondary allows me to focus on essentials rather than constantly wading through unnecessary clutter." From the authors' point of view, they know that by designating "primary content" they: 1. Have a reliable way of designating what the typical person without a disability needs access to in order to obtain the essential benefit of the content. 2. Only need to develop equivalents for primary content, not for secondary content, including most required equivalents. This is particularly important for developers of specialized software exclusively for one disability group. If the software is not intended for the "person without a disability" at all, then virtually all content is "secondary content" and virtually all equivalents become optional rather than required. 3. Have a way of focusing people's attention on the most important content. 4. Have a way of "overriding" the "importance" assignments that W3C user agent guidelines plans to attach to HTML elements. It should be noted that defaults can be established that would allow user agents to make educated guesses about what the author would have intended as the proper primary/secondary designation from information such as: whether the content is an equivalent or an equivalency target, whether the element type is important or unimportant, whether the element is a text element or a non-text element, etc. Conversely, if the language supported the designation of primary/secondary, then the user agent could guess at some of the other pieces of information if they happen to be missing. Finally, I think that nothing less than the primary/secondary distinction will allow people to readily evaluate how well they are doing in providing people with disabilities access that is comparable to people without disabilities. Progress can actually become measurable. Ensuring accessibility (at least at the Priority 1 level) becomes conceptually simple, "Ensure access to primary content plus accessible equivalents for inaccessible primary content." (Of course, how encompassing this statement is depends on how encompassing one's definition of "content" is; yet the statement is remarkably scalable and adaptable to different meanings of the word "content".) ==== IJ: Your proposed checkpoint 2.1b for UAAG requires user agents to "make avilable all primary content as well as all W3C-required equivalents". Is there any need to single out the primary content? EH: I single out primary content because: (a) there are many people with disabilities who would rely on primary content alone, (b) even those who use primary content mostly as a supplement their use of secondary content still need to be able to try to access the primary content if they desire, (c) the Priority 1 requirement to "make available" content should not encompass secondary content except for required equivalents. (Note: An author could provide an equivalent that is not required by WCAG. It should not be a P1 requirement to make those available.) The general philosophy is, "Don't make accessibility requirements that are not necessary and if you do make requirements, don't assign a high priority level (e.g., Priority 1) unless it is truly warranted." ==== IJ: [By the way, Dan Connolly has said that we blew it by calling two pieces of content "equivalent" if their relationship is not symmetric. As Eric points out, the equivalence relationship is often imperfect and one-directional. Would we be better off using a term like "text alternative" with the understanding that the text alternative is supposed to fulfill the same function?] EH: To be sure, the "equivalent" relationship is logically unidirectional, i.e., the relationship between the equivalency target and the equivalent cannot be reversed. There may possibly be a better term but I am confident that it would not be helpful now to use the term "alternative". As I recall we discussed using the term "alternative" instead of "equivalent." I am glad we did not go with that. I still don't think we have a firm grasp of what we mean or should mean by "alternative". I actually like the term equivalent, because it shows that we are striving to provide equivalent (comparable) access for people with disabilities (see definition of Equivalent). By the way, I would like to further banish the term "alternative" to yet further reaches of obscurity by replacing the terms "regular content"-versus-"alternative content" (found in my "Corrected!" memo) with the new and hopefully more precise terms of "equivalency target"-versus-"equivalent". ==== IJ: I have to think more about all of this. I think there are some very interesting points in your proposal, but I'm having trouble with blurring the lines between author's intent and the user environment. EH: I hope that the clarifications that I have offered will sharpen the line between the author's intent and the user environment. [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0183.html [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html <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, 3 August 2000 23:57:52 UTC