- From: Hansen, Eric <ehansen@ets.org>
- Date: Mon, 27 Nov 2000 13:06:54 -0500
- To: "UA List (E-mail)" <w3c-wai-ua@w3.org>
My comments are marked below with 'EH::'.
> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Friday, November 24, 2000 3:31 PM
> To: Hansen, Eric
> Cc: ehansen7@hotmail.com; jongund@uiuc.edu; asgilman@iamdigex.net;
> ij@w3.org
> Subject: Re: Top down approach: equivalence, etc.
>
>
> "Hansen, Eric" wrote:
> >
> > This memo has two parts. Part 1 focuses on reactions to the approach
> > discussed on the train. Part 2 tries to continue on the
> same 'track' that
> > the 23 October 2000 version of UAAG 1.0 reflects.
> >
> > PART 1: A DIFFERENT 'TRAIN' OF THOUGHT
> >
> > Ian outlined an approach discussed during a conversation on
> the train. Here
> > are some thoughts:
> >
> > 1. If we are willing for the moment to forget history and
> to discuss changes
> > that would impact WCAG, then approaches such as the one
> outlined based on
> > our train conversation are possible. In my work with the
> UAAG definitions, I
> > have tried to define terms such that no change is required
> to checkpoint 1.1
> > of WCAG 1.0.
>
> Yes, I realize that.
>
> > 2. The approach appears to remove what I might term the
> 'equal access'
> > provisions from equivalency. Those provisions necessarily involve a
> > comparison between one piece of content for a person with a
> disability and
> > another piece of content for a person without any
> disability. At least on a
> > conceptual level, I view this as a weakness of the approach
> being discussed.
> > On a practical level, I don't yet have a good feel for how
> important this
> > is. In some applications, this kind of equal access claim
> will be very
> > important, but perhaps that could be built into another
> specification.
> > Basically, I feel that the equal access claim is the essence of the
> > equivalency relationship, but if others believe strongly
> that they wish to
> > remove that from the definition, I will be happy to
> consider it. As I think
> > about it, I would not want to go a lot further down this
> road unless key
> > members of WCAG are seriously willing to consider removing or this
> > provision. I am getting to feel that we need more input on
> this and other
> > matters.
>
> I'm not convinced that the equal access provisions have vanished. A
> requirement
> to include equivalents for "A" that are available tri-modally is
> tantamount
> to requiring equivalents for "A" that are accessible to individuals in
> the
> reference disability groups. As noted previously, there are other
> accessibility
> issues than the ones requiring tri-modal rendering, but for
> the purposes
> of
> this discussion, I equate "available tri-modally" with
> "providing access
> to users
> with from the reference disability groups". Have I missed
> something (or
> short-circuited
> something)?
EH::
What one captures (at least roughly) with the phrase 'available tri-modally'
is what in UAAG 1.0 (23 October 2000) is the definition of 'text element'.
What one is still missing is the 'equal access' provision of 'equivalency'
that would say: 'A text equivalent is content that is available tri-modally
AND in doing so fulfills essentially the same function as some other content
(the equivalency target) does for a person without any disability.' In other
words it is not enough that content is understandable is each of the three
modes. It is essential that the understanding (or communication function)
that is obtained in each of the three modes is essentially the same as that
which is obtained by a person without any disability who is accessing the
other content.
>
> > 3. This approach does not seem to distinguish any member of
> an equivalency
> > group as an equivalency target. I suppose that one could define an
> > equivalency group as one in which each member of the group
> is equal in some
> > aspect (functionality for some user) to every other member
> of the group. If
> > the equal access provisions are removed from the definition
> of equivalency,
> > then there may be little or no need to designate one member
> as the target.
>
> I think it's more important to make this distinction in WCAG than in
> UAAG,
> in any case. It may not be necessary in UAAG.
EH::
I think that what I am trying to do is maintain that distinction that is
already in WCAG 1.0.
>
> > 4. The impact of this approach on other terms that are used
> in both UAAG 1.0
> > and WCAG 1.0 is not entirely clear ("Text content, non-text
> content, text
> > element, non-text element, text equivalent, non-text
> equivalent"). But the
> > impact may not be terrible.
> >
> > I think that it is worthwhile to consider this option. I
> look forward to
> > comments by others.
> >
> > ========
> >
> > Issue 1: WCAG 1.0 Checkpoint 1.1
> >
> > Ian wrote:
> > > Re-examining WCAG, checkpoint 1.1 almost works as is:
> > >
> > > "Provide a text equivalent for every non-text element."
> > >
> > > However, it could be rewritten (and would be longer) as:
> > >
> > > "Provide a text equivalent for any content that is
> > > not available in each of three modes: visual, auditory,
> > > tactile.
> > >
> > > Note: Examples of content that requires a text
> > > equivalent include audio, video, ascii art, etc."
> >
> > Following the line of reasoning above, I think that a more
> accurate phrasing
> > of checkpoint 1.1 would be something along the lines of:
> >
> > "Provide a text equivalent for any content that is not
> understandable in
> > each of three modes: visually-displayed text, synthesized
> speech, and
> > braille."
> >
> > This clarification is important because we need to make
> clear that we are
> > not requiring people to render content as pictures (visual
> mode), non-speech
> > sounds (auditory mode), or raised-line tactile drawings
> (tactile mode). We
> > want them to provide content that has the accessibility
> advantages often
> > associate with text.
>
> I agree.
>
> > My rewording still does not explain the further assumptions
> that are now
> > explicit in the 23 October 2000 version of UAAG definition of 'text
> > element'. But I can't see burdening the checkpoint language
> itself with
> > further detail.
> >
> > The approach discussed by Ian eliminates some guidance that
> is implicit (or
> > explicit) checkpoint 1.1 of WCAG 1.0 regarding the
> grain-size of 'non-text
> > elements'. (This may not be a big issue.)
>
> I think that (in WCAG) this could be Note material.
>
>
> > ====
> >
> > Issue 2: Recognition of Equivalents
> >
> > Ian wrote:
> >
> > > Note: Since in some formats, equivalents may not be
> > > recognized as such but may be recognized as part of a
> > > larger class of objects (which we've narrowed to those
> > > objects marked up as alternatives), user agents may
> > > need to provide access to the larger class in order to
> > > ensure that 2.3 is satisfied.
> >
> > This comment is extremely important and may not even be
> stated clearly
> > enough. Even with WCAG 1.0 triple-A conformant content,
> there is no way that
> > a user agent can be certain that content that is found in some 'alt'
> > attribute is an equivalent or equivalency target or
> neither. There is a good
> > likelihood that content found there was intended as an
> equivalent and that
> > the other piece of content (e.g., the image) is the
> equivalency target. But
> > there is nothing in the HTML 4.0 or WCAG 1.0 specifications
> to prevent an
> > author from (a) intending the reverse, such as an image
> that is a 'non-text'
> > equivalent for some text that is found in the 'alt', or (b)
> simply putting
> > totally unrelated content in that location.
> >
> > To drive the point home, I think that one can make the case
> that given the
> > current state of WCAG 1.0 and UAAG 1.0 and other W3C
> specifications (HTML,
> > SMIL 2.0), that a user agent can _never_ fully recognize an
> _equivalent_. It
> > can only present one or more 'alternatives' to the user and
> let the user
> > 'dispose' of them. Without such a comment (perhaps even
> more strongly
> > worded), this would place a heavy and nonsensical burden
> upon UAAG 1.0
> > checkpoints 2.5 and 2.6 (handling of unrecognized or missing text
> > equivalents). (By they way, regardless of the outcome of
> this discussion, I
> > think that checkpoint 2.5 and 2.6 need some minor tune-up.)
> >
> > Regardless of what approach is taken, we need to address
> this gap in the
> > current UAAG 1.0 guidelines. I think that it is important
> to realize that
> > this is an issue regardless of how we define 'equivalency' or 'text
> > element'.
>
> Yes, I think we are all pretty much in agreement on the following:
>
> 1) We need to state in UAAG that to ensure coverage of some
> requirements,
> the UA developer may have to cast a wider net than our minimal
> requirements.
>
> We may not yet agree on the following:
>
> 2) How to write the checkpoint (broadly or narrowly). So far, I am
> more
> inclined to have narrow checkpoints and notes about
> formats such as
> SMIL.
>
> > Regardless of how we define those terms, the user agent developer
> > must clearly understand that current languages and
> specification (including
> > WCAG 1.0) place the burden upon the user for sorting through those
> > alternatives to find the accessibility content that WCAG
> 1.0 requires.
>
> Yes.
>
> > PART 2: BACK ON THE EXPRESS (?) TRAIN
> >
> > This part discusses things that do not assume the changes in Part 1.
> >
> > One whole I see part 1 as moving backward or staying still
> and I say part 2
> > as moving forward.
>
> That's interesting: I saw the "top-down" discussion as a way of moving
> forward
> for the following reasons:
>
> 1) It would seem that WCAG 1.0 is slightly (at least) broken with
> respect
> to consistency in definitions and that something needs to be done
> (outside
> of UAAG). The top down approach seemed a simpler way (to me) of
> describing the
> WCAG requirements than what WCAG 1.0 says.
>
> 2) The top down discussion suggests to me that we can have simpler
> definitions
> without losing the accessibility bindings. I will need to discuss
> with Eric
> the part about the missing equal access provisions. As I
> mentioned,
> I don't think
> they have been lost since they are built into the
> requirements. It
> is still important
> to explain that:
>
> a) The goal is equal access
EH::
See my earlier comment about what I think is missing from the proposal under
discussion.
> b) For users with some disabilities, tri-modal access
> is a way to
> meet that goal
EH:
To my understanding, 'equal access' necessarily involves a comparison
between (at least) one person with a disability and a person without a
disability. Consider some explanatory material regarding the section 508
regulations for federal (U.S.) procurement:
"Section 508 requires that when Federal agencies develop, procure, maintain,
or use electronic and information technology, they shall ensure that the
electronic and information technology allows Federal employees _with
disabilities_ to have access to and use of information and data that is
comparable to the access to and use of information and data by Federal
employees who are _not individuals with disabilities_, unless an undue
burden would be imposed on the agency."
(http://www.access-board.gov/sec508/nprm.htm, emphasis added)
> c) WCAG 1.0 requires authors to do this with text equivalents.
>
> > Some of the things in the part should be done regardless of
> whether the
> > changes in part 1 are accepted.
> >
> > ====
> >
> > Suggestion 1: Rely on WCAG 1.0 for definitions of text
> element and non-text
> > element
> >
> > Refer to WCAG 1.0 as the authoritative source for
> distinguishing between
> > text elements and non-text elements. I have such language,
> an excerpt of
> > this is as follows:
> >
> > "Distinguishing Between Text Elements and Non-Text
> Elements. Developers of
> > user agents or of Web content are not required to validate
> the accessibility
> > of content with individuals in the reference disability
> groups in order to
> > classify elements as either text elements or non-text
> elements. Involvement
> > of people with disabilities in validating accessibility is
> encouraged. Yet
> > it is sufficient to make classification decisions on the
> basis checkpoint
> > 1.1 of WCAG 1.0 checkpoint, which identifies certain units
> of content as
> > 'non-text elements' [NOTE. I am not sure that WCAG would
> intend to say the
> > list is sufficiently definitive and complete to also say
> that "Yet it is
> > both necessary and sufficient to make....". We should
> discuss implications
> > of this if WCAG feels that way.]. As noted above, text elements are
> > generally composed solely of text, yet note that 'ascii
> art' and 'scripts',
> > though composed of text, are classified in WCAG 1.0
> checkpoint 1.1 as
> > 'non-text elements' because they are typically _not_
> understandable in at
> > least one of the three modes (visually displayed text,
> synthesized speech,
> > braille) to their respective reference audiences."
>
> Would we copy the WCAG definitions into UAAG?
>
EH::
I think that a better approach would be to simply give a few examples:
'e.g., images, animations, video, audio, ascii art, scripts, etc.' and then
refer them to WCAG 1.0. This might give WCAG a little more wiggle room in
their version 2.0.
> > ====
> >
> > Suggestion 2: Make clear the limits of recognizing roles
> >
> > Explain that some (now _all_) language specifications do
> _not_ permit user
> > agents to distinguish among alternatives between: (a)
> equivalents and
> > non-equivalents; nor (b) an equivalent and an equivalency target.
>
> Yes.
>
> > ====
> >
> > Suggestion 3: Provide a definition of "alternatives."
> >
> > I am thinking that it might be something like this:
> >
> > "Alternative; alternative relationship. An alternative is
> content that
> > resides in a location appropriate (according to
> specification) for the
> > content that serves the role equivalency target or
> equivalent. For example,
> > according to WCAG 1.0, in HTML, for an image that is an
> equivalency target,
> > an appropriate location for its text equivalent is between
> the quote marks
> > in the alt attribute (alt="").
> > "An 'alternative relationship' is the set of alternatives
> that is specified
> > as a single group. For example, an image that is an
> equivalency target is in
> > the same alternative relationship as the image element's
> alt attribute value
> > and the resource identified by the element's longdesc attribute. An
> > alternative relationship may include as few as one entity (i.e., one
> > alternative with no 'peer'). Any equivalency relation must
> have one or zero
> > equivalency targets."
>
> I have a couple of issues with the definition:
>
> 1) I'm not thrilled about talking about "location." I'd rather talk
> about
> "identity." The author identifies a piece of content as an
> alternative for
> some other content.
EH: I don't necessarily like the word 'location' either. Perhaps a better
word is 'mechanism'.
>
> 2) I don't think that alternative should be defined in terms of
> equivalent.
> As I've understood our discussion, we've considered the
> equivalence
> relationship
> to be a special case of the alternate relationship. For
> instance, I
> may offer the
> user 10 different "alternative" style sheets, without implication
> that they offer
> an equivalent experience to anyone (in fact, they intentionally
> offer a different
> experience).
EH::
As I considered the definition of alternative relationship, I was somewhat
surprised to find myself thinking that the linkage between alternative and
equivalent was important. But I do think that now.
I think that we are agreed that there is no existing specification that
requires that an 'alt' attribute have anything to do with disability access.
As far as I know, the same is true with analogous mechanisms in SMIL, etc.
I think that there may be a misunderstanding due to my bad wording. I will
try to clarify my intent.
My previous wording:
> > "Alternative; alternative relationship. An alternative is
> content that
> > resides in a location appropriate (according to
> specification) for the
> > content that serves the role equivalency target or
> equivalent. For example,
> > according to WCAG 1.0, in HTML, for an image that is an
> equivalency target,
> > an appropriate location for its text equivalent is between
> the quote marks
> > in the alt attribute (alt="").
> > "An 'alternative relationship' is the set of alternatives
Old (Eric's first proposal):
"Alternative; alternative relationship. An alternative is content that
resides in a location appropriate (according to specification) for the
content that serves the role equivalency target or equivalent. For example,
according to WCAG 1.0, in HTML, for an image that is an equivalency target,
an appropriate location for its text equivalent is between the quote marks
in the alt attribute (alt="").
New (27 November 2000 proposal):
"Alternative; alternative relationship. An alternative is 'pre-rendering'
content that is implemented using a mechanism that is prescribed for the
role equivalency target or equivalent. For example, according to WCAG 1.0,
in HTML, for an image that is an equivalency target, an appropriate
mechanism for implementing its text equivalent is between the quote marks in
the alt attribute (alt=""). It must be noted that specifications (HTML,
SMIL, etc.) may allow such mechanisms for any of a wide array of purposes,
many of which are unrelated to disability access."
What I am trying to do by restricting our use of alternative in the document
is to avoid an unlimited scope of things that user agent developers must
worry about. For example, suppose that I have a web page with a menu of four
options: a, b, c, and d. Each option or 'alternative' (general usage) has a
link to a different page. Do we really want user agent developers to be
required to provide the capabilities in checkpoint 2.3 for those options? I
think not. I believe that we only want them to focus on mechanisms that, by
specification, are those that _might_ be used for equivalents (i.e., for
disability access).
I must emphasize that this restriction in no way, shape or form is
attempting to modify or restrict the usages of specific mechanisms (e.g.,
'alt' attribute) to disability access. To do so is, I think beyond our
charter. It is only intended to help developers by narrowing the universe of
different mechanisms that they need to worry about.
Frankly, one of the top thoughts on my W3C mind over the last several days
is my thought that that phrase is not restrictive enough.
IJ:
>I think that "equivalent" is not necessarily bound to
> disability
> concerns either (e.g., here's an equivalent version of
> this document
> in French...).
EH::
In a previous memo, I have outlined how the notion of equivalency could be
useful for language translations. However, to the best of my knowledge,
providing access to language translations was never regarded as an
accessibility issue per se. Therefore, the definition of equivalency as used
in the WAI docs should not be modified to yet better accommodate language
translations. However, it is perfectly permissible to use 'alt' attribute or
similar mechanisms for language translations. If we must use the word
'equivalency' when referring to language translations, then we need to
qualify the term to something like:
"Language Equivalency. A language equivalency relationship between two
pieces of content means that one piece of content with base natural language
'A' is able to fulfill essentially the same function (insofar as in feasible
given the state of technology and the nature of the languages) for an adept
user of that language as another piece of content with base natural language
'B' does for an adept user of that language. In the absence of markup to the
contrary, neither language is presumed to be the 'original' or more accurate
expression of the content."
I personally don't think that UAAG 1.0 should be obliged to deal with the
language translation issue. Such involvement might be appropriate for
version 2.0.
>
> > "Due to limitations in language and other specifications:
> >
> > "(a) An alternative relationship may include alternatives
> that are unrelated
> > to each other by any equivalency relationship. For example,
> even though the
> > alt attribute is the proper location for placing the text
> equivalent for an
> > image, there the HTML specification allows use of the
> location for a wider
> > array of purposes. And no specification forbids an author
> from placing
> > unrelated content in that location.
> >
> > "(b) The equivalency role (e.g., equivalent, equivalency
> target) that an
> > alternative was intended by its author to serve may not be
> recognizable.
> > Even with WCAG 1.0 triple-A conformant content where each
> alternative is
> > either an equivalency target or an equivalent for that
> equivalency target,
> > it may not be possible for a user agent to be certain that a given
> > alternative was intended by the author as an equivalent or
> equivalency
> > target or neither.
> >
> > "This necessarily places a final responsibility on the user
> to determine how
> > and if the alternatives are related to each other, although
> the user agent
> > must help. This document requires the user agent to present
> alternatives to
> > users in ways that not only facilitate access to all
> content (checkpoint
> > 2.1), but to help users to identify equivalency
> relationships (checkpoint
> > 2.3 [checkpoint to be revised]). Furthermore, checkpoint
> 2.X specifies
> > configuration that will implement heuristics for assigning roles to
> > alternatives for which the role in unknown. An example of
> such a heuristic
> > might be, 'In the absence of other markup to the contrary,
> when there are
> > two alternatives -- an image plus the contents of an alt
> attribute for the
> > image -- then assume that the image is an equivalency target and the
> > alt-text content is a text equivalent.'"
> >
> > ==
> >
> > Compare the definition provided in
> > http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0157.html
> >
> > Definition of "Alternative relationship, alternative" :
> >
> > In the context of this document, an alternative
> relationship between two
> > pieces of content means that one piece is intended by the
> author to serve
> > essentially the same function as the other. For requirements in this
> > document related to alternative relationships, the user
> agent is only
> > responsible for those it can recognize (generally through
> markup). In the
> > absence of markup that indicates otherwise, an equivalency
> relationship
> > recognized by the user agent is presumed to indicate the
> author's intent to
> > present alternatives (i.e., the equivalent and the
> equivalency target).
>
> I still prefer the first two sentences of this version. However, we
> would
> need to add information about needing to provide access to
> alternatives
> in
> order to ensure access to equivalents for some formats.
EH::
You liked:
> > In the context of this document, an alternative
> relationship between two
> > pieces of content means that one piece is intended by the
> author to serve
> > essentially the same function as the other.
This may be okay, but I am not sure that it correctly characterizes the
mechanisms that we are referring to. For example, I don't think that there
is any such restriction on the use of 'alt' attribute. I think the specs a
pretty wide open. Furthermore, in the future there may be other
mechanisms... I think it much more direct and accurate to simply say that we
are focusing on mechanisms identified as proper (permissive, if not
exclusive) for equivalents and equivalency targets. Such an approach does
not attempt to reinterpret or modify existing specs (HTML, SMIL).
>
> > ====
> >
> > Suggestion 4: Distinguish between location and content
> >
> > Properly distinguish between the location that an
> alternative is stored and
> > the alternative itself. For example, checkpoint 2.6
> confounds the two. I
> > don't think that we can sort out these issues without
> making that basic
> > distinction.
>
> Can you explain this further? I understand the distinction you are
> making, but
> not the significance.
EH::
I don't think that I can fully articulate my concerns. But I think that one
issue is that since (at this moment) user agent can only recognize
_alternative relationships_ and must _infer_ the existence of 'equivalency
relationships', then the handling of empty alt attributes needs to be part
of the _inference_ processing. In other words, this issue needs to be
addressed at the stage in which one is evaluating the alternatives and
determining whether to count them as an equivalency relationship or not.
Perhaps this should be a special case of the checkpoint 2.3.A that I
proposed below.
Old (23 October 2000):
2.6 Allow configuration so that when the author has specified an empty text
equivalent for non-text content, the user agent generates no repair text or
generates repair text as required by checkpoint 2.5. [Priority 3]
Note: An empty text equivalent (e.g., alt="") is considered to be a valid
text equivalent in some authoring scenarios. For instance, when some
non-text content has no other function than pure decoration, or an image is
part of a "mosaic" of several images and doesn't make sense out of the
mosaic. Please refer to the Web Content Accessibility Guidelines 1.0
[WCAG10] for more information about text equivalents. Refer also to
checkpoint 2.5.
>
> > ====
> >
> > Suggestion 5: Clarify reality of unmarked equivalents.
> >
> > Document somewhere the fact that we have long considered the term
> > 'equivalent' applicable even when not marked up as such. (I
> think that it is
> > already in there but perhaps not as clearly as it needs to be.)
>
> Ok.
>
> > =====
> >
> > Suggestion 6: Reexamine checkpoints
> >
> > Reexamine every checkpoint to determine whether it really
> means the location
> > where an alternative is stored, an alternative, an equivalent, an
> > equivalency target, or some other term.
>
> Ok.
>
> > ====
> >
> > Suggestion 7: Fix the definition of recognize.
> >
> > Fix the definition of recognize (and perhaps applicability)
> to clarify
> > requirements for recognizing equivalency relationships and
> roles of their
> > parts.
>
> Ok.
>
> > ====
> >
> > Suggestion 8: Apply heuristics for assigning equivalency roles
> >
> > "2.3.A. Allow configuration to apply heuristics for
> assigning equivalency
> > roles (equivalent, equivalency target, unknown, unrelated) where the
> > author-intended roles are unknown.
> > "Note 1: An example of such a heuristic might be, 'In the
> absence of other
> > markup to the contrary, when there is an image plus one
> alternative, then
> > assume that the image is equivalency target and the
> alt-text content is the
> > text equivalent."
>
> I understand the motivation for this checkpoint:
> Add back some automation so the user isn't always required to make
> choices.
> But is this necessary? I would think that markup languages and style
> sheets
> (including user style sheets) will determine what gets
> rendered "first"
> and
> consequently what content will be accessible by virtue of checkpoint
> 2.3.
EH::
As nearly as I can recall, the working group seemed to be of the opinion
that issue of what gets rendered "first" should be considered distinct and
separate from the issue of whether something is an equivalent or an
equivalency target. Thus, the equivalency relationship should not, in
itself, characterize either the equivalent or the equivalency target as
being more preeminent or more worthy of being presented "first". I have
attempted to respect that distinction, which means that, as you suggest, it
is fine for other mechanisms (markup languages and style sheets) to
determine what is presented first.
I believe that checkpoint 2.3 should focus on what it says -- 'equivalents'
and 'equivalency targets', regardless of what those other mechanisms (markup
languages, style sheets, etc.) say about what is presented first. In other
words, checkpoint 2.3 does not speak to what gets presented 'first'.
Nevertheless, based on existing conventions for presentation, typically, the
equivalency target (i.e., the alternative that is inferred to be the
equivalency target) will be presented 'first' and the equivalent (the text
in the alt attribute) will be presented second. But our checkpoints are not
intended to interfere with or prescribe such things.
Thus, the focus of this proposed checkpoint is on the equivalency role, not
on the issue of what is presented first. To reiterate, the working group has
wished to treat the issue of equivalency role as a distinct and separate
issue than the issue of what gets presented first.
I personally don't think that it is necessary to have a checkpoint like 2.3
addressing things that are presented first versus second, etc.
>
> > ====
> >
> > Suggestion 9: Allow assignment and reassignment of
> equivalency roles.
> >
> > Because intended equivalency roles will be so uncertain, it
> seems important
> > (i.e, Priority 3 or higher), to allow the user to assign
> and reassign
> > equivalency roles.
> >
> > New:
> >
> > "2.3.B. Within an author-specified alternative
> relationship, allow the user
> > to assign and reassign equivalency roles (equivalent,
> equivalency target,
> > unknown, unrelated). [Priority 3 (or 2)]
> > "Note 1: This user agent must allow the assignments made to
> remain in force
> > until modified by the user or until the end of the session,
> whichever occurs
> > first. This will allow the assignments to be active when
> using the viewing
> > mechanisms of checkpoint 2.3.
> > "Note 2: The user must be allowed to reset alternatives
> within a group to
> > their original status (i.e., prior to the
>
> I'm not sure how this would work in practice. I also fear adding
> requirements
> with no implementatione experience at this point.
EH::
One of the purposes of this checkpoint is to reinforce the idea that
sometimes the heuristics in 2.3.A might be wrong. For example, someone may
have intended for an image to serve as a non-text equivalent for a text
(that is the equivalency target). Although given the currently available
mechanisms, an author might be considered unwise in trying to use the IMG
and 'alt' mechanism to do this. Perhaps at this stage this, checkpoint is
not essential, but I think that it does help fill in the picture.
Furthermore, I am thinking that few people are likely to object to a
rational checkpoint of this kind at the Priority 3 level. (At least they
should not at an earlier stage of progress...!)
>
> > ====
> >
> > Suggestion 10: Add a note to checkpoint 2.3.
> >
> > With the addition of checkpoints 2.3.A and 2.3.B in place,
> I don't see any
> >
> > New:
> >
> > Add:
> >
> > "Note 2: The user agent must respond to role assignment provided in
> > checkpoints 2.3.A and 2.3.B."
> >
> > Old (23 October 2000):
> >
> > 2.3 Provide easy access to each equivalent and each
> equivalency target
> > through at least one of the following mechanisms: (1)
> allowing configuration
> > to render the equivalent instead of the equivalency target;
> (2) allowing
> > configuration to render the equivalent in addition to the
> equivalency
> > target; (3) allowing the user to select the equivalency
> target and then
> > inspect its equivalents; (4) providing a direct link to the
> equivalent in
> > content, just before or after the equivalency target in
> document order.
> > [Priority 1]
> > Note: For example, if an image in an HTML document has text
> equivalents,
> > provide access to them (1) by replacing the image with the rendered
> > equivalents, (2) by rendering the equivalents near the image, (3) by
> > allowing the user to select the image and then inspect its
> equivalents, or
> > (4) by allowing the user to follow readily available links to the
> > equivalents.
> > Techniques for checkpoint 2.3
> >
> > > -----Original Message-----
> > > From: Ian Jacobs [mailto:ij@w3.org]
> > > Sent: Wednesday, November 22, 2000 1:56 PM
> > > To: ehansen@ets.org; ehansen7@hotmail.com; jongund@uiuc.edu;
> > > asgilman@iamdigex.net; ij@w3.org
> > > Subject: Top down approach: equivalence, etc.
> > >
> > >
> > > Hello,
> > >
> > > After the AOL face-to-face meeting, Eric and I took the
> > > train together as far as Philadelphia. We talked about
> > > equivalence/text content/text equivalents. Here is a
> > > description of our discussion as I remember it. (These
> > > views may not be Eric's.)
> > >
> > > Note: I've not sent these comments to the list per a
> > > request from the Chair. Jon has suggested that we try
> > > to work out a proposal that we can send to the group,
> > > but to keep the initial discussions off the list.
> > >
> > > Comments encouraged,
> > >
> > > - Ian
> > >
> > > ====================
> > > I think that the goal of WAI work is to meet the needs of
> > > users with disabilities by assigning responsibility for
> > > meeting those needs to content authors, software developers,
> > > and writers of technical specifications. Since WAI's mission
> > > today is to meet the needs of users with disabilities, each
> > > requirement made in a guidelines document must have a known
> > > impact on accessibility.
> > >
> > > There are a number of ways to "bind" a requirement to a user
> > > need. The "bottom up" approach (used by Eric) has been in
> > > part to use definitions for the binding. Another, "top down"
> > > approach (the subject of the train ride) binds the impact to
> > > the requirements at a higher level.
> > >
> > > Specifically, starting from the top:
> > >
> > > 1) User needs
> > >
> > > - All users must have access to all
> > > content and functionality.
> > >
> > > Note: For simplicity, below I only speak about
> > > functionality.
> > >
> > > - Some users with disabilities may not be able to
> > > access some functionality through all senses.
> > >
> > > Note: While is true for all senses, the ones that
> > > concern us today for Web access are sight and hearing.
> > >
> > > Note: WAI guidelines address other accessibility needs
> > > than those related to the senses of sight and hearing.
> > > Those are not at issue here.
> > >
> > > - Some users must have access to all functionality
> > > through just one of the following modes: visual,
> > > auditory, or tactile.
> > >
> > > 2) The general equivalence requirement (too strong for WCAG 1.0)
> > >
> > > - Authors, developers, and spec writers in some
> > > combination must ensure that all functionality is
> > > available through visual, auditory, and tactile means.
> > >
> > > Example: One way to meet this requirement for a
> > > restaurant menu is to publish three versions: a standard
> > > printed menu, a spoken menu, and a Braille menu. WCAG 1.0
> > > does not require authors to provide printed Braille to
> > > users and only requires an auditory description (1.3) for
> > > important information (until user agents support
> > > text-to-speech).
> > >
> > > 3) The specific text equivalent requirement (part of WCAG 1.0)
> > >
> > > - It is necessary and sufficient that authors meet the
> > > general equivalence requirement today by providing text
> > > "where necessary" (see below). Text is sufficient because:
> > >
> > > a) Technology exists today that makes some text available
> > > in all three modes. However, some text cannot communicate
> > > the same message when rendered in all three modes (e.g.,
> > > ascii art cannot in general).
> > >
> > > b) The WCAG WG considered that a requirement to provide
> > > text to meet the needs of users with uni-modal needs was
> > > not overly burdensome. The WCAG WG did consider, on the
> > > other hand, that graphical equivalents for all text
> > > content was overly burdensome.
> > >
> > > Notes:
> > >
> > > - A text equivalent must include text characters but is
> > > not limited to text characters (e.g., a JPEG file may
> > > include text characters amidst binary data). The text
> > > characters may only be available after processing (e.g.,
> > > there may be markup, the information may be encrypted
> > > or compressed, etc.); this is an implementation detail.
> > >
> > > - "Where necessary" means any time that some piece of
> > > content or functionality is not available in all three
> > > modes already. This was too general a statement for WCAG
> > > 1.0, so the WG narrowed the scope to "any content that
> > > isn't text available in all three modes". It is
> > > consistent that since the WG did not include the more
> > > general equivalence requirement, that it would define
> > > "where necessary" in terms of the narrower requirement
> > > that was made - for text equivalents. Hence "where
> > > necessary" was reduced to "for non-text content" even
> > > though some "non-text content" may be composed partially
> > > or entirely of text characters.
> > >
> > > The top-down analysis provides one way of looking at how
> > > WCAG 1.0 ended up with checkpoint 1.1. I think it also
> > > allows us to simplify our definitions:
> > >
> > > - text: sequence of text characters
> > >
> > > - equivalent: content that provides equivalent
> > > functionality as some other content
> > >
> > > - text equivalent: content that, possibly after
> > > some processing, is composed of text characters
> > > that are sufficient to make it an equivalent.
> > >
> > > - text content/element: I'm not sure that we need
> > > definitions for these terms.
> > >
> > > Re-examining WCAG, checkpoint 1.1 almost works as is:
> > >
> > > "Provide a text equivalent for every non-text element."
> > >
> > > However, it could be rewritten (and would be longer) as:
> > >
> > > "Provide a text equivalent for any content that is
> > > not available in each of three modes: visual, auditory,
> > > tactile.
> > >
> > > Note: Examples of content that requires a text
> > > equivalent include audio, video, ascii art, etc."
> > >
> > > The accessibility binding is achieved by the combination
> > > of the equivalence requirement and the assumption that text
> > > characters may be rendered in three modes. The key piece
> > > is still in the definition of text equivalent: that the
> > > characters alone must be sufficient to convey the equivalence.
> > >
> > > 4) Related requirements we're willing to make in UAAG
> > >
> > > I think that the following requirements still work with
> > > the simpler definitions proposed above:
> > >
> > > - Provide access to all content, including equivalents (2.1).
> > >
> > > - Provide easy access in context to all equivalents (2.3).
> > >
> > > Note: Since in some formats, equivalents may not be
> > > recognized as such but may be recognized as part of a
> > > larger class of objects (which we've narrowed to those
> > > objects marked up as alternatives), user agents may
> > > need to provide access to the larger class in order to
> > > ensure that 2.3 is satisfied.
> > >
> > > --
> > > Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
> > > Tel: +1 831 457-2842
> > > Cell: +1 917 450-8783
> > >
>
> --
> Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
> Tel: +1 831 457-2842
> Cell: +1 917 450-8783
>
>
Received on Monday, 27 November 2000 13:08:59 UTC