Re: Proposal for Checkpoint 2.1

Jon Gunderson wrote:
> 
> 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.

I don't think I agree. Maybe part of the problem is whether we're 
talking about "view" or "viewport".
 
> > > 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 think this is covered by access to content. Just indicate as a
technique
that people could select an element and query attributes.

[snip]
> >
> > > 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.

Ensure that all equivalents are available in the same view.

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

I hadn't heard a requirement for two or more synchronized views.

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

I still think this should only be a technique.

 _ 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 12:03:52 UTC