Re: Search function options

Gregg Vanderheiden writes:
 > In WCAG 1.0 there was
 > 
 >  
 > 
 > 13.7 If search functions are provided, enable different types of
 > searches for different skill levels and preferences. [Priority  3]
 > 
 >  
 > 
 > this doesn't appear specifically in 2.0
 > 
 >  
 > 
 > this sounds like it should be part of either OPERABLE or UNDERSTANDABLE.
 > I think it goes in understandable since it sounds like the different
 > forms are provided because a person wouldn't understand a more complex
 > form.   

Agreed. This is part of a larger issue, however. Forms are only an
instance of the more general concept of a user interface, so at a
minimum it should read:
Provide interfaces customized for different skill levels and
preferences.

Then the question is asked what the success criteria should be. As I
don't have a clear answer, I won't try to draft any here. Instead, I
shall raise several issues surrounding this proposed checkpoint which
I think need to be resolved along the way.

By way of background, it should be noted that (any appearances to the
contrary notwithstanding) the technologies underlying the web are
evolving, and indeed quite rapidly. Two examples may be briefly
mentioned. First, the W3C is already becoming involved in the
development of standards to support so-called "web services". The
basic idea, as I understand it, is to foster application
interoperability below the user interface level. As Gregg suggested at
a recent teleconference, one approach would be to limit our guidelines
only to web content that provides its own user interface; but, as he
also recognized, this has the disadvantage that content which operates
below the user interface level may not then have the necessary
semantics and abstractions to support accessibility, even if the
underlying markup language follows the XML accessibility guidelines
and hence supports the required features. Moreover, there are
checkpoints in our guidelines which need not be restricted to content
that "comes with its own interface", whatever that means. Examples
include most of guidelines 1 and 5; checkpoint 4.1 also applies to any
content that contains text, even if it is destined to become part of a
larger interface.

The second trend worthy of note is the development of user interface
abstractions, for example in XForms, and the growing support for
constructing user interfaces customized for different device types,
including audio (VoiceXML), visual (XSL formatting objects) and so
forth, not to mention handheld and mobile applications.

In such an environment I think our guidelines need to be very clear as
to what requirements apply in different situations. Also, there are
now more options available in customizing user interfaces to meet
various user requirements and to adapt to the context in which the web
content is being delivered.

I would suggest a break-down along the following dimensions:

1. It should be made clear to a reader of the guidelines which
   checkpoints presuppose that the content author has a significant
   degree of control over the user interface, and which are applicable
   to scenarios in which this is not the case, including web services.
   This may of course be evident enough already, but if not then we
   need to clarify it.

2. Guideline 1 essentially requires that sufficient structure and text
   equivalents be included to enable a user agent, a proxy server or
   other application processing the web content to adapt and customize
   the interface. Of course, the author may, and in practice often
   does, provide style sheets or "alternative forms" of the content
   for the purpose of enhancing and customizing the interface. When
   this is so, there are two interrelated dimensions of customization
   relevant to our guidelines, viz.:

a. customization to suit different user needs and/or preferences.

b. customization to enhance the quality of the interface for one or
more device types.

Of course, both categories are strongly connected, in that strategies
intended for one type of customization will often benefit the other.
For example, simple interfaces with few options available at any given
moment, may be easier to present on devices with small screens. They
are also of undoubted benefit to users with certain cognitive
disabilities.

Thus our guidelines need to say, in broad terms:

If you plan to customize the interface (instead of just allowing the
default user agent processing of the content format to take effect)
then we recommend that the user interface be enhanced along two
dimensions:

a. to accommodate different skill levels and user preferences;

b. to accommodate different device types.

Much of this belongs in guidelines 2 and 3, though at present I am not
sure how best to formulate these requirements as checkpoints. Another
interesting question is: under what conditions should the author be
required (for minimum conformance) to enhance the user interface in
either or both of these ways? Can we establish general criteria here?
I can only offer quite general observations at present.

Obviously, if there are good grounds for believing that, without
customization on the author's part, the default presentation created
by particular types of user agents won't be satisfactory, then there
are good grounds for the author to offer appropriate interface-level
enhancements, including, where appropriate, the provision of multiple
interfaces.

There may also be some kind of complexity threshold beyond which it is
advisable to offer a simpler alternative, but I suspect this is likely
to be another case of "the interface has been reviewed and found to be
as simple as is appropriate for the task, or a simpler alternative has
been provided" (cf. checkpoint 4.1 in current draft).

To summarize, I have identified two dimensions of user interface
customization and argued that both should be treated in our
guidelines. I have also argued that it may be necessary to clarify
which of our checkpoints apply to content that doesn't include its own
user interface, and which presuppose that a significant  degree of authorial
influence over the interface is possible.

Received on Sunday, 28 April 2002 04:44:26 UTC