- From: Charles McCathieNevile <charles@w3.org>
- Date: Sat, 20 Nov 1999 18:16:04 -0500 (EST)
- To: Nir Dagan <nir@nirdagan.com>
- cc: Scott Luebking <phoenixl@netcom.com>, w3c-wai-gl@w3.org
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