Re: A brief analysis of dynamically generated web pages and accessibility

Nir has correctly identified the basic problem of automatically providing
different versions - this problem is exactly the same as faced by mobile
devices which have an extremely diverse range of capabilities. The W3C work
on CC/PP is intended to address precisely this question, and hopefull in the
near future it will be possible to describe user requirements, preferences
and capabilities in terms of media much better, and serve content tailored
for that. An example from the mobile world is to serve just the outline of a
page (perhaps the top couple of header levels, and summaries of multimedia
objects) and to serve a single section on request.

The other problem that has been identified by Gregory and others is the
question of what is appropriate for individual groups of users. For example,
some people who have no vision are not interested in receiving images, and
don't care about the colour of text. Others have software which allows them
to distinguish classes of text in tones, or to render graphics in a tactile
or sonic format, or need to know how the content is being presented to their
colleagues, in order to talk about the same things. As I understand the
goal of this group, it is to produce guidelines which enable people to create
content once that can be used by people regardless of disability, rather than
ot create multiple forms of content for each different set of user
needs. That approach is necesasry in the case where it isn't possible to
create generally accessible content, and may sometimes be an optimisation for
reasons of implementation.

Charles McCN

The question that Gregory and others ahve 

On Fri, 19 Nov 1999, Nir Dagan wrote:

  One issue in generating dynamic pages tailored for the user,
  is the ability of the server to have useful information on 
  the user's needs.
  
  It seems to me that the current state of HTTP doesn't allow 
  to get enough information regarding needs of disabled people.
  
  The mechanisms available now to the server are:
  1. The client's "accept" "accept-language" and "accept-charset" request
  headers,
  2. The client's "user-agent" request header.
  
  The accept-language and accept-charset are the most used by 
  clients and servers, but they have no direct relation to accesibility.
  
  The "accept" header may be of some use for accessibility, but if the server
  wants to serve only different HTML pages, its use is quite restricted.
  
  The user-agent request header has two problems. One is that using it is not
  scalable
  from the server's point of view: the server has to study the particular
  abilities of 
  a growing and diversified set of user agents. The second problem is that
  even if the server
  recognizes the user agent, this is insufficient to tell what the user
  needs: I may very well
  want a page crowded with images when I am using Lynx as I have configured
  an external image viewer.
  
  Style sheets offer a mechanism to discriminate by "medium". (Either via the
  "media" 
  attribute of the <link> and <style> HTML elements, or internally in the
  stylesheet itself)
  
  However as Scott suggests, sometimes complicated transformations (not
  available in CSS
   but possibly available in XSLT) that are taken on the server side are
  desireable.
  
  It seems that a possible solution is to have a "user-agent-media" request
  HTTP header.
  (or "accept-media" ??) As it has a limited set of values it is much more
  scalable 
  than user-agent, and is a more natural way to apply style sheets on the
  server side. 
  
  Seems as an idea that fits the current slogan "CSS on the client and XSLT
  on the server."
  
  Regards,
  Nir.

Received on Saturday, 20 November 1999 18:16:14 UTC