W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2000

Re: Authoring Tool Accessibility (fwd)

From: Charles McCathieNevile <charles@w3.org>
Date: Mon, 17 Jul 2000 13:31:03 -0400 (EDT)
To: WAI GL <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.20.0007171329280.11361-100000@tux.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,

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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:33 UTC