Noscript and accessibility??

[Don]

On 25 Apr 2005 Edwin van der Vaart wrote in alt.html


Don't be so picky.

Wow!! He knows my nick name.[/QUOTE]

I thought Vaart-Fart was your nick name.

 

[Nico Schuyt]

Then don't use FP.

Sorry, haven't found a better editor so far
Did the coding for the guestbook I sent you work properly?

 

[Samuël van Laere]

Samuël van Laere wrote:

[snipped code]

It still doesn't do a thing on the site - nothing show's up -
though no errors are returned, so something must be good in it.

There's nothing wrong with the code at all. However, the code in abbr.js
is very antisocial as it overwrites the listener added in mine (and
Toby's). The quick solution is to include abbr.js /before/ textsizer.js.

Well it was my mistake, I replaced Toby's code with yours inside the
function.
Didn't realize your code wasn't suposed to go inside that function.
It works now )

Thanks for the help guy's, even the PHP solution would be good.
But i'll keep the javascript for now.

Cheers,
Samuël van Laere

 

[Spartanicus]

People who understand web browser scripting recommend never using
NOSCRIPT tags at all, because they do not satisfy their intended goal.
That is, there may be an exclusive relationship such that a browser that
is script disabled/incapable will be able to employ the contents of
NOSCRIPT elements, but there is no relationship between a script enabled
browser and the successful, active, execution of any given script. Thus
the pairing of SCRIPT and NOSCRIPT elements cannot provide the 100%
coverage that any accessibility considerations would require. Other
techniques should be used instead, and they remove the need for NOSCRIPT
elements.

You overstate the issue. A noscript fall back can make sense, for
example to serve a single image as an alternative for an image changing
script.

 

[Lauri Raittila]

You overstate the issue. A noscript fall back can make sense, for
example to serve a single image as an alternative for an image changing
script.

In that case, script should be made so that there is always single image,
and script may change that image to image changing thingy. No noscript
element needed.

 

[Jukka K. Korpela]

A noscript fall back can make sense, for
example to serve a single image as an alternative for an image
changing script.

A better example of a useful noscript element would be

<noscript>
<p>This order form is more comfortable to use on a JavaScript-enabled
browser, because then you would see the running total calculated
immediately. Your current browser has JavaScript disabled, or does
not support JavaScript. You can still fill out and submit the form,
and you will have an opportunity to see the calculated total before
confirming your order.</p>
</noscript>

Of course, this does not specify any fallback - it's simply content to
be presented if and only if client-side scripting is not enabled.

 

[Toby Inkster]

<noscript>
<p>This order form is more comfortable to use on a JavaScript-enabled
browser, because then you would see the running total calculated
immediately. Your current browser has JavaScript disabled, or does
not support JavaScript. You can still fill out and submit the form,
and you will have an opportunity to see the calculated total before
confirming your order.</p>
</noscript>

But if the user has a browser that understands some client side scripting
language, but not Javascript, this message will not be shown, yet the
Javascript on the form will not work.

This:

<p id="ns">This order form is more comfortable to use on a
JavaScript-enabled browser, because then you would see the running total
calculated immediately. Your current browser has JavaScript disabled, or
does not support JavaScript. You can still fill out and submit the form,
and you will have an opportunity to see the calculated total before
confirming your order.</p>
<script type="text/javascript">
document.getElementById('ns').innerHTML='';
</script>

is better (except that it uses the proprietry, but widely supported
innerHTML property -- it could be rewritten to use standard DOM methods,
but innerHTML is easy to understand for this illustrative example) as it
will be hidden only in browsers that support Javascript.

 

[Mark Parnell]

But if the user has a browser that understands some client side scripting
language, but not Javascript, this message will not be shown, yet the
Javascript on the form will not work.

What browsers fall into that category? Would that include disabled
Javascript if other scripting languages were enabled?

 

[Spartanicus]

A better example of a useful noscript element would be

<noscript>
<p>This order form is more comfortable to use on a JavaScript-enabled
browser, because then you would see the running total calculated
immediately. Your current browser has JavaScript disabled, or does
not support JavaScript. You can still fill out and submit the form,
and you will have an opportunity to see the calculated total before
confirming your order.</p>
</noscript>

For users that have no control over whether js is enabled/available only
the "you will have an opportunity to see the calculated total before
confirming your order" part of the message is useful.

As someone who has js disabled and who could enable it I would consider
being reminded of having js disabled as patronising, and I would
certainly not consider switching js on in such an event.

 

[Edwin van der Vaart]

Edwin van der Vaart wrote:

Did the coding for the guestbook I sent you work properly?

I haven't tried that.

 

[Richard Cornford]

Toby Inkster wrote:

<p id="ns">This order form is more comfortable to use on a
JavaScript-enabled browser, because then you would see the
running total calculated immediately. Your current browser
has JavaScript disabled, or does not support JavaScript.
You can still fill out and submit the form, and you will
have an opportunity to see the calculated total before
confirming your order.</p>
<script type="text/javascript">
document.getElementById('ns').innerHTML='';
</script>

is better (except that it uses the proprietry, but widely
supported innerHTML property -- it could be rewritten to use
standard DOM methods, but innerHTML is easy to understand for
this illustrative example) as it will be hidden only in
browsers that support Javascript.

That statement will only be removed on a script capable browser, but not
all of them. Support for dynamic manipulation of a DOM using innerHTML
may be wide but it is not universal. Adding getElementById removes
another couple of browsers from the supported set, and it is really
unlikely that the user's ability to 'see the running total calculated
immediately' hangs on nothing more then the browsers support for
innerHTML and getElementById. So it is better, but the statement is
inappropriate for the context and the decision to remove it should be
more closely related to the availability of the features that the script
will actually use.

Richard.

 

[Richard Cornford]

Toby Inkster said:


What browsers fall into that category? Would that include
disabled Javascript if other scripting languages were enabled?

Internet Explorer could be configured that way; by eliminating JScirpt
from the OS (the DLL and the registry entries) and leaving VBScritp in
place. It is not a very likely (or sane) configuration but it does
feature in the spectrum of possibilities.

Richard.

 

[Richard Cornford]

A better example of a useful noscript element would be

<noscript>
<p>This order form is more comfortable to use on a
JavaScript-enabled browser, because then you would see the
running total calculated immediately. Your current browser
has JavaScript disabled, or does not support JavaScript.
You can still fill out and submit the form, and you will
have an opportunity to see the calculated total before
confirming your order.</p>
</noscript>

What this is saying is that if the user of a javascript capable, but
disabled, web browser enables scripting and re-loads the page they
_will_ experience particular scripted behaviour. That sort of confidence
is not the product of wide experience scripting web browsers. The
environment presented to scripts by web browsers are just not
sufficiently consistent to guarantee successful execution of any
particular (non-trivial) script in _all_ available environments. For
some users that statement is simply a lie.

In choosing a script that could be implemented using the relatively
basic form manipulation facilities that are very widely implemented in
scriptable web browsers (and since the inception of scripting), you
provide an 'example of a useful noscript element' that comes about as
close to achieving its goal as any noscript element could. But there is
still much that such a script could trip up upon; the non-ECMAScript
conforming behaviour of the logical operators on NetFront 4, early Opera
5's failure to implement a length property on the options collection of
select elements, much variation in the capabilities of regular
expression implementations (and regular expression bugs), and so on.

The premise of a noscript element is that there are only two possible
outcomes, successful script execution and script being unavailable. And
when it was introduced, in the days when there was only one scriptable
browser, it probably seemed like a good idea because those were the only
two possibilities. These days there are three possible outcomes on the
public Internet; the two previous outcomes plus the possibility that a
script capable and enabled browser is being used but that it does not
provide the facilities that the script requires (for whatever reason)
and so the script must fail to employ those facilities (and do what was
desired of it).

The noscript element cannot cover that third possibility, but a
defensively written script that tests for, and observes, its inability
to act can decline to act, achieving clean degradation under their own
control. Thus an inability to act becomes nothing more, no direct harm
is done as a consequence. The situation for the user of such a browser
is no worse than the situation for a user of a script incapable/disabled
browser on the same page, except that the content of noscript elements
will not be shown to the user.

Whatever it may make sense to include in a web page for the script
incapable should also make sense for the users of browsers that do not
support the particular scripted features, so the sensible starting
position is to put it in the page and then have the script remove, or
modify, it only when it has determined that the browser environment is
providing the facilities that it requires.

Though it doesn't make sense to be telling people that they should
enable javascript when it may already be enabled, but then it doesn't
make sense to be telling them that when you cannot guarantee that doing
so will make any difference to them.

Of course, this does not specify any fallback - it's simply
content to be presented if and only if client-side scripting
is not enabled.

There is very little fallback that can be provided by noscript elements
(particularly given that it is not valid to place then inside the head
element). But it is difficult to see much alternative content that would
make sense for the script disabled/incapable that would not also make
sense for the users of browsers lacking the features that the
corresponding script would have used if available. Which just leaves
these noscript elements providing these assertions that things will be
much better with scripting enabled, which are not necessarily true for
all users anyway (assuming that they understand what javascript is and
how to enable it).

Richard.