Re: Proposal for Checkpoint 2.1

Jon Gunderson wrote:
> 
> The discussion of checkpoint 2.1 has raised a number of issues on it's
> meaning and what is needed for conformance
> 
> I think the group has consensus on the following issues:
> 
> 1. Alternative equivalents should be available through the User Interface
> in place of or in conjunction with primary content
> 
> 2. Users need access to all content

Yes.
 
> 3. All views need to be accessible

I don't think this is true. Some views could not be accessible,
as long as the user can get equivalent functionality in other views.
Just like for the documentation: some documentation may be inaccessible
as long as at least one version is.
 
> 4. A source view is one way to make content available, but not the only way
> it should be made available

This is a comment on 2.

> 5. Access to the attributes of an element is useful and should be easy for
> the user to obtain.

This is a special case of 2.
 
> I like Ian's [1] splitting out the alternative equivalent part of the
> checkpoint into a separate checkpoint.
> 
> I would like to propose the following 5 checkpoints to help make the
> requirement for checkpoint 2.1 clear.  The proposal is based on the
> comments that I have hearing for the past couple weeks.
> 
> Proposal:
> 
> Checkpoint 2.1a Ensure that the user has access to all content.  [Priority 1]
> 
> Note on 2.1a:
> 1) The combination of views offered by a user agent must provide access to
> all author supplied resources.  A source view is typically one of the views
> offered by a user agent, but is not a requirement for satisfying this
> checkpoint if resource information is available in the combination of other
> views.

Yes, that seems ok.
 
> 2) When a users change the default rendering configuration (colors, style
> sheets, font size and style...) the view must provide access to all the
> content defined for that view.  In a graphical user agent this may require
> the ability of the user to scroll the contents of a view in a view port.

I don't understand this now. Why is it only necessary to provide a
scrolling mechanism when the default config has been changed?
 
> Checkpoint 2.1b Allow the user substitute alternative equivalents for
> primary content in views where alternative equivalents are not rendered by
> default. [Priority 1]
> 
> Note: For example, substituting the ALT text associated with an image
> and/or a link to the LONGDESC resource of an image for the original image.

I think "substitute" is too strong. Is it sufficient to provide
alternative content in addition to (e.g., in a tool tip) primary
content? Can we just say "Ensure that alternatives are available"?
 
> Checkpoint 2.1c For synchronized alternative equivalents, provide a
> synchronized view of the alternative equivalent with primary
> content.  [Priority 1]
> 
> Note: This supports the current checkpoint for a means to provide
> positioning of a separate view in checkpoint 4.7

Checkpoint 4.7 gives very precise instructions for graphical
positioning. The proposed 2.1c, makes a larger requirement.
Hos is 2.1c different from 2.6?

  "Allow the user to specify that text transcripts, 
   collated text transcripts, captions, and auditory
   descriptions be rendered at the same time as the 
   associated auditory and visual tracks. Respect
   author-specified synchronization cues during rendering."

> Checkpoint 2.1d Provide synchronized views of content. [Priority 2]
> 
> Note: If a user agent provides more than one view of content, allow the
> user to synchronize the views.  For example, when an element is selected in

> one view and the user switches to a source or a DOM tree view of the
> resource, the portion of the resource associated with the selected element
> is also selected in the source or DOM tree view.

I don't think we should add this checkpoint to the 
guidelines at this time. Synchronized views are undoubtedly useful, but 
this is a brand-new requirement. I'm pretty sure this is covered
in the techniques document. Can we just consider it a technique?
 
> Checkpoint 2.1e Provide access to only the attributes of a selected
> element. [Priority 3]
> 
> Note: In some cases the user needs access to the attributes of a selected
> element to determine the purpose or relationship of the element to other
> elements in a resource.
> 
> This is priority 3 since it is a convenience function.  The information
> would be required to be available through the user interface in 2.1a and
> partially supported in 2.1d.  AG and JW have said this maybe a common
> technique for XML, until more is understood about how XML will be used and
> made accessible.

I don't think this will be useful to many people in practice. How
many users know that an attribute is, let alone attributes of an XML
application they've never used before? This is a special case of
checkpoint 2.1a that I don't think needs its own checkpoint. I propose
instead that we suggest techniques that ensure that this is done.

 _ Ian


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

Received on Monday, 1 May 2000 11:22:34 UTC