- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sun, 23 Jan 2000 09:55:02 -0600
- To: <w3c-wai-gl@w3.org>
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 09:50:44 UTC