- From: Lisa Seeman <seeman@netvision.net.il>
- Date: Thu, 9 Nov 2000 15:25:28 +0200
- To: <A.Flavell@physics.gla.ac.uk>, "WAI \(E-mail\)" <w3c-wai-gl@w3.org>
True true. But our guideline specifically require you to support the older client software (and these clients are not even old). a quote from this lovely site that you recommended. "Backward compatibility: Logically encoded pages will render useless in browsers that do not support bi-directional text. With certain restrictions (screen width etc.), visually encoded documents may render reasonably in both old and new browsers." But Visual encoded documents can not be read by a screen reader. You know, even the best BILI browser - IE5 - has "rather annoying bugs concerning the title element and alternative text to images" in other words, accessibility is not truly supported. So to compile with checkpoint 1 and checkpoint 6, you have to do both visually and a separate logically incoded document. And that is very hard to do. Now you are right in that the source of the problem is with the client software. And that needs to be addressed, but it creates a problem that you can not keep the WIA in BILI. And that is our problem. L -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On Behalf Of Alan J. Flavell Sent: Wednesday, November 08, 2000 4:23 PM To: Lisa Seeman Cc: WAI (E-mail) Subject: Visual/logical Hebrew, was Re: FW: Irregular fonts and I18N On Wed, 8 Nov 2000, Lisa Seeman wrote: > Firstly the link itself would have to be in the logical architecture to be > accessible, in which case it will come out backwards to everyone else! lemThe properly-engineered solution for that is the "Accept-charset:" header from the client to express its capabilities, with the server sending out the proper document variant by content-negotiation. You'll say, of course, that many available clients don't support it. True enough, and so that's the problem that needs solving. Seems to me that just as a personal proxy like WebWasher or Junkbuster can filter _out_ HTTP headers, presumably one could "front-end" a browser with a proxy that would put desired HTTP headers _in_, if the browser implementers couldn't be bothered to implement this part of the published protocols. BTW, you'll presumably be familiar with the discussion at http://www.nirdagan.com/hebrew/ best regards
Received on Thursday, 9 November 2000 08:33:28 UTC