- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 28 Jul 2000 03:32:09 -0400
- To: w3c-wai-ua@w3.org
"Hansen, Eric" wrote:
>
> Date: 27 July 2000
> To: UA List
> From: Eric Hansen
> Re: "Primary Content", etc.
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.
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.
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.
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.
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?
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. 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"? In other
words, the author has to provide a text equivalent for
any non-text primary content. Why does that break?
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?
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?
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?
[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?]
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.
Cheers,
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
<BEGIN ERIC ORIGINAL MEMO>
> Date: 27 July 2000
> To: UA List
> From: Eric Hansen
> Re: "Primary Content", etc.
>
> At the 13 July telephone conference I took an assignment to explain my
> proposal for a definition of "primary content."
>
> I am also including other definitions that I am using in a paper that I am
> writing. I think that they might be useful. This memo also introduces a
> concept called "standard conditions" which I believe can greatly simplify
> and clarify the meaning of the guidelines. Indeed, without such a concept, I
> think that some of our checkpoints are not quite correct.
>
> The very last part of this documents lists a few of the problems that these
> changes are trying to address and lists a few benefits of making the
> changes.
>
> This memo has several objectives, listed below beginning with the most
> important:
>
> 1. Set forth some definitions capable of reserving "namespace" for terms
> such as "primary content" and "alternative content", "standard conditions",
> "nonstandard conditions" in the WAI working groups and documents.
>
> 2. Make some changes in UAAG and WCAG documents, especially the definitions
> and ancillary material. (I am not cross-posting this immediately.)
>
> 3. Set forth a piece of a vision or concept of accessibility and suggest how
> that may help WAI set its course in the future.
>
> INTRODUCTION
>
> I believe that the lack of solid definitions of "primary content" and
> "alternative content" has adversely affected the previous two guideline
> documents (Web Content and Authoring Tools) and that by not addressing it
> now with the User Agent guidelines, we will be compounding the difficulties.
>
> I realize that we will not be able to clear up everything all at once. There
> are some clarifications that will have to await later iterations of all
> three guidelines. But I believe that with the User Agent guidelines we still
> have an opportunity to avoid some future trouble as well as to set a
> positive direction for the future.
>
> PART 1: PRIMARY AND ALTERNATIVE CONTENT
>
> Suggestions 1.1: Provide a definition of "primary content".
>
> New:
>
> 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_.
>
> Comment:
>
> The question arises: "_Who_ does the 'intending' referred to in the
> definition and how is that intention become manifest?" I think that the Web
> content author's claim is currently the most relevant piece of information
> for determining whether elements should be considered primary versus
> alternative. However, other criteria are also possible, including: What
> content do people without any disability commonly access when using the Web
> site, etc. User agents should rely on explicit markings when available and
> when they are lacking they should follow a rule-set (in process) for
> determining how to handle cases in which markup is at least partially
> missing.
>
> ====
>
> Suggestion 1.2: Provide a definition of "alternative content".
>
> New:
>
> Alternative content. All content (meaning #1) other than primary content.
> See the definition "primary content." [This could be elaborated on that will
> have to be done later.]
>
> ====
>
> PART 2: STANDARD AND NONSTANDARD CONDITIONS
>
> Suggestion 2.1: Define standard conditions.
>
> New:
>
> Standard Conditions
>
> Standard conditions are those condition for content delivery allow a person
> without any disability to gain the full benefit of typical content, in this
> case, Web content. Standard conditions serve as a reference point for
> delivery of content. Among the important conditions that are standard for
> Web content are a computer capable of a wide range of visual and auditory
> output and which relies on keyboard and a pointing device (mouse) for input.
> Individuals with disabilities will often be able to receive Web content with
> standard conditions but in some cases, non-standard conditions will be
> required. The more that conditions diverge from the standard conditions, the
> lower the number of checkpoints that may be applicable. (See the section on
> Checkpoint Applicability.)
>
> ==
>
> [For WCAG] In the context of the WCAG documents, the term "standard
> conditions" refers to the following set of conditions of delivery of Web
> content: [see list below]
>
> [For UAAG] In the context of the UAAG documents, the term "standard
> conditions" refers to the following set of conditions of delivery of Web
> content: [see list below]
>
> ==
>
> 1. A color visual display monitor about 14 to 17 inches diagonal measurement
> with a pixel resolution of at least X and palette of at least X colors.
> 2. Visual display capabilities adequate for handling motion video with
> audio, animation, and other graphical and sound elements.
> 2. Stereo two speakers for output capable of outputting prerecorded [??]
> audio and synthesized speech [How about other sounds?].
> 3. A pointing device (e.g., mouse) and keyboard for input.
> 4. Quick response time for accessing information both from local storage
> devices and via the Internet.
> 5. Operated by one person at a time seated in front of the display monitor.
> 6. Moderately quiet room.
> 7. Moderately good room illumination.
> 8. Unlimited time per session, though usually measured in minutes or hours.
> 9. [?] Computer properly handles WIMP [spell out] interface
> 10. [?] System compatibility with readily available commercial assistive
> technology. [I don't think that this is essential but it may not hurt.]
> 11. [For WCAG but _not_ for UAAG] Availability of general-purpose graphical
> user agents (e.g., Web browser and multimedia players).
>
> Comment:
>
> It is critical that these conditions represent common, but reasonably
> positive conditions because primary content delivered under these conditions
> represents that usage that _has to be matched for people with disabilities_.
> To match a level of delivery quality much lower than this would sabotage the
> guidelines. For example, suppose that the "standard conditions" for Web
> content specified the use of a reduced capability device, such as a
> small-screen text-only mobile device. Such a reduced capability device would
> unduly lower the bar that had to be reached.
>
> Note that standard conditions would be different for another class of
> technology (phone, television, radio, etc.). Furthermore, over time the
> standard conditions for a given class of technology may need to be modified,
> though these conditions should designed to last for several years.
>
> Note that reference to standard conditions does not in any way limit the
> manner or condition in which Web technology _can_ be used. It is merely to
> establish a stable point of reference against which access for people with
> disabilities can be compared.
>
> ====
>
> Suggestion 2.2: Define "nonstandard conditions".
>
> Nonstandard conditions
>
> Conditions that vary significantly from standard conditions. [This could be
> elaborated upon further but that will need to come later.]
>
> ====
>
> PART 3: CONTENT
>
> This section is very rough. It attempts to delineate a few definitions of
> "content".
>
> ====
> Suggestion 3.1: Refine the definition of "content".
>
> Importance: Fairly important. It would be more important if I felt that I
> really had it right. I think that I have some of it close to right.
>
> Old (7 July 2000 UA doc):
>
> Content
> In this specification, the term "content" is used in two ways:
> Content refers to the document object as a whole or in parts. Phrases such
> as "content type", "text content", and "language of content" refer to this
> usage. When used in this sense, the term content encompasses equivalent
> alternatives. Refer also to the definition of rendered content. and other
> accessibility information.
> Content refers to the content of an HTML or XML element, in the sense
> employed by the XML 1.0 specification ([XML], section 3.1): "The text
> between the start-tag and end-tag is called the element's content." Context
> should indicate that the term content is being used in this sense.
>
> New:
>
> Content:
>
> The word content is used in several different ways in this document. [I have
> not determined that the UA document itself uses the term in each of the
> following ways.]
>
> Content #1: The information and functionality that are available to the user
> through the user interface.[This seems close to what we refer to as
> "rendered content".] This meaning of content encompasses that which is
> produced as a result of content #2, style, and logic [??] information. This
> meaning focuses on that which is rendered. Note that this meaning includes
> the notion of functionality.
>
> Content #2: The elements that are used to produce content #1. This meaning
> of content _includes_ style information. See checkpoint 2.1 (content
> includes style information). See definition of element.
>
> Content #3: Content as opposed to Style (Formatting) information.
>
> Content #4: Content as opposed to Functionality. This meaning of content is
> contrasted to the "functionality". This contrast seems implicit in the use
> of the term "content" is checkpoints themselves and the term "functionality"
> in the section on applicability. [I am not sure that this distinction holds
> up well.]
>
> Content #5: Value or benefit, such as of a product or service. Under this
> definition, one wants to ensure that people with disabilities obtain the
> full value or benefit of a Web-based product or service. [Note. This
> definition should not be used in checkpoints.] Fake example: "The purpose of
> the guidelines is to make Web content accessible to people with
> disabilities." UA document example: "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_." [Emphasis added].
>
> Content #6: The message to be communicated by content meaning #1. Example:
> "The goal of the guidelines is to make Web content accessible to people with
> disabilities" is taken to mean that the message can be received and used by
> people with disabilities.
>
> [ETC.]
>
> ====
>
> PART 4: ELEMENTS AND EQUIVALENTS
>
> Suggestion 4.1: Define "element" as used in the context of text element and
> non-text element.
>
> Proposed Language:
>
> Element. An element is a coherent parcel of Web content (content meaning #2)
> intended for producing "information and functionality that are available to
> the user through the user interface" (content meaning #1). An element may be
> thought of a "pre-rendered content", since it refers to content that
> "precedes" (i.e., is used to produce) what appears (visually, auditorily,
> etc.) at the user interface. The term "pre-rendered" content is used instead
> of "unrendered" content since rendered content can also be used for
> generating content meaning #1. For example a parcel of visually displayed
> text may properly be considered an element, since it could be read such as
> by an optical character reader and translated into another form (e.g.,
> Braille text, synthesized speech). [Need to determine whether elements can
> contain other elements (?). Also whether elements are determined at the time
> of authoring (?). Also whether certain kinds of content [certain media types
> (??)], such as images, _must_ be regarded as elements, although one element
> can include other elements. Also whether elements can be of any size, e.g.,
> a single text character, a page, a presentation, or a whole Web site. Also
> whether those elements presented to the person with a disability in order to
> obtain the full benefit should have little or no irrelevant material.]
>
> ====
>
> Suggestion 4.2: Define the term "text element".
>
> The term text element is one of the most important terms in the document. As
> I picture it, as noted later, a text equivalent is essentially a text
> element that fulfills essentially the same function as some other content.
>
> New:
>
> Text Element
>
> A "text element" is an element that has the accessibility and communication
> advantages commonly associated with well-formed written text. Specifically,
> a text element fulfills its function when delivered in any of the _core text
> element output modes_ (visually-displayed text, synthesized speech, and
> Braille) to their respective _core disability reference groups_. An
> important characteristic of a text element is "seriality"; that is, a text
> element must make sense when presented in serial fashion (i.e.,
> sequentially), such as via audio or Braille. [Note. The foregoing might be
> changed unless changed from "seriality" to "serializable" yet that would
> assume a higher level of processing that I am not sure that we want to
> assume/permit/require. THIS IN AN IMPORTANT ISSUE. Our position on that this
> issue affects whether or not nonlinearizable tables should be considered
> non-text elements. There is nothing that in my view theoretically requires
> that candidate text elements require little or no processing. I suppose that
> in order we specify a finite set of permissible file formats.] [I am not
> sure whether I am sold on the following, but here is a rough cut:] In the
> context of this document, a text element must be created so that any CSS
> style information and HTML-type style [?] information found in candidate
> text element is "disposable". Thus, loss of any such style information must
> not cause the rendered text element to fail to fulfill its function.[Ian,
> does this last sentence match what we discussed? The requirement to have
> formatting information is not required by a theory (at least my theory) of
> equivalents but may be justified on the basis of technical/pragmatic
> issues.]
>
> Comment 1:
>
> At this time, I do not define a text element as necessarily conforming to
> WCAG 1.0 checkpoint 14.1 ("Use the clearest and simplest language
> appropriate for a site's content. [Priority 1]", though maybe it should. I
> need to think more about this. Comments welcome.
>
> Comment 2:
>
> Creating a text element almost invariably involves inserting text characters
> (usually in written natural language such as English, French, etc.) for
> storage, retrieval, and rendering; nevertheless any specific mechanism for
> creating a text element is not an essential characteristic.
>
> I believe that text elements must be logically distinct, even if they drawn
> upon the same resource. Logical distinctness can then yield presentational
> distinctness when necessary.
>
> Comment 3
>
> As I have indicated before, I believe that nonlinearizable (or [?]
> nonserializable) tables (tables that cannot be automatically linearized)
> should be considered a non-text element and there require a text equivalent
> (i.e., linearized [or serialized] table). Comments welcome.
>
> Comment 4
>
> We need to talk more about what kind of "formatting" and processing
> information it is permissible or required to provide with or as a part of
> text elements.
>
> ====
>
> Suggestion 4.3: Define "core text element output modes".
>
> Each of these _core disability reference groups_ (blind, deaf, deaf-blind)
> corresponds to a "core text output modalities is matched to a _core text
> element output mode_: deaf: visually displayed text via the sense of sight,
> blind: synthesized speech via the sense of hearing, and deaf-blind: Braille
> for the tactile sense.
>
> ====
>
> Suggestion 4.4: Define the term "disability reference groups".
>
> New:
>
> Disability Reference Groups
>
> Reference groups are those groups of people with disabilities that the
> guidelines are intended to benefit. The WAI has not established a general
> standard list of disability groups, although such a list might contain
> groups such as [? blind, low vision (including color blind), deaf, hard of
> hearing, deaf-blind, learning disability, physical disability]. However,
> there are three _core disability reference groups_: blind, deaf, and
> deaf-blind. These three groups represent disabilities that affected by
> impairment to sight and hearing, which are the sensory modalities most
> commonly used for communication of Web content.
>
> Comment 1
>
> I think that it is justifiable and perhaps necessary to give special
> emphasis to these core disability reference groups.
>
> ====
>
> Suggestion 4.5: Define non-text element.
>
> Non-Text Element
>
> Conversely, a "non-text element" is an element that _lacks_ one or more of
> the advantages of text elements. For example, it fails to preserve its
> function (e.g., convey its message) when rendered in at least one of the
> three core text element output modes -- visually displayed text, synthesized
> speech, and Braille.
>
> Comment: Distinguishing Between Text Elements and Non-Text Elements
>
> This comment describes how to distinguish between a text element and a
> non-text element.
>
> Creating a text element almost always involves inserting text characters
> somewhere; however, one must avoid being confused into thinking that this
> method of creating an element is a defining feature of text elements. Note
> that the list of _non-text_ elements in WCAG checkpoint 1.1 contains things
> that were created using _text_ characters, such as ascii art and scripts,
> etc. For that matter, even audio and video files (or any other computer
> data) can be construed as consisting of combinations of the _text
> characters_ of "1" and "0".
>
> Additionally, the fact that something _appears visually as text_ does not
> mean that it is a text element. For example, as emphasized in checkpoint 1.1
> of WCAG 1.0, "graphical representations of text" are non-text elements.
> Somewhat more surprisingly, _any visually displayed text_ is properly
> regarded as a non-text element because, given ordinary commercially
> available technology, the visually-displayed text fails to render sensibly
> in at least one of three modalities -- visually-displayed text, synthesized
> speech, and Braille. Any visually displayed text obviously has the quality
> of being rendered as visually displayed text, yet at this time, it cannot be
> rendered as synthesized speech or Braille without delivery mechanisms that
> are not commonly available commercially. Some combination of technologies
> might now exist (e.g., optical character recognition) that could read the
> text from a visual display and then translate that into an electronic text
> representation that could then output to synthesized speech and Braille (as
> well as back into visually displayed text). Yet such a combination of
> technologies is not commonly available commercially and is likely to be
> quite inaccurate. Thus, requirement to provide a text equivalent depends not
> merely on the presence of a non-text element; it depends on also on it
> lacking a text equivalent. If the visually displayed text is rendered from
> an underlying text representation (e.g., ordinary prose text between tags or
> with other appropriate markup in an HTML file), then it already has a text
> equivalent, whereas, if the visually displayed text is rendered from a
> graphical image (i.e., a picture), then it lacks a text equivalent, and a
> text equivalent must be provided.
>
> ====
>
> Suggestion 4.5: Clarify the definitions of text equivalent and non-text
> equivalent.
>
> Proposed Language:
>
> Text Equivalent. A text equivalent is a text element that is an equivalent
> for some other content.
>
> Non-text Equivalent. A non-text equivalent is a non-text element that is an
> equivalent for other content. For example, an auditory description is an
> auditory equivalent of the non-auditory track information (especially the
> visual track).
>
> Comment:
>
> Note that a text equivalent may be created not only for primary content, for
> any content ("some other content").
>
> ====
>
> PART 5: CHECKPOINT 1.1 OF WCAG 1.0
>
> Overview: Split checkpoint 1.1 of WCAG 1.0 into three checkpoints and
> include the concept of primary content.
>
> Suggestion 5-1: Fix the main portion of WCAG 1.0 checkpoint 1.1.
>
> Importance: Very important
>
> Old:
>
> "Provide a text equivalent for every non-text element..."
>
> New checkpoint 1.1a:
>
> "Ensure that every non-text element that, under standard conditions, would
> result in primary content has a text equivalent [Priority 1]."
>
> Comment 1:
>
> This revised version makes clear that elements produce content meaning #1
> (since the definition of primary content refers to meaning #1).
>
> The use of "would" correctly confirms that the implication that they must
> provide the text equivalent even if the content may be used under
> nonstandard conditions.
>
> Comment 2
>
> Probably the most important kind of equivalent is the "text equivalent."
> WCAG 1.0 requires Web content developers to provide text equivalents for all
> non-text elements.
>
> Old WCAG 1.0 checkpoint 1.1 reads:
>
> 1.1 Provide a text equivalent for every non-text element (e.g., via
> "alt", "longdesc", or in element content). This includes: images, graphical
> representations of text (including symbols), image map regions, animations
> (e.g., animated GIFs), applets and programmatic objects, ascii art, frames,
> scripts, images used as list bullets, spacers, graphical buttons, sounds
> (played with or without user interaction), stand-alone audio files, audio
> tracks of video, and video. [Priority 1]
>
> It should be noted that there are many cases of non-text element for which
> it is not necessary to provide a text equivalent because a text equivalent
> already exists, for example, visually displayed text that already has an
> underlying text representation.
>
> ====
>
> Suggestion 5-2: Fix the secondary part of WCAG 1.0 checkpoint 1.1.
>
> New checkpoint 1.1b:
>
> "Ensure that every non-text element that under standard conditions would
> result in only alternative content has a text equivalent [Priority 3]."
>
> Comment 1:
>
> The Priority 3 designation for this proposed checkpoint makes sense because
> having such text equivalents "may" help people with disabilities, but
> failure to provide the text equivalents should not making access impossible
> (Priority 1) or even difficult (Priority 2).
>
> This says, for example, that if a Web content developer provides a sign
> language video equivalent as alternative content for a written text, then it
> is only a Priority 3 requirement to provide auditory descriptions, text
> transcript (collated text transcript if there is audio), and captions (if
> there is an auditory track). If, however, the sign language video is primary
> content such as would probably be the case if the purpose of the material
> was to teach sign language skills to general audiences (i.e., persons
> without any disability), then those equivalents must be provided per
> checkpoint 1.1a (Priority 1).
>
> ====
>
> Suggestion 5-3: Explain why the current WAI documents don't fully reflect
> this distinction between primary and alternative content.
>
> New:
>
> "Current versions of the WAI documents do not fully reflect the distinction
> between primary and alternative content because they tend to reflect what
> was possible in HTML versions 4.0 or earlier. Those languages do not provide
> a standardized way for the Web content author to make a claim about what
> claim about which content is "primary" and which is "alternative". Future
> Web languages and customizable langauges (XML) should allow elements to be
> marked up to indicate whether elements will be used to produce primary
> content (i.e., content [meaning #1] to be used by people without any
> disability)."
>
> Comment 1:
>
> Note that when I refer to primary or alternative content, I am using a
> definition of content (meaning #1) that may include the concept of style or
> formatting.
>
> It may be important for some applications (high stakes educational testing)
> to be able to specify ranges or enumerated settings that are to be
> considered "primary content" and those outside that range or enumerated set
> to be considered "alternative content". For example one can imagine a high
> stakes educational test in which a certain set of font sizes are considered
> as producing primary content (e.g., 6 point to 48 point) versus alternative
> content (e.g., smaller than 6 point or larger than 48 point). However, for
> most applications, this level of refinement over the distinction between
> primary and alternative content may be beyond the minimal requirement. This
> notion of variations in style resulting in something being categorized as a
> primary or alternative content may present some problems that I have not yet
> resolved.
>
> ====
>
> PART 6: ASSOCIATING PRIMARY AND SECONDARY CONTENT
>
> Suggestion 6-1: Provide specifications for associating primary and
> alternative content.
>
> [More needs to be said on this point.]
>
> ====
>
> PART 7: FIXES TO UAAG CHECKPOINT 2.1, ETC.
>
> Suggestion 7.1: Split UAAG checkpoint 2.1 into three checkpoints.
>
> Old (UAAG 7 July 2000):
>
> 2.1 Make all content available through the user interface. [Priority 1]
> Note: Users must have access to the entire document object through the user
> interface, including equivalent alternatives for content, attributes, style
> sheets, etc. This checkpoint does not require that all content be available
> in every viewport. A document source view is part of a solution for
> providing access to content, but is not a sufficient solution on its own.
> Refer to guideline 5 for more information about programmatic access to
> content.
> Techniques for checkpoint 2.1
>
> New checkpoint 2.1a:
>
> 2.1a Until there are W3C-recommended ways for the Web content author to make
> claims about the primary/alternative status of Web content elements, make
> all content available through the user interface. [Priority 1]
>
> Note. In some cases, making content available may consist merely of
> providing a document view.
>
> Comment
>
> For checkpoint 2.1a, one still needs to have applicability kick in
> sometimes.
>
> I am still uncomfortable with this checkpoint because there is no way to
> ensure or require that content is understandable by humans.
>
> ====
>
> Suggestion 7.2: Ensure Priority 1 access to primary content and required
> alternatives.
>
> New checkpoint 2.1b:
>
> When there are W3C-recommended ways for the Web content author to make
> claims about the primary/alternative status of Web content elements, make
> available all primary content available as well as all W3C-required
> equivalents. [Priority 1]
>
> Comment:
>
> Note 1. Since not every device can deliver every kind of primary/alternative
> content, the user agent applicability provisions may kick in.
>
> ====
>
> Suggestion 7.3: Ensure Priority 3 access to "other" content.
>
> New checkpoint 2.1c:
>
> When there are W3C-recommended ways for the Web content author to make
> claims about the primary/alternative status of Web content elements, make
> available all other content beyond that covered in checkpoint 2.1b.
> [Priority 3]
>
> Note. This "other content" would include non-required alternative content
> (e.g., equivalents not required by WCAG).
>
> ====
>
> Suggestion 7.4: Require that user agents provide a minimum set of
> accessibility modes.
>
> Either as a UAAG checkpoint (e.g., checkpoint 2.3) or techniques for it,
> specify expectations for different modes of presenting content.
>
> New:
>
> "Provide customizable presentation modes suited to different disability
> profiles. [Priority 2 (or 3)]"
>
> "Techniques"
> Following are possible modes.
>
> "1. BL Mode - optimized for individuals who are blind. Provide primary
> content plus facilitated access to auditory descriptions, synthesized speech
> renderings of text elements, font modification features, etc."
> 2. DF Mode - optimized for individuals who are deaf. Provide primary content
> and text equivalents for auditory information (e.g., captions).
> 3. DB Mode - optimized for individuals who are deaf-blind. Provide primary
> content [?] plus facilitated visual and Braille access to all text elements,
> including text equivalents for inaccessible primary content. Facilitate
> configuration and control for turning visual content on and off.
> 4. Full Access Mode - provide primary content plus menu (or other) access to
> all required equivalents.
> [etc.]
> 5. Primary-Content-Only Mode - This mode is used to test the functionality
> of an application vis-à-vis persons without any disability. This mode
> provides a reference point for evaluating basic functionality of the
> application and a point of comparison for evaluating access for people
> _with_ disabilities.
>
> ====
>
> Suggestion 7.5: Review UAAG the section on applicability.
>
> The section on applicability needs to be reviewed. My hunch is that the
> section could be considerably shortened and simplified through the use of
> concepts such as "primary content" and "standard conditions".
>
> PART 8: PROBLEMS AND BENEFITS
>
> This section outlines a few of the problems that the changes try to address
> and some of the problems.
>
> The problems and solutions have not been organized into a highly ordered
> sequence. This is somewhat of a mixed bag.
>
> Problem 1: Inability to Distinguish Between Essential and Non-essential
> Content
>
> The current guidelines do not generally distinguish between essential and
> non-essential content in determining the accessibility requirements. Issue
> 299(Definitive list of important elements for known markup languages?
> (http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#299) is one
> manifestation of this problem.
>
> Problem 2: Failure to See The WAI Documents as Minimal Requirements
>
> I think that we need to be more explicit in the WAI document about the fact
> that they are statements of minimal requirements -- not statements of an
> "ideal" level of accessibility.
>
> I think that we realize that we don't really know what the ideal level looks
> like, and even if we did, it would be technically and otherwise impossible
> to implement at this time.
>
> ====
>
> Problem 3: An Endless Development Loop
>
> Our current approach appears to require alternative content for all content,
> which results in an endless loop. (I don't think that it was intended.) For
> example, under the current phrasing, WCAG checkpoint 1.1 ("Provide a text
> equivalent for every non-text element...") may put the Web content developer
> into an endless development loop. Suppose that we have multimedia
> presentation (mmp1). We need to provide auditory descriptions (synchronized
> with the auditory track), captions (visually-displayed-text equivalent that
> is synchronized with the visual/auditory tracks), and a collated text
> transcript capable of being output visually, auditorily, and tactilely (via
> Braille). Yet when we play mmp1 with some combination of auditory
> descriptions, captions, and collated text transcript, that constitutes
> another multimedia presentation which we will call simply "mmp2" (actually
> it may constitute even more than one multimedia presentation). Now because
> mmp2 is a multimedia presentation, it needs auditory descriptions, captions,
> and collated text transcript, which are more complicated than those of mmp1,
> since, for example, the audio is more complicated due to auditory
> descriptions and the visual track is more complex due to captions. The
> process continues to mmp3 an so on _ad infinitum_.
>
> One obvious way to prevent getting caught in such an endless loop is to
> clarify by saying that Web content developers _only_ have to develop
> accessible "alternative content" for "primary content" that is inaccessible.
>
>
> Problem 2: Failure to acknowledge or respect the content author's _intent_
> in determining whether content is considered "primary" or "alternative".
>
> The guideline documents express some allegiance to understanding the
> "function" of content (see the definition of "Equivalent"), but fails to
> acknowledge the important role of the _Web content author_ in designating
> the function of content. For example, at a minimum, the Web content author
> ought to be able to designate whether a specific content element will serve
> to produce "primary content" or "alternative content". My criticism may seem
> nonsensical since, for example, one assumes that "alt-text" for images is
> intended by the content author to be "alternative content". But that is only
> an assumption.
>
> Yet, let us consider an example in which that assumption is incorrect.
> Suppose that the Web content author has developed an instructional module
> that teaches the role of various accessibility-related elements (prerecorded
> auditory descriptions, renditions of text equivalents, renditions of
> linearized tables, etc.). The developer wants to show examples of each of
> the elements and he wants the examples to be available for all users (both
> with and without disabilities). In this case he should be able to show
> accessibility elements (e.g., visually displayed "alt-text", visually
> displayed longdesc file contents, prerecorded auditory descriptions,
> captions, visually displayed collated text transcripts, etc.) and designate
> them as _primary content_. Under my proposed definitions, any of these that
> are non-text elements (meaning that they _cannot_ be sensibly rendered as
> visually displayed text, synthesized speech, and Braille) must have a text
> equivalent provided since they are primary content. Almost all of these
> probably already have text equivalents and so do not need them added. But
> let us assume that the auditory description lacks a text equivalent and a
> text equivalent (e.g., text transcript) must be provided.
>
> Unfortunately, there is no standardized machine-readable way for a Web
> content author to make a claim about which content is "primary" and which is
> "alternative". Sometimes I wonder whether the current WAI guideline
> documents tend to incorrectly assume that the key to the distinction between
> primary and alternative content lies in component type (e.g., primary =
> multimedia presentation; alternative = captions, auditory descriptions,
> collated text transcript) rather than in the specific communication purposes
> of content, for which the stated intent of the Web content author would be a
> highly relevant clue.
>
> Benefit 1: Fits with regulatory emphasis on comparability between people
> with disabilities and people without disabilities.
>
> Benefit 2: Fits with definition of Equivalent.
>
> Please note that this definition fits perfectly with the definition of
> "equivalent" in WCAG 1.0, which also uses persons without any disability as
> a reference point:
>
> Content is equivalent to other content when both fulfill essentially the
> same function or purpose upon presentation to the user. In the context of
> this document, the equivalent must fulfill essentially the same function for
> the person with a disability (at least insofar as is feasible, given the
> nature of the disability and the state of technology), as the primary
> content does for the _person without any disability_. (from the definition
> of Equivalent, emphasis added)
>
> I would point out that there is a huge benefit it the conceptual simplicity
> of having two important terms -- "equivalent" and "primary content" --
> clearly linked in this way. Conversely, I think that failure to link the
> terms in such a clear way injects "noise" into the conceptual framework.
>
> Benefit 3: Reinforces the Unidirectional Relationship Between "Original"
> Content and Its Equivalents
>
> Please note that the distinction between primary and alternative content
> builds upon and reinforces the "unidirectional" relationships between the
> two pieces of content in the "equivalency" relationship. In most situations,
> the original content will be primary content (i.e., for people without any
> disability) and the equivalents will be alternative content (i.e., for
> people with a disability). It is important to keep in mind that if content A
> is an equivalent for content B, then that does not necessary mean that
> content B is an equivalent for content B. (If I am correct, cases in which
> the relationship would be true in both directions are generally trivial or
> very rare.)
>
> SUMMARY OF BENEFITS
>
> I believe that adopting the main suggestion this memo will significantly
> improve the quality of the WAI guidelines documents. I think that it can
> make the checkpoints clearer and more easily understood and followed, will
> prevent implementation problems that will otherwise arise, and very
> importantly, will make the guidelines more readily applicable to different
> languages, devices, and disability groups.
>
> <END OF MEMO>
Received on Friday, 28 July 2000 03:32:16 UTC