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

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

From: Ian Jacobs <ij@w3.org>
Date: Wed, 21 Feb 2001 23:18:23 -0500
Message-ID: <3A94930F.35EF63B4@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:38 GMT