W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2001

RE: [media] Making Sites Accessible Makes Sense For All Customers

From: Jon Hanna <jon@spinsol.com>
Date: Wed, 14 Feb 2001 11:13:43 -0000
To: <w3c-wai-ig@w3.org>
Message-ID: <NDBBLCBLIMDOPKMOPHLHGEKDCOAA.jon@spinsol.com>
-----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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:53 GMT