Re: Proposal for Checkpoint 2.1

At 09:53 AM 2000-05-02 -0500, Jon Gunderson wrote:
>I propose the following checkpoints and questions for discussion at today's 
>telecon for improving checkpoint 2.1:
>
>====================
>Checkpoint 2.1a Ensure that the user has access to all content.  [Priority 1]

AG::

How is this different from Guideline 2?

I am coming around to the view that we should separate out the content of
the markup from the content marked by the markup in the checkpoints.  Let
the Guideline address the information content as a whole, and the
checkpoints address separately the classes of content that people may think
of as different.

So:

Checkpoint:  Ensure that the user has access to all properties encoded in
the markup.
Note: the entity type name in XML or HTML is included, along with
attributes, in the scope of such properties.

Checkpoint:  Ensure that the user has access to all data contained within
or referenced from the markup.

[Guideline: Present content appropriately.  Note: text view of inline .AU
or .GIF does not satisfy the above checkpoint.]

Checkpoint:  >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 many user agents, but is not a requirement for satisfying this 
>checkpoint if resource information is available through the combination of 
>other views offered by the user agent.
>
>2) When a users change the default rendering configuration of a viewport 
>(colors, style sheets, font size and style...) the viewport must provide 
>access to the entire content of the view.  For example, in a graphical user 
>agent this may require the adding of scroll bars to the viewport so the 
>entire view can be rendered through the view port.
>

AG::

Consider moving this to the navigation section.  There is a generic
requirement to provide navigation functions when the rendered content of a
view exceeds the concurrent display capability of the viewport.  Add a note
that this is almost always the case in a variety of adaptive modes.  The
fact that this includes when the user has adjusted the rendering rules
should be a note, not a checkpoint.  There can be a note with a cross
reference under Guideline 2.

>=================
>Checkpoint 2.1b Make available alternative equivalents to primary content 
>in all views where alternative equivalents are not rendered by default. 
>[Priority 1]

AG::

It is hard to imagine justifying even a Priority 2 for this strong a rule.
Clearly if each alternative equivalent is available in some usable view,
then there are no Priority 1 failures.

Consider the following alternate development:

Guideline: Stay as close to the author's presentation concept as you can.

Checkpoint: Present alternative equivalents in the same context as what
they are alternatives for.  Note: see 2.6 for a corollary for temporal media.]


Checkpoint: Make it possible to present multiple equivalents at the same time.

Note: Usually equivalents substitute, but there are access-required use
cases where they are presented in addition to the prior alternative.
>
>Note: For example, substituting the ALT text associated with an image 
>and/or rendering a link to the LONGDESC resource of an image for the 
>original image.
>
>=================
>Checkpoint 2.1c 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 another view, like a source or a DOM tree 
>view of the resource, the portion of the resource selected in the original 
>view is also selected in the source or DOM tree view.
>
>QUESTIONS: Should this be a checkpoint or a just a technique technique?  Is 
>this an accessibility issue?

AG::

Checkpoint.  At least P3, possibly P2.

Technique: support navigating to "here, in view X."  Equivalently, view
selection from context menu would move to synchronized location in another
view.

>SPECIAL CASE QUESTION: What about content generated by scripts, there may 
>be no easy identification of the information in a source view.

AG::

What does the script write to?  Doesn't it write into the document object,
and it gets rendered from there?  Therefore there is the basic DOM-dumper
procedure that give you a source view of whatever the script has changed
the virtual source to.

>
>=================
>Checkpoint 2.1d 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.1c.  AG and JW have said this is a common 
>technique for people with disabilities to understand the content of an XML 
>document.
>
>QUESTIONS: Is this too specific of a checkpoint?  Does it solve an 
>accessibility problem?

AG::

Yes (too specific), and yes (solves accessibility problem).

This is a technique.  Does not belong as a checkpoint.

This technique should be described in the UAAG in conjunction with
Guideline 2.  It demonstrates that Guideline 2. is readily achievable, does
not impose undue burden.  It is a generic strategy that is applicable to
XML documents and is expected [current estimate of PF WG, at least.] to be
necessary as part of the XML accessibility-support system.

It does not deliver the very best in usability, but for many pieces of
information it is better than a raw source view.  It is expected to be
needed frequently when neither the user agent nor the author has
anticipated the combination of user needs and content structure that
happens in practice.

Sample of discussion from PF call:

<quote>

AG: generic UA doesn't need to provide look up tables [friendly
translations] for
all media for all dialects of XML, but since text in XML,
ought to give you original text as one of your choices

JW: basically agree, but only a minimal requirement;
sometimes the markup is all you have--especially if you
don't have a stylesheet!

AG: UA should be providing a minimal requirement, and not
assume that there is a stylesheet, let alone a good one;
access to attribute information provides basis for overlay
of client stylesheet

RS: agree; good target for developers; if want to render
more, go for it!

<end quote>

It is something that is easy for the User Agent to do that puts a floor
under the usability level of the practically-available presentation styles.

This is a rough summary of our discussion on the PF call yesterday, where
there was general agreement.  No formal vote has been taken or documeted
position taken.

Related recommendation:

Move all discussion of source view and property inspection to techniques
discussion in the guidelines document.   This section should say the
following things:

Property inspection is expected to be significantly more usable than source
view for many properties.  

Source view may be the most usable readily-achievable view for some content
such as embedded fragments of style and script languages.

Al

>
>
>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 Tuesday, 2 May 2000 12:45:52 UTC