Protocols needs for deployment of accessibility features

Hi
    I attended the recent WAI meeting at the RNIB, Peterborough, England.
It was good to meet the various representatives of the WAI communities
there.
    At the meeting I had lost of questions to ask.  Various WAI WG chairs
suggested I join the w3c-wai-ig@w3.org mailing list and ask my questions
there.  I hope I'm not asking too many FAQs (I've had a quick read through
the archives).
    Much of the WAI work is based on the deployment of more accessible
formats (HTML 4.0, CSS 2.0), providing advice on how to use these formats
(Authoring Guidelines) and develop authoring tools and user agents.
    The WAI work seems to assume that the current generation of browsers
will (rapidly) disappear and that we shouldn't be too concerned at the
interoperability problems we currently face (e.g. buggy CSS implementation).
   I think this assumption is dangerous (even if WAI people don't make it,
readers of various WAI guidelines are likely to make it).
   To take a trivial example.  The use of .margin-left CSS values to indent
text is currently recommended over use of tables, multiple <DL> tricks, etc.
In practice however .margin-left and .margin-right cause sever problems when
printing resources in Netscape 4 (Windows NT/95).  These CSS properties are
on the list of unsafe properties in the list at
http://www.webreview.com/guides/style/unsafegrid.htm
   So the naive user who finds that CSS is recommended for accessible
documents and picks up a 10 minute guide to CSS is likely to find themselves
producing documents which are not accessible as hard copy to users of what
is probably still the most widely deployed browser.
   Even the minority of sophisticated users of CSS will find it difficult to
avoid using these features if they're using a high level authoring tool.
   I had hoped that some protocol wizardry would come to the rescue.
However I understand that Transparent Content Negotiation is not widely used
and there is little interest in it from the browser, server and authoring
tool communities.  So it's even  more unlikely that we'll see Transparent
Feature Negotiation, which could allow only safe HTML / CSS features to be
sent to a browser.
   The W3C Core Style Sheet Gallery does have some application wizardry.  It
uses browser-sniffing to serve "safe" CSS.  A very cursory inspection I made
yesterday showed that the IE CSS file contained 797 lines and the Netscape 4
file 169 lines.  However I have not seen any mention of browser-sniffing in
the WAI guidelines, or in any other W3C document.
   Although  this may address the deployment problem, I suspect it will be a
minority solution as it does seem complicated to implement.  It would be
ironic if only large companies (such as Microsoft) had the resources to
deploy such techniques for making websites accessible to legacy browsers but
well-meaning authors who did not have access to (complicated?) scripting
facilities had to chose between accessible pages as defined by tools such as
Bobbie) or inaccessible pages which can at least be printed.

   My questions:

   o Are there technical solutions to the legacy browser problem which we
can expect to be widely available?
   o If not does the WAI community have any ideas when legacy browsers will
be so little used that they can be ignored?  Can you give advice to
organisations who have to make such choices?  Note that this can be a
dangerous question as many websites don't get many hits from Lynx.

Thanks

Brian Kelly

------------------------------------------------------
Brian Kelly, UK Web Focus
UKOLN, University of Bath, BATH, England, BA2 7AY
Email:  b.kelly@ukoln.ac.uk     URL:    http://www.ukoln.ac.uk/
Homepage: http://www.ukoln.ac.uk/ukoln/staff/b.kelly.html
Phone:  01225 323943            FAX:   01225 826838

Received on Tuesday, 4 August 1998 10:47:41 UTC