- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 17 Jul 2000 13:31:03 -0400 (EDT)
- To: WAI GL <w3c-wai-gl@w3.org>
Forwarded from Sylvain Galineau of Iris (they make relevant parts of Lotus Notes) with permission -------------------- I would like (once again, I'm stubborn) to get back to one point I made way back. Are there plans for a new Content-Type/Accept style HTTP header/value allowing the server to know the client needs accessible content ? Today, we know how to deliver the right data in terms of preferred language, character set, image file format or user agent (browser type, cell phones, whatever). I can understand your goal to have content always authored in an accessible manner but that is not always practical in terms of performance or bandwidth. Case in point : our web server allows you to use an applet for view rendering. However, we unfortunately do not generate an alternate HTML version of that view for other browsers in the page. It would simply be too costly today. Since the applet, if loaded, also calls the server to load its content, we could end up reading the view index twice for each page load (we don't cache those since our product allows each view to be different for each user due to access rights and other things....). One way around the problem would be to have the view data as an XML data island that the applet or a stylesheet could use to render the view. But that would limit us to the latest IE browsers, without even getting into standard/DOM issues etc. Also in many cases, customers want to render things in a visually sharp manner using non-accessible tricks if necessary , - whatever works i.e. invisible tables and all, as we (gasp) do - but they still want (or will want or will have) to cater to user agents and users that require accessible content. So I can imagine people wanting to have an XSL stylesheet for the accessible case on top of the ones they have today for the various user agents, for instance. If something in the request told us the user agent requires accessible content, supporting the WAI requirements would be easier, for app servers and of authoring tools vendors.Once you set your page/form to be accessible, the tools can then prompt you for all the required attributes and warn you about features you shouldn't be using (beans, applets, zero-border tables....) without being intrusive for the 'other' content. True, the goal should be to write all the stuff once without having to split/process everything in a million ways. In other words, if such a header were to exist, it would be nice to be able to deprecate it at some point. But in the real world, we are not there and it's going to be a while. Having many WAI rules into HTML 4.0 (ALT required in many places for instance) helps in making things more accessible. But that does not prevent people from authoring stuff that is unusable for a blind person. I guess it's a question of short-term vs. long-term goals. Having some HTTP header field telling us the user agent needs accessible content is a short-term workaround. Might be incompatible with the longer term objective but why not, if it serves the cause ?
Received on Monday, 17 July 2000 13:31:04 UTC