RE: Proposal for Checkpoint 2.1

I would agree that all views need to be accessible in the sense that the
content rendered in the view must also be made available to outside AT.
Obviously, a graphic is not going to be accessible to a person who is blind,
but the alt text of the graphic must always be available through the API to
the AT.

Just imagine the case where the user of an AT interface changes the browser
to a view that is not accessible, and can't get back!

Denis

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Ian Jacobs
Sent: Monday, May 01, 2000 12:04 PM
To: Jon Gunderson
Cc: w3c-wai-ua@w3.org; w3c-wai-pf@w3.org
Subject: 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 13:38:09 UTC