Re: A brief analysis of dynamically generated web pages and

In Gregory's model, as I understand it, the user (client) has access to
specialised style sheets, which suit their individual needs. They can apply
that to well-structured content to get  document htat fits their personal
requirements much more precisely than a server-sided approach can approximate
the requirements of a class of users. In addition, the client can determine
whether they want images, or audio content, or other separate pieces at the
time they read. They can use bookmarks that are the same whether they are
sighted, deaf, blind, etc.

In some cases there is value in serving content of different types according
to diffferent requests. (An obvious one is the tablin service that linearises
tables and adds headers according to specified options). But in many cases
the best solution is still to serve well-created content the first time
around.

Charles

On Mon, 22 Nov 1999, Scott Luebking wrote:

  Hi, Gregory
  
  I'm not sure we are using the same analysis.  Let's break this up into
  two pieces.  First there is the selection of what is delivered to the
  browser.  The server is making the decision here.  In your model, which
  is also a version of many-sizes-fits-all approach, the server generates
  a web page and chooses the style sheets all of which are sent to the
  browser.  In my model, the server looks at the information, chooses a
  format and generates the web page which is then sent to the browser.  In
  your model, the server is limited to the style sheets its knows about.
  In my model, the server can use some intelligence in creating the web
  page.  As a result, the model I'm talking about for the server side is
  much more flexible than the server side model your talking about.  (If
  your model uses inline style, what is the benefit of you model over my
  model?)  My model has the added benefit of avoiding having to worry about
  the differences among implementations CSS without losing any flexibility.
  
  When a server is interacting with information, it has a better understanding
  about the purposes or concepts which relate to the different aspects
  of the page.  For example, the server would better know which links are
  for advertising and which are for the web site.  As a result,
  the server can group links by categories.  Or, for example, the server
  could know which functions are probably most likely to be used and
  could improve blind user's efficiency by letting them be activated
  by keyboard events.  When a page is created, these various concepts
  of relationships on the page disappear.  The DOM cannot capture them.
  
  To understand what I'm discussing, you need to understand the
  "concept-barrier" that is a problem in all of computer science
  including access technology.  This is a tough one for many people
  to understand.  Let me know if you want some elaboration.
  
  Scott
  
  
  > aloha, scott!
  > 
  > you are still, in my opinion, attempting to impose a many-sizes-fits-all policy
  > on content delivery -- an approach which is doomed for you cannot possibly
  > predict (nor can you reasonably expect content providers to know) what the
  > individual blind user needs in order to make sense of, and interact with, the
  > content being delivered...
  > 
  > yes, the server should assume half of the burden (which can be done via
  > responsible browser sniffing, so that the stylesheet and inline style
  > declarations delivered with the content, for example, won't crash the
  > requesting UA nor cause the content to be rendered in unexpected and
  > incomprehensible ways), but the client side should handle the quote blind
  > tailorization unquote -- particularly if the requester is using an AT that can
  > access his or her user agent of choice's DOM...  and even if the blind
  > individual requesting the content isn't using a user agent that has implemented
  > the DOM, or is incapable of supporting it, then an intermediary proxy, of the
  > sort that len kasday and i have been talking about in WAI circles since 1997,
  > could do the client side work for a client that doesn't have the resources or
  > access to the DOM needed by the UA slash A.T. combination described in my
  > scenario...  of course, the proxy would have to be heuristic, and constantly
  > updated, so as to take into account new scenarios and combinations, but 
  > 
  > gregory.
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Monday, 22 November 1999 20:15:34 UTC