FAQ Regarding Equivalency Concept

Date: 15 November 2000, 13:28 hrs
To: UA List
From: Eric Hansen
Re: FAQ Regarding Equivalency Concept

Per earlier discussion within the Working Group, I have developed the
beginnings of a Note or FAQ (Frequently Asked Questions) regarding the
concept of 'equivalency'. I have lots more to do on it, but I felt that it
might be helpful to send this to the list at this time.

Title: Toward a Unified Concept of 'Equivalency' for Web Accessibility

ABSTRACT

[To be provided]

PART 1: INTRODUCTION

Status of This Document

This document may be superseded at any time. Unless otherwise indicated, the
opinions expressed in this document do not necessarily represent the
consensus of the W3C, WAI, or of any of its working groups. The levels of
consensus associated with W3C Recommendations and working drafts cited in
this document are commensurate are those implied in their status within the
_W3C Process_.

Overview

This document attempts to elucidate a concept of 'equivalency' that is
capable of serving the Web Accessibility Initiative (WAI) now and long into
the future. The concept of  'equivalency' is one of the most important
concepts in the WAI guideline documents, figuring prominently in the Web
Content Accessibility Guidelines (WCAG), the User Agent Accessibility
Guidelines (UAAG), and the Authoring Tool Accessibility Guidelines (ATAG).
For example, one of the most significant and sweeping requirements in any of
these guideline documents is checkpoint 1.1 of Web Content Accessibility
Guidelines (WCAG) 1.0, which requires that Web content developers "Provide a
text equivalent for every non-text element". Perhaps above any other
checkpoint, this is the one that requires the most new content development.
This is a Priority 1 checkpoint, which means that failure to adhere to this
checkpoint will cause one or more disability groups will find it
"impossible" to access information in the document" (see WCAG 1.0 definition
of Priority 1) and thereby prevent a Web site from achieving any level of
conformance to WCAG 1.0 (A, double-A, triple-A). The UAAG and ATAG documents
also make extensive use of the concept of equivalency. It is critical,
therefore, that the concept of equivalency be clearly defined and support
the removal of known accessibility barriers.

PART 2: FREQUENTLY ASKED QUESTIONS (FAQ)

Q = "Question"

==== FAQ-1 ====

Q: "Why is it so important that equivalency-related terms be clearly
defined?"

Equivalency-related terms are central to the work of the Web Accessibility
Initiative (WAI). For example, WCAG 1.0 checkpoint 1.1 is arguably the most
significant and sweeping requirement in any of these guideline documents
because it is the one that requires the most new content development. This
is a Priority 1 checkpoint, which means that failure to adhere to this
checkpoint will cause one or more disability groups will find it
"impossible" to access information in the document" (see WCAG 1.0 definition
of Priority 1). A Web site that fails to adhere to this checkpoint cannot
achieve any level of conformance to WCAG 1.0 (A, double-A, triple-A). It is
critical that checkpoint 1.1 be understandable and justifiable. WCAG 1.0
checkpoint 1.1 is as follows.

"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]

Understanding equivalency-related terms is important to developers of user
agents understand as well as to developers of Web content. For example, UAAG
1.0 checkpoint 1.5 requires user agent developers to ensure that "every
message (e.g., prompt, alert, notification, etc.) that is a non-text element
and is part of the user agent user interface has a text equivalent" (UAAG
1.0 [23 October 2000]). As noted in the UAAG 1.0 glossary definition of
'Text content":

"Per checkpoint 1.1 of "Web Content Accessibility Guidelines 1.0" [WCAG10],
authors must provide a text equivalent for every author-supplied non-text
element. Similarly, user agent developers must provide a text equivalent for
every non-text element offered by the user agent to the user (refer to
checkpoint 1.5)." (UAAG 1.0 [23 October 2000], glossary entry for 'Text
content, non-text content, text element, non-text element, text equivalent,
non-text equivalent'). UAAG 1.0 checkpoint 1.5 reads:

"1.5 Ensure that every message (e.g., prompt, alert, notification, etc.)
that is a non-text element and is part of the user agent user interface has
a text equivalent. [Priority 1]"

==== FAQ-2 ====

Q: "With respect to the concept of 'equivalency', what are some of the most
important things that WCAG 1.0 and UAAG 1.0 have in common?"

There are at least three major things that the UAAG 1.0 and WCAG 1.0 have in
common with respect to the concept of  'equivalency'.

1. Focus on Equal Access

In both specifications, the notion of 'equivalency' focuses on _equal
access_ for people with disabilities. An assertion that a piece of content
is an 'equivalent' says something about the potential of that content for
providing a person with a disability with essentially the same benefit as
that obtained by a person without any disability who is using some other
content.

Excerpts from the two specifications (WCAG 1.0 and UAAG 1.0) are as follows.

UAAG 1.0 (23 October 2000 'Last Call' Draft):

"In the context of this document, an equivalency relationship between two
pieces of content means that one piece -- the "equivalent" -- is able to
serve essentially the same function for a person with a disability (at least
insofar as is feasible, given the nature of the disability and the state of
technology) as the other piece -- the "equivalency target" -- does for a
person without any disability." (UAAG 1.0, glossary entry for 'Equivalent
(for content)'.)

WCAG 1.0:

"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." (WCAG
1.0, glossary entry for 'Equivalent')

Thus, in both specifications, the notion of equal access is at the heart of
the concept of equivalency. In both specifications, one piece of content --
the 'equivalent' -- is able to serve essentially the same function for a
person with a disability (at least insofar as is feasible, given the nature
of the disability and the state of technology) as some content other content
(UAAG 1.0 calls it the 'equivalency target') does for a person without any
disability. 

2. Unidirectionality of Relationship

The fact that the 'equivalent' pertains to a person _with_ a disability
whereas the other content (the 'equivalency target') pertains to a person
_without_ any disability has implications for directionality. 

Specifically, just because:
(a) content A for a person _with_ a disability is an equivalent for content
B for a person _without_ a disability, 
we _cannot necessarily assume_ that:
(b) content B for a person _with_ a disability is an equivalent for content
A for a person _without_ a disability.

For example, let us take the case in which some descriptive text serves as a
text equivalent for an image for someone who is blind. The term 'equivalent'
(as in 'text equivalent') is applicable because the person can use their
screen reader (text-to-speech software) to generate synthesized speech that
fulfills the essentially the same function (insofar as is possible given the
current state of technology and the nature of blindness) as the image does
for a person without a disability.

If the equivalency relationship were bi-directional, that would require, for
example, that the _image_ be able to fulfill essentially the same function
(insofar as is possible given the current state of technology and the nature
of blindness) _for the person who is blind_ as the text description does for
a person _without_ a disability. This clearly cannot be assumed since, for
example, images are generally considered inaccessible to people who are
blind.

Thus, we cannot assume that content types (e.g., text, images, audio, video)
that are usable by people without any disability can arbitrarily be made
accessible to a person with a given disability (or vice versa) and,
therefore, we cannot characterize the equivalency as bi-directional in that
sense. This unidirectionality is a necessary consequence of the definition
of 'equivalent' as found in both specifications.

3. Equality of 'Feasible Essential Function'

In both specifications (UAAG 1.0 and WCAG 1.0), the concept of equivalency
asserts an important kind of _equality_  between the equivalent and the
content for which its serves as an equivalent (the 'equivalency target'). 

Sometimes an equivalent and its equivalency target may seem sufficiently
different from each other that it seems strange to say that they are 'equal'
in some respect. For example, it is seems obvious that an image and its text
equivalent are not 'equal' -- at least visually -- because the typical
appearance of a visually rendered image is very different from the typical
appearance of its visually rendered text equivalent. Yet, in both
specifications, the two pieces of content _are_ equal in a sense that
contributes greatly to the goal of equal access. Specifically, with respect
to the _essential communication function that is feasible_  to achieve
(i.e., the 'feasible essential function'), the _equivalent_ for the person
with a disability is _equal_ to the other piece of content for the person
without any disability (i.e., the _equivalency target_). 

4. Recognize and Use Key Equivalency-Related Terms

Both specifications use the terms 'equivalent', 'text equivalent', 'non-text
equivalent', 'text element', 'non-text element', 'text content', and
'non-text content' although, as we will argue, UAAG 1.0 (23 October 2000)
clarifies the meaning of these terms.

==== FAQ-3 ====

Q: "How is UAAG 1.0 most helpful in clarifying the meaning of
equivalency-related terms such as 'text element', 'non-text element', 'text
equivalent'?"

UAAG 1.0 does several things to clarify equivalency-related terms. In doing
so it answers two questions that naturally arise about UAAG checkpoint 1.5
and WCAG 1.0 checkpoint 1.1. 

a. "What is so 'inaccessible' about a non-text element that makes it
necessary to provide a text equivalent for each one?" 

b. "What is so 'accessible' about a text equivalent that allows it to remove
the accessibility barrier?"

In order to see how UAAG 1.0 helps answer these questions, let us begin with
what information is already provided in WCAG 1.0. WCAG 1.0 lays the
groundwork by noting that:

"Text content can be presented to the user as synthesized speech, braille,
and visually-displayed text. Each of these three mechanisms uses a different
sense -- ears for synthesized speech, tactile for braille, and eyes for
visually-displayed text -- making the information accessible to groups
representing a variety of sensory and other disabilities." (WCAG 1.0,
Introduction). This is also found in the WCAG 1.0 glossary entry for
equivalent.

Furthermore, within the WCAG 1.0 definition of equivalent we read:

"Since text content can be presented to the user as synthesized speech,
braille, and visually-displayed text, these guidelines require text
equivalents for graphic and audio information. Text equivalents must be
written so that they convey all essential content." (WCAG 1.0, glossary
entry for "Equivalent")

UAAG 1.0 explicitly connects the notion of 'text content' with the term
'text element', something which is not as clear in WCAG 1.0:

"In this document, the term "text content" refers to content that is
composed of one or more text elements." (UAAG 1.0 [23 October 2000],
glossary entry for 'Text content, non-text content, text element, non-text
element, text equivalent, non-text equivalent')

The UAAG 1.0 defines 'text element' as follows:

"In this document, the term "text element" means content that, when
rendered, is understandable in each of three modes to three reference
groups:"
"1. visually-displayed text, for users who are deaf and adept in reading
visually-displayed text; 
"2. synthesized speech, for users who are blind and adept in use of
synthesized speech; 
"3. braille, for users who are deaf-blind and adept at reading braille."
(UAAG 1.0 [23 October 2000], glossary entry for 'Text content, non-text
content, text element, non-text element, text equivalent, non-text
equivalent')

Having provided a clear definition of 'text element', the definition of
'non-text element' is easy:

"A "non-text element" is an element that _fails_ to be understandable when
rendered in any of three modes to their respective reference disability
audiences. Thus, text elements have essential accessibility advantages often
associated with text while non-text elements are those that lack one or more
such advantages." (UAAG 1.0 [23 October 2000], glossary entry for 'Text
content, non-text content, text element, non-text element, text equivalent,
non-text equivalent')

Thus, we now have an answer to the first question: "What is so
'inaccessible' about a non-text element that makes it necessary to provide a
text equivalent for each one?" The answer is that a non-text element is
'inaccessible' in the sense that it fails to be understandable in one or
more of the three delivery modes to their respective reference disability
groups.

Now what about the other question: "What is so 'accessible' about a text
equivalent that allows it to remove the accessibility barrier?" Again, UAAG
1.0 provides the key to answering this question by linking the definition of
'text equivalent' to the definition of 'text element'.

"A "text equivalent" is a text element that, when rendered, serves
essentially the same function as some other content (i.e., an equivalency
target) does for a person without any disability." (UAAG 1.0 [23 October
2000], glossary entry for 'Text content, non-text content, text element,
non-text element, text equivalent, non-text equivalent') [NOTE. SHOULD SAY
"_THE_ EQUIVALENCY TARGET.]

Thus, the reason that a text equivalent is so 'accessible' is that that it
_is_ a 'text element', which, as we have already seen, is accessible in the
sense of being understandable to the reference disability groups when
delivered in their respective modes. 

And, thus, UAAG provides helps considerably in clarifying both the meaning
and the rationale for both UAAG 1.0 checkpoint 1.5 and WCAG 1.0 checkpoint
1.1.

==== FAQ-4 ====

Q: "Are there any major obstacles that would seriously hinder the term 'text
element' as being defined instead simply as a piece of content that is
composed of text characters?"

Let us consider one major hindrance that would result from defining a 'text
element' as content that is composed of text characters rather than the UAAG
1.0 definition, specifically, incompatibility with the list of non-text
elements in WCAG 1.0 checkpoint 1.1. The list begins with the words "This
includes: "

"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]"

If a text element were defined simply as "text", then some of the "non-text
elements" in WCAG checkpoint 1.1, such as ascii art and scripts, would be
counted as "text elements". A good definitions of text element and non-text
element will _not_ allow an element to be both a text element and non-text
element _at the same time_. 

By contrast, the presence of ascii art and scripts in the list of non-text
elements is perfectly understandable in the context of the UAAG 1.0
definition of non-text element because such elements would typically fail to
fulfill their communication function in one or more of the three modes
(e.g., synthesized speech in the case of ascii art) even though they are
"text".

Received on Wednesday, 15 November 2000 13:38:37 UTC