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

Minor comments below. I support this approach.

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Wednesday, February 21, 2001 11:18 PM
> To: w3c-wai-ua@w3.org
> Subject: [Action] Proposal to address issues 394, 359, 358, 
> 322, and 321
> (checkpoints 2.1, 2.3, 2.6, 2.7, definitions)
> 
> 
> 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.

EH: Might be helpful to specify 'required' of whom in order to achieve what.
Otherwise, it makes one think of checkpoint priority definitions, which I
don't think are really intended here.

> 
> 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

EH: Not sure what you mean by "will...account" for. Do you mean 'should'? I
don't think that you mean must. Perhaps OK as is...

>       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

EH: I presume that 'specified rendering process' refers to the process
specified by the 'specification'. Or does it also include requirements of
this checkpoint as a kind of 'specification', which, of course, it is. I
think that we need to use the word specification carefully. I presume that
we mean specifications outside of the UA document.... Is that correct?

>       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).

EH: I looks like you are using the term 'according to specification' to
refer to spec outside of the UA doc and 'specified mechanism' to refer to
parts of the UA doc. Is this correct? Does it make sense.
> 
> 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

EH: If we wanted to keep the accessilibility focus, we might say "provide
accessibility-required optional content". Otherwise, what spec is doing the
requiring and do we have any business requiring non-accessibility repair?

>  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

EH: hyphen in 'non-text content'

> 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.
> 

EH: One might suggest editorial fine tunings to the definitions, but I am
basically satisfied. I don't see anything in this areas that warrants UAWG
telecon discussion at this time.

> -- 
> Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> Tel:                         +1 831 457-2842
> Cell:                        +1 917 450-8783
>

Received on Thursday, 22 February 2001 13:50:18 UTC