- 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