- From: Scott Luebking <phoenixl@sonic.net>
- Date: Tue, 1 Jan 2002 08:41:34 -0800
- To: w3c-wai-gl@w3.org
Hi, I think that it is important to consider both the results and the mechanisms. This avoids the tendency of coming up with desired results and forgetting how much work on the part of web page developers to achieve the results. T.V. Raman has done some very good work on Emacspeak. However, there is another user base that needs to be considered. These are people with disabilities who want to learn the most minimal amount of technology and access technology in order to get access to information and interact. Many of them would not be interested in learning what XSLT transformations are possible and how to choose from them. Another other assumption is that a document will have the appropriate structure. Why do web page developers want to put the effort into creating the appropriate structure? Often their criteria (and their bosses') are more like how does it look, does it work the way it is suppose to and how will it work on the major browsers. Appropriate structure is not high on priorities because what does it actually do that is as important as the other goals mentioned? I don't believe that many disabled people who have only minimal interest in technology would really want to hassle with client-side transformation tools. It adds more to what they have to learn. They have to worry about what client-side tools work with what access technology doing what tasks. I believe the focus should be more on the minimally teachnologically inclined disabled people. Scott > Scott Luebking writes: > > > > I've been kind of exploring some ideas not to dissimilar to what > > you are suggesting about abstracts as a way to quickly size ulp > > a web page when browsing by voice or on a small screen. A format > > that I keep coming back to that could appear at the beginning of appropriate > > web pages would be something like: > > > > TITLE > > > > INTRODUCTION / SUMMARY > > > > INDEX OF SECTIONS ON PAGE > > I suggest we would do better by separating the desired result from the > mechanics of how it is implemented, whether by a server, a proxy > server, the user agent or whatever it may be. We can then provide > techniques for implementing it in those parts of the process over > which the content developer has control. The question of whether this > is necessary will depend on (changing) assumptions regarding the > technology available downstream, in gateways, proxy servers and user > agents. The issue of how those assumptions are to be determined over > time belongs to a separate thread of discussion (cf. minimal user > agent capabilities). > > Incidentally, I am currently running a version of T.V. Raman's > Emacspeak software that will apply a user-selected XSLT transform to > each incoming HTML document. It can linearize tables, unravel nested > ftables, create an outline of the document and so forth. Given > appropriate structure in the original it is perfectly possible to > satisfy the presentational requirements quoted above (that is, title > followed by summary, outline, then main text). > > Perhaps the best solution would be to argue, as always, that authors > need to include the relevant structure/semantics in the content, and > fthen they can decide whether to implement some of the transforms > themselves or leave it to proxy servers and user agents. Likewise, > accessibility advocates will need to think strategically about whether > it would be more effective from a practical point of view to create > more client-side transformation tools and deliver them into the hands > of users, than to encourage authors to implement server-side > transformations on grounds of accessibility. > > In either case, the server-side techniques should be included in our > techniques documents and those who are interested in working on the > details should collaborate with Wendy, Cynthia and other members of > the group with specific interests in this area.
Received on Tuesday, 1 January 2002 11:41:37 UTC