RE: The web processing model: ideas for an introduction

This is an excellent intro AND tutorial as well.   We could have used it a
long time ago as a tutorial for our own team.

I think we should

1) all read it carefully multiple times to see if there are any refinements
or things missing.
2) We should read it to make sure we all are on the same page with regard to
3) We should run this past EO and see if they can tune it at all - or make
it easier to understand (it is clear as a bell to me but I have kind of a
head start before I read it)

Very nice job Jason.
This will be a valuable tool to us and those reading the document.

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Depts of Ind. and Biomed. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu, http://trace.wisc.edu/
FAX 608/262-8848
For a list of our listserves send "lists" to listproc@trace.wisc.edu


 -----Original Message-----
From: 	w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]  On
Behalf Of Jason White
Sent:	Thursday, January 25, 2001 5:29 PM
To:	Web Content Accessibility Guidelines
Subject:	The web processing model: ideas for an introduction

In today's teleconference I proposed that an introductory section be added
to the guidelines, outlining the model of processing and interaction which
characterizes the web, and indicating the points at which issues of
accessibility may be addressed. Here are some preliminary ideas:

1. Content is stored, or generated, on a server.

2. It is requested by a client application.

3. Along the path from server to client application, there may be one or
more proxy servers.

4. The client application may reside on any kind of web-capable device,
and may comprise a number of software modules (including interfaces to
assistive equipment). Client devices may include desktop or mobile
computers, telephones, voice response systems, etc.

5. Any or all of the components comprising the model outlined above, may
reside in a single computer or be connected via a network. They may be
operated under the control of the content author, the user of the content,
or a third party (for example an internet service provider or a gateway
operator).
 6. The ne
eds and preferences of the user may be
satisfied:

a. On the server, by providing the same content in different formats (for
instance with the aid of conversion software). Any of the available
versions may be selected by explicit user action or by techniques of
content negotiation built into the communication protocol (e.g. CCPP).

b. On a proxy server, which may transform and filter the content. Again,
the proxy server may provide its own user interface or respond to content
negotiation protocols.

c. In the client application, which may apply style rules and/or provide
specific support for the rendering of particular content formats. The
client application may also filter or otherwise transform the content.

7. These guidelines specify that the content, as written by the author and
stored on the originating server, should meet certain requirements of
accessibility, for example by possessing an explicit logical structure
which is encoded in such a way that it can be processed in software, and
by providing text equivalents to medium-specific presentations, notably
sounds and images. This information may be used at any stage along the
processing pipeline (by the server, a proxy or the client application) to
transform the content into a presentation satisfying the user's needs and
preferences.

8. Input from the user may be communicated to a proxy server or, more
typically, to the originating server on which the content resides. It may
result in the retrieval of further content (for example through the
activation of a hypertext link), the submission of a form, a database
query or other application-specific actions. Such input may also be
processed by the client application, including scripts supplied by the
content provider.

9. These guidelines include requirements which ensure the available of
input mechanisms which can be operated by a variety of devices (keyboards,
pointing devices, speech recognition systems, etc.). This does not prevent
content providers from customizing the manner in which user interfaces
interact with particular input devices, but merely requires that
device-independent input methods be made available. As this discussion has
indicated, user input may be transmitted to the server (potentially via
one or more proxy servers) at a level of abstraction which is input-device
independent. Protocols of form submission can provide this functionality,
for example.

10. In addition to the foregoing, the guidelines include requirements
which aim to ensure that content can be readily understood by as broad an
audience as possible, and that documents and user interfaces alike are
designed in a consistent style which facilitates comprehension and
interaction by a wide variety of individuals, irrespective of their needs.


I suppose the above statements serve, in effect, as the outline of an
introduction to the guidelines as a whole. If they represent an
appropriate summary of our purpsoes and assumptions, then I am sure they
can be reworked, refined and, in essence at least, incorporated into the
document.

Received on Saturday, 27 January 2001 22:46:58 UTC