Re: Does the user know for sure whether the page is dynamic or static?

Do dynamic pages have good english titles that are directly relevant to
their contents?
I find it very difficult to find titles for pages...

jay@peepo.com

Jonathan Chetwynd
Special needs teacher / web accessibility consultant
education and outreach working group member, web accessibility initiative,
W3C
----- Original Message -----
From: Al Gilman <asgilman@iamdigex.net>
To: <w3c-wai-gl@w3.org>
Sent: Sunday, January 23, 2000 3:55 PM
Subject: Re: Does the user know for sure whether the page is dynamic or
static?


> At 10:13 AM 1/23/00 +0000, Jonathan Chetwynd wrote:
> >My concern is that urls should be simple and that the content should be
> >reproducable as well as easy to understand.
> >(please do not comment on mine, it's a known disability.)
> >
> >If a 'blind' person was discussing a page with a sighted one, it seems
that
> >one is possibly creating an area of confusion. If the pages are generated
> >dynamically this could be unacceptable.
> >
> >eg: about one year ago I was considering buying an Apple notebook and the
UK
> >prices quoted online were 50% of market value.
> >Unfortunately(?) they refused to honour these.
> >
>
> This is a very good issue, but having all URIs refer to static resources
is
> not the solution.
>
> The last time this one went around on www-talk can be found in a thread
> indexed at
>
>  <http://lists.w3.org/Archives/Public/www-talk/1999MayJun/thread.html#38>
>
> The thread carries over into the following July-August archive, too.
>
> I am not saying that the present technology is perfect. or that the
> industry is in consensus on how the system should work in this area.  The
> semantics of URIs generate heated conflicts among people of deep knowledge
> and general good intentions.  The lack of a clear roadmap for application
> of schemas and namespaces is coupled to this disunion in the community.
>
> Many of the references [call them bookmarks, favorites, links or whatever]
> that one wants to save are to services that tell one new things on each
visit.
>
> The general semantics of a URI-reference is that it is a handle or
> representation of a query;  Depending on the query the response to the
> query may be uniquely determined no matter when the query is asked, or it
> may change as time rolls on.  This is not always discernable from the text
> of the URI-reference itself, and particularly not from the scheme and
> syntax of the URI-reference itself.
>
> Pedantic point:  There is a class of URI schemes known as URNs.  Some of
> these are specifically designed as an attempt to have better understanding
> of the stability of the information identified from the reference itself.
> On the other hand, this technology has not won widespread use yet.  Hence
> it is not clear that our issue of interoperating people with different
data
> views (GUI and speech, for example) is going to be solved by the universal
> adoption of URNs.
>
> The need to be able to synchronize between people who are accessing
> information is very real, but forcing all URLs to refer to static
> information is overkill and would accomplish a total disconnect between
our
> set of rules and the Web run by money.
>
> The distinction between the "data date" and "report date" in accounting
> printouts is pretty widely understood.  What we need to be working with is
> a similar distinction.  We need a way for people to be able to be sure
that
> they are accessing the same information, even when it is presented
> differently.
>
>
> One interesting fact is that although one does not necessarily know from
> the URI-reference in the referring document whether the resource
identified
> is static or dynamic, if HTTP is used to its best, you do know from the
> response how dynamic the response is.  There are effectivity metadata
> fields defined for the HTTP headers that can make this clear.
>
> The blind discussant and the sighted discussant need to compare
identifying
> attributes of the documents they hold, not the links they exercised.
>
> The response of the system should be predictable; but not necessarily
static.
>
> Al
>
> >
> >jay@peepo.com
> >
> >Jonathan Chetwynd
> >Special needs teacher / web accessibility consultant
> >education and outreach working group member, web accessibility
initiative,
> >W3C
> >----- Original Message -----
> >From: Charles McCathieNevile <charles@w3.org>
> >To: Scott Luebking <phoenixl@netcom.com>
> >Cc: <nir@nirdagan.com>; <w3c-wai-gl@w3.org>
> >Sent: Sunday, January 23, 2000 2:22 AM
> >Subject: Re: XML and accessibility
> >
> >
> >> A simple question can resolve whether there are different needs for
> >> dynamically generated pages And statically generated ones:
> >>
> >> Does the user know for sure whether the page is dynamic or static?
> >>
> >> If the user cannot tell whether there is a difference then there is no
> >> different user need. In cases where t information is being updated as
the
> >> user is reading it, such as a stock-market ticker that is running, or
some
> >> scrolling text, then there are rrequirements that the user can pause
the
> >> motion.
> >>
> >> Charles McCN
> >>
> >>
> >> On Sat, 22 Jan 2000, Scott Luebking wrote:
> >>
> >>   Hi, Nir
> >>
> >>   The reason I said that the suggestion about extending XHTML is
> >>   simplistic is that there needs to be more research into what problems
> >>   blind people have using web pages.  The issue of navigation bars is
> >>   actually a specific example of a more general problem that blind
people
> >>   have in navigating through web pages.  In general, blind people will
> >>   work more efficiently when web pages are organized along lines of the
> >>   importance of semantic information.  In the case of navigation bars,
> >>   navigation bars are of less semantic importance and it would be
better
> >>   to put them after the more important information of the dynamically
> >>   generated web page.
> >>
> >>   Please remember that the discussion is about dynamically generated
web
> >>   pages.  This almost automatically implies that some level of
programming
> >>   is involved.
> >>
> >>
> >>   Since there has been little discussion on what is needed for web
pages
> >>   designed for blind users, it is not very easy to conclude how much
> >>   effort is needed in developing them.  Also, having a separate web
page
> >>   for blind users might simplify development of web pages for sighted
> >>   users.  So, it might be that a larger, complex problem of developing
> >>   dynamically generated web pages for both blind and sighted user could
be
> >>   replaced by two smaller, simpler problems.
> >>
> >>
> >>   I would agree that the guidelines should stick to principles or
axioms.
> >>   The question to be resolved is whether there is the same of set of
>
> >>   axioms for stored pages as there is for dynamically generated web
pages.
> >>   This cannot be answered until there is better understanding about
what
> >>   is needed in web pages dynamically generated for blind users in order
> >>   that they can can be both efficient and accurate when using the web
> >>   pages.
> >>
> >>
> >>   In terms of dynamic web pages for blind users, it is irrelevant
whether
> >>   the HTML was generated from XML, databases or any other data source.
> >>   The more important aspect is that the resulting HTML has the
appropriate
> >>   information and structure needed by blind people using the
dynamically
> >>   generated web pages in order to be efficient and accurate when using
the
> >>   web pages.
> >>
> >>
> >>   Scott
> >>
> >>
> >>   > At 02:45 PM 1/22/00 -0800, Scott Luebking wrote:
> >>   >
> >>   > >I'm sorry to say, but your suggestion of extending XHTML for
webbish
> >>   > >constructs is rather simplistic.
> >>   >
> >>   > Yes of course. But I would like to recall that there was a big
> >discussion
> >>   > at some point of how to mark navigation bars exactly for the
purpose
> >of
> >>   > allowing moving them around by the user agent.
> >>   >
> >>   > Simplicity is a virtue, not a drawback. If one wants that a wide
> >>   > public of content providers will create accessible websites,
> >>   > one should create simple rules, from the content provider's point
of
> >view,
> >>   > for acheiving it. Returning different documents based on the
request
> >>   > variables
> >>   > has its virtues, but is very demanding from the content provider.
Only
> >very
> >>   > large
> >>   > websites that hire professional programmers can afford that.
> >>   > Eventually every kid and every housewife will have a website, and
we
> >want all
> >>   > of these websites to be accessible.
> >>   >
> >>   > >
> >>   > >I don't quite understand your comment on it being preferable that
WAI
> >>   > >not create guidelines for using given specifications.  It would
seem
> >that
> >>   > >the guidelines/techniques do just that, e.g. recommending use of
the
> >LABEL
> >>   > >tag, not using TABLE for layout, etc.
> >>   >
> >>   > I think that the Content guidelines should stick to principles or
> >axioms of
> >>   > accessible design. And that there should be a set of techniques
that
> >gives
> >>   > the "how to do" stuff. These techniques may very well include XSLT
> >stuff.
> >>   > By their nature the techniques are evolving over time while the
axioms
> >stay
> >>   > fixed.
> >>   > This is very much how the guidelines are organized now.
> >>   >
> >>   > This is also very good for WAI's work directly. It can evaluate
other
> >>   > W3C proposals against the "WAI axioms".
> >>   >
> >>   > I didn't say WAI shouldn't give these techniques. I said that it
> >shouldn't
> >>   > be the major and only effort of WAI. The main effort should be in
> >getting the
> >>   > other W3C recommendations to take into account accessiblity in the
> >first
> >>   > place.
> >>   >
> >>   > When WAI started alt was not a required attribute in <img> in HTML
> >(then
> >>   > HTML3.2),
> >>   > so it was quite urgent to state that HTML pages without alt in
<img>
> >are
> >>   > not accessible.
>
> >>   > Now by having a better HTML recommendation (HTML4.0), we achieve
much
> >more
> >>   > on the alt front than a hundred techniques documents, simply
because
> >there
> >>   > are hundereds of more people
> >>   > who validate their HTML pages without reading WAI documentation at
> >all.
> >>   >
> >>   > Excuse me again for the rather simplistic example. It disregards
the
> >fact
> >>   > that writing
> >>   > the alt text well is also very important; but I hope it is
> >illustrative still.
> >>   >
> >>   > I think we are standing in a begining of a period where lots of
> >proposals
> >>   > of XML
> >>   > applications/modules will be in the air. WAI should be alert to
> >influence
> >>   > those in time.
> >>   >
> >>   > Regards,
> >>   > Nir.
> >>   >
> >>   > ===================================
> >>   > Nir Dagan
> >>   > Assistant Professor of Economics
> >>   > Brown University
> >>   > Providence, RI
> >>   > USA
> >>
> >>
> >> --
> >> Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409
134
> >136
> >> W3C Web Accessibility Initiative
> >http://www.w3.org/WAI
> >> 21 Mitchell Street, Footscray, VIC 3011,  Australia
> >>
> >>
> >
>
>

Received on Sunday, 23 January 2000 12:27:24 UTC