Re: Proposal for Checkpoint 2.1

Responses in JRG:

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

JRG: I think saying that all views do not need to be accessible is 
problematic.  A developer could say that the source view is the accessible 
view for their application and I don't need to make any other views 
accessible.  I think we need to have a requirement that all views are 
accessible.

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

JRG: AG and JW think this is a critical need.  Others on telecons have said 
this is important too.  I agree though that most people will not know what 
to use it for.

>
> > 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.
>
>I don't understand this now. Why is it only necessary to provide a
>scrolling mechanism when the default config has been changed?

JRG: I should have said maybe.  For example, in a graphical user agent this 
may require
the ability of the user to scroll the contents of a view in a view port so 
that information rendered in larger fonts can still be viewed.

The example is just a technique.  In general we would want to encourage 
implementations the minimize horizontal and vertical scrolling.

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

JRG: I used the word substitute to emphasize that the alternative must be 
in the same view as the primary content.  Substitute may not be the best 
word, I would encourage other suggestions that make clear the requirement 
of rendering the alternative equivalents in the same view as primary content.

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

JRG: This is the same as 2.6 and I with draw the proposed 2.1c.

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

JRG: This seems to be a requirement from the group.  But if the group 
doesn't want it, we can move it to the techniques document.

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

JRG: I agree, but many people have said this information is very valuable 
to the few users with disabilities that understand it.

>  _ Ian
>
>
>--
>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
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
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 Monday, 1 May 2000 11:52:05 UTC