- From: Jon Hanna <jon@spinsol.com>
- Date: Wed, 14 Feb 2001 11:13:43 -0000
- To: <w3c-wai-ig@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > It is only worth asking to "prove" that something CAN BE > accessible. I do NOT like the idea of a set of minimum > assumptions. That in my opinion is dumbing down the web in the > name of accessibility. Either the technology, in this case > JavaScript, can be accessible or it can't. If there are some > reference implementations (more than 1] to "prove" that it can, > then by definition it is accessible. If it isn't usable with a > certain browser, then it isn't "supported". Just because something > isn't supported doesn't make it in-accessible. Accessible to whom? When Lynx comes across a <script> element it ignores its contents, when it comes across a <noscript> element it doesn't ignore its contents. This is perfectly standard-compliant behaviour. The first part of this is important - the current build of Lynx "understands" the <script> element and will skip its contents even when SGML or XML comments aren't used to "hide" those contents - compare with early versions of the graphical browsers which don't understand the element and will render its contents. For one thing there is no reason to assume that any given browser will understand any given scripting language, and browsers should ignore MIME types and languages they aren't able to run (while ECMA-script may be *a* standard scripting language, there are other scripting languages which have been standards for longer and have a higher level of standards-compliance amongst their implementations. The fact that ECMA-script is a de facto standard for web page scripting is irrelevant from the point of view of HTML). There is nothing in the standards, either the ECMA standard, or the HTML one, to suggest that only ECMA-script should be used. The ECMA-standard does not make any assumptions that the script in question is to be run on a web client, there are lots of other uses for ECMA-script. The HTML standard quite clearly suggests that other languages could be used, and its examples use tcl twice and javascript and vbscript once each. I have on occasion used vbscript on webpages launching it from javascript when available and otherwise using a (less useful for my purposes) javascript equivalent. There were three "standards" here, one was the proprietary spec for vbscript, the others html and ECMA-script. I didn't break either standard. There are lots of user agents that may not use javascript for a variety of reasons. For one thing a script engine will necessarily add to the processor, memory and potentially disc resources needed, this may not be appropriate in some cases (especially small hand-held devices were the "cost" of these resources increases). Some proxies will not allow .js files through, and may even edit out script blocks (probably over-paranoid, but there have been security holes from time to time which involve scripting capability in browsers). One of the reasons many people use lynx is it isn't very resources-expensive, which makes ideal for browsing on a machine primarily used for something that is more expensive. A indexing spider wants to do a minimum amount of parsing grab the information it is looking for from the page, it should be able to just ignore the contents of <script> elements, and not have to delve through it looking for "document.write" or "document write" or "document.Write" etc to work out what content the page has (and that is grossly simplifying the task at hand). Accessibility isn't just about users who are physically disabled. If it isn't accessible to a user-agent because of security measures, or because of low resources, or because that user-agent is a bot, then it isn't accessible. If we are going to argue that Lynx must have javascript capability we might as well argue that it should have images, as long as it could provide the alt attributes to Braille or voice outputs. Lynx fulfils the part of the standard that deals with images 100% because rendering the alt text instead of the images is fully standard compliant, so it is with <script>. For one thing making a script-based page accessible to clients that don't run scripts is generally pretty easy. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> iQA/AwUBOopoZtlYbmO7kSNQEQJqlACg7uV97aCSVNNBxOQEHht2ZsfaMBQAoPZT UQHxEuA1rpC7snZeAplYghSv =EKY/ -----END PGP SIGNATURE-----
Received on Wednesday, 14 February 2001 06:13:20 UTC