Hi there,
At 01:40 AM 30/06/2004, you wrote:
I think that catering for special needs, or simply trying to conform to accessibility guidelines, should be the developer's task, on the basis of the anticipated audience. And you can also see why imposing choices on the users is a bad idea: while you probably should keep in mind accessibility everywhere, it could make sense to propose a special version of your site (lighter on resources, for instance, or conceived for PDA browsers, etc.), but if you already have to propose a version for "normal", standard-complying browsers, and another for IE, this probably is not feasible, or would result in a scarcely maintainable site.
I think it's good to strike a balance here. On our Introduction to Hul'q'umi'num' site (http://web.uvic.ca/hrd/hulq/) we let the user choose which audio file format and media player they prefer to use, then store that in a cookie and use it to insert the appropriate media player code for every audio link. We determined this would be the best way to handle the fact that there are no real standards for media files on the Web, and a range of players is available; it's unreasonable to require people to install a particular player just to use one site, so we let you choose between WMP, Real, Flash and Quicktime, and between .wma, .ra, .mp3 and .ogg files. This pretty much ensures that anyone can use the audio material without installing anything special (we hope!).
We also allow people to decide where they'd like to put the navigation menus on the page, and give the option of a high-contrast colour scheme, or a print stylesheet for the pages (which is monochrome, without navigation). All of this is done through JavaScript and cookies, and the individual pages themselves do not need to be changed; the JavaScript reads the cookies and makes changes to the DOM when the page is loaded or when the user chooses an audio segment to listen to. All of this is done client-side, so the site can be run from a CD, or a server with no available scripting, if necessary.
This kind of flexibility is fairly easy to incorporate in a site nowadays. However, the issue of PDAs is a slightly different one; PDA browsers are porrly-featured in terms of CSS, JavaScript and DOM support, so unless a site is very simple indeed, any special version of it for PDAs currently has to be created server-side. In a couple of years, though, PDAs will be running the equivalent of the current FireFox, I think, and most things we do now for desktop browswers will be practical for PDAs.
But then we'll have the legacy installed base of old PDAs to worry about...
Cheers, Martin
______________________________________ Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com