W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Re: [Action] Proposal to address issues 394, 359, 358, 322, and 321 (checkpoints 2.1, 2.3, 2.6, 2.7, definitions)

From: Jon Gunderson <jongund@uiuc.edu>
Date: Thu, 22 Feb 2001 07:40:49 -0600
Message-Id: <>
To: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
First, I would like to thank Ian, Eric and Al for their work on this 
proposal.  They have spent a lot of time discussing the issues and as chair 
I appreciate their efforts.

QUESTION: What happened to the part of Checkpoint 2.3 that allowed for 
substitution of alternative content of C for the original C?  The proposal 
seems to talk about additional rendering, providing a link and query access 
to alternative content of C.


At 11:18 PM 2/21/2001 -0500, Ian Jacobs wrote:
>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
>    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.
>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]
>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
>   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?
>  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

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Thursday, 22 February 2001 08:38:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:29 UTC