- From: Jonathan Chetwynd <jay@peepo.com>
- Date: Sun, 23 Jan 2000 17:16:23 -0000
- To: <w3c-wai-gl@w3.org>, "Al Gilman" <asgilman@iamdigex.net>
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