- From: Charles McCathieNevile <charles@w3.org>
- Date: Sat, 22 Jan 2000 21:44:06 -0500 (EST)
- To: Scott Luebking <phoenixl@netcom.com>
- cc: nir@nirdagan.com, w3c-wai-gl@w3.org
Navbars are an interesting case in point. There are a number of users who would be better served by being able to skip over, rather than have to work their way through, a navigation bar. These include people who have cognitive diabilities and people with motor disabilites as well as blind users. On the other hand, access to the navigation is of course as important to these users as to everyone else. I think Nir is much closer to the mark - what is needed is some markup to identify a navbar. Actually, however, there is such markup in HTML 4 - the map element. Until we all have good browsers, however, it is helpful to provide a way of skiiping past this. Accesskey is one strategy that is provided by HTML but only implemented in some browsers. Another is to provide a link to "skip navbar" which goes directly past them. 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 Saturday, 22 January 2000 21:44:14 UTC