W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2000

content negotiation (was Re: A proposal for changing the guidelines)

From: Nir Dagan <nir@nirdagan.com>
Date: Sun, 12 Mar 2000 23:57:28 -0500
Message-Id: <200003130454.XAA04511@vega.brown.edu>
To: w3c-wai-gl@w3.org
It is in my view very important to distinguish between
1. What the server serves to the client.
2. What are the internal workings of a server.

The WAI guidelines concentrate on the first and rightfully so.
It doesn't matter whether, for example, a served HTML page was written 
using Pico or Notepad, or was generated by mechanism that converts 
SGML documents written in my private DTD by using a DSSSL style sheet.

Also the user shouldn't care whether a page was generated dynamically 
or not. The claim that dynamically generated pages are a useful(?)
technique to keep multiple versions up to date is irrelevant. What is 
relevant, and is mentioned in the guidelines, is that if various forms are 
available they all should be up to date. How the server achieves that
should not be a part of guidelines but may be addressed in a techniques 
document.

A question that the guidelines may address is whether it is useful
to return different forms of the same content to different users
in regard to accessibility issues. 

The position of the guidelines as they are now is that of universal design,
namely serving an identical content-document to all requests, and allowing 
the client to select a style sheet (among those provided 
by the server, and those that the client or user provides).

It could be argued that this is not good enough, and that 
some form of content negotiation would be useful. 

These are the options available now:
1. content negotiation based on accept-* request headers:
   problems: does not cover accessibility related issues well
             poorly implemented by clients.
2. content negotiation based on user-agent request header:
   problems: does not represent user's preferences faithfully,
             and in particular those preferences that are related 
             with accessibility.
3. client side scripting:
   problem: almost all clients allow turning it off,
            thus anyway requires a universal design default page.
4. creating a form on the website in which the user reports his preferences.
   problem: quite tedious for the user if he has to do this on every website.

Given the above, as well as the unfortunate fact that many content providers 
implement methods 2. and 3. poorly, WAI chose to support universal design
and rely on client processed style sheets to get the content presented in 
a useful manner to the user.

The long run solution would be a combination of style sheets with improved 
content negotiation, such as informative "client profiles." 
However as long as the work of these new methods reaches some sort of 
tangible form, in my view, there aren't any substantial changes that can 
be introduced o the guidelines.

Regards,
Nir. 
===================================
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI
USA

http://www.nirdagan.com
mailto:nir@nirdagan.com
tel:+1-401-863-2145
Received on Sunday, 12 March 2000 23:54:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:01 GMT