- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Thu, 22 Feb 2001 07:40:49 -0600
- To: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
Ian,
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.
Jon
At 11:18 PM 2/21/2001 -0500, Ian Jacobs wrote:
>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
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
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