Re: A brief analysis of dynamically generated web pages and

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.

Received on Monday, 22 November 1999 17:59:07 UTC