- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 21 Feb 2001 23:18:23 -0500
- To: w3c-wai-ua@w3.org
Hello,
Below is a proposal to address issues 394, 359, 358, 322, and 321.
It consists of four parts:
===========================================================
I. Modifications to checkpoints 2.1 and 2.3
II. Modifications to checkpoints 2.6 and 2.7
III. Definition of "optional content"
IV. Sketch of changes to definitions related to WCAG 1.0.
===========================================================
Reference document: 26 Jan 2001 Guidelines
http://www.w3.org/WAI/UA/WD-UAAG10-20010126
Issues list:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html
Notes on consensus among Al, Eric, and Ian about this proposal:
a) We agreed on Part I (the most important part of the proposal).
b) We have not formally agreed on the other parts, though we have
discussed all of them at some point. I think that any
differences of opinion about Parts II and III would be
minor.
c) Our discussions about definitions imported from WCAG 1.0
("equivalent", "text element", "text equivalent") ceased when
we realized that the substance of our discussions lay at the
checkpoint level. Therefore, Part IV is only a sketch of how
the document's definitions will need to be modified. The
editors need to do more work on this, but the changes should
only be editorial at this point (all the substantial issues
now being addressed by Part I).
-------------------------------
Part I: Modifications to checkpoints 2.1 and 2.3
-------------------------------
The first part of this proposal replaces checkpoints 2.1 and 2.3
with four checkpoints. These checkpoints represent several ideas:
1) Not all content is rendered at all times. Automatic decision about
when to render "optional content" is preferred, but manual decision
by
the user may be required.
2) Structure is preferred (both the author's specified preferences and
the user's structured access), but unstructured access may be
required.
3) Rendering according to specification is preferred, but a source
view of text content may be required (e.g., because of user-side
error conditions, authoring errors, inadequate specification,
or incorrect user agent implementation). For example, the user
may have to look at URIs for information, HTML comments,
XML element names, or script data.
4) Local control of rendering is important; global configuration of
rendering preferences is convenient.
-----------
Checkpoints
-----------
Taken together, these four checkpoints are designed to ensure
access to all content.
a) For format specifications that the user agent implements, make
content available through the specified rendering process.
[Priority 1]
Note: The specified rendering process will also account for
format-defined interactions between author preferences and user
preferences/capabilities (e.g., the "alt" attribute, the
rendering order of nested OBJECT elements in HTML, test
attributes in SMIL, and the cascade in CSS). If a conforming
user agent does not render a content type, it should allow the
user to specify a way to handle that content (e.g., by launching
another application, by saving it to disk, etc.).
b) For text formats that the user agent implements, provide a
view of the text source. [Priority 1]
Note: Text formats include:
(1) all media objects given an Internet
Media Type of 'text' (e.g., text/plain, text/HTML, or
text/*), and
(2) All SGML and XML applications regardless
of Internet Media Type (e.g., HTML 4.01, XHTML 1.1, SMIL,
SVG, etc.).
The user agent should provide a source view for any
text format, not just implemented text formats.
c) Allow configuration so that, for each piece of unrendered content
"C" that, by specification, is intended for the user through the
user interface, the user agent alerts the user to the existence of
the content and provides access to the content. Provide access to
this content according to specification or where unspecified,
as follows:
(1) If C has a close relationship (e.g., C is a summary, title,
alternative, description, expansion, etc.) with another piece of
rendered content D, do at least one of the following:
(a) render C in addition to D,
(b) provide access C by querying D, or
(c) allow the user to follow a link to C from the context of D.
(2) Otherwise, do at least one of the following:
(a) render a placeholder for C that may be replaced by C,
(b) provide access to C by query
(e.g., allow the user to query an element for its
attributes), or
(c) allow the user to follow link in context to C.
[Priority 2]
Note: This checkpoint requires "element level" user control of
rendering. However, the configuration requirement is global;
the user may wish to turn off manual control entirely.
The specified rendering process will also account for
format-defined interactions between author preferences and user
preferences/capabilities (e.g., the rendering order of
nested OBJECT elements in HTML, test attributes in SMIL,
and the cascade in CSS).
d) For content that is rendered under well-defined conditions,
allow the user to configure the user agent to create those
conditions.
[Priority 3]
--------
Comments
--------
Comment 1) Proposed checkpoint (c) is only a Priority 2
checkpoint. This is because checkpoints (a) and (b), both
Priority 1, ensure access to all content. Checkpoint (c) provides
for in-context, manual access to content (that, when selected, is
rendered "according to specification" per checkpoint (a), or
through one of the specified mechanisms).
Comment 2) The term "equivalent" has been deleted from the
preceding checkpoints. Here's why: a format specification
includes markup features that may be used for a number of
purposes, including for the provision of equivalents per the
requirements of WCAG 1.0. The proposed checkpoints require the
user agent to make available all optional content to the user.
Some of the time, authors will have used those features to
provide equivalents.
Comment 3) The term "equivalent" should be replaced by "optional
content" in a number of other places in the document. For
instance:
a) The subhead under Guideline 2 needs editing to talk
about optional content, not equivalents.
<OLD>
Ensure that users have access to all content, notably
recognized equivalents such as text equivalents and
auditory descriptions.
</OLD>
<NEW>
Ensure that users have access to all content, including
optional content that may be provided to meet the
requirements of WCAG 1.0.
</NEW>
b) The prose of Guideline 2 needs editing as well, to convey
the staged access model and to use the term "optional content"
instead of equivalents.
c) Change "equivalents" to "optional content" in the following
Guideline 4 note: "The checkpoints in this guideline apply to
all content, including equivalents."
d) Do similar changes elsewhere in the Guidelines and in the
Techniques Document as well.
-------------------------------------------------
Part II: Modifications to checkpoints 2.6 and 2.7
-------------------------------------------------
Checkpoints 2.6 and 2.7 should be likewise modified to use the
concept of "optional content" instead of "equivalents".
<NEW 2.6>
Allow configuration to generate repair text when the user
agent recognizes that the author has failed to provide required
optional content. If the optional content is associated with
other content rendered by default, and that content is
included by URI reference, base the repair text on the URI
reference and content type. Otherwise, base the repair text on
element type information.
</NEW 2.6>
<NEW 2.7>
Allow configuration so that when the author has intentionally
provided empty optional content, the user agent generates no
repair text or generates repair text as required by checkpoint
2.6.
</NEW 2.7>
-------------------------------------------------
Part III: Definition of optional content
-------------------------------------------------
Optional content is content that the author does not intend the
user agent to render by default, but that the author does intend
to make available to the user through the user interface under
certain conditions. Some mechanisms for providing optional
content include the "alt" attribute and the OBJECT element in
HTML, and the test attributes of SMIL 1.0 and SMIL 2.0.
The rendering semantics (when and where) of optional content may
be well-defined in some cases (e.g., "alt" and OBJECT in HTML)
and less well-defined in others (e.g., "title" in HTML).
Note: The Web Content Accessibility Guidelines 1.0 requires that
authors provide text equivalents for non text content. This is
generally done by using the optional content mechanisms of a
markup language.
-----------------------------------------------------
Part IV: Changes to definitions imported from WCAG 1.0
and modified for UAAG 1.0.
-----------------------------------------------------
Checkpoints 2.4 and 4.6 use the terms captions, text transcript,
and collated text transcript, which themselves use text
equivalent, text element, equivalent, and text.
Checkpoint 1.3 uses the terms non-text element and text
equivalent, but applied to the user interface, not content.
How can we harmonize usage of these terms between content
and user interface?
ROUGH PROPOSAL:
a) Use the current definitions of text, captions, text
transcripts, and collated text transcripts.
b) Text element:
<DFN>
As used in this document a "text element" either
adds text to content or to the user interface. Both in
WCAG 1.0 and this document, text elements are presumed to
produce text that can be understood when rendered visually,
as speech, or as Braille.
A text element may consist of both text and non-text data. A
user agent may have to process a text element in order to have
access to the text characters. For instance, a text element may
consist of markup, it may be encrypted or compressed, or it may
include embedded text in a binary format (e.g., JPEG).
</DFN>
c) Non-text element:
<DFN>
A "non-text element" is an element in content or the
user interface that does not have the qualities of a text
element.
</DFN>
d) Text equivalent:
<DFN>
"A text equivalent is an equivalent created by one or more
text elements."
</DFN>
e) Equivalent: Use the WCAG 1.0 definition.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Wednesday, 21 February 2001 23:18:27 UTC