Re: The web processing model: ideas for an introduction

Jason,

	Very nice beginning to the introduction! This would not be an introduction
for the "general public" of course, but only to those familiar with the
terms and meanings within.

     One glaring omission: in #4, insert "television" between computer and
telephone. 

	Another suggestion: Combine 1, 2, and 3, and add at the end of 3, add the
definiton for proxy server now in 6b.  

					Anne


At 10:29 AM 1/26/01 +1100, Jason White wrote:
>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 Friday, 26 January 2001 06:30:51 UTC