WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: NOSCRIPT question

for

From: Andrew Kirkpatrick
Date: May 2, 2006 1:00PM

> "If it is not possible to make the page usable without
> scripts, provide a text equivalent with the NOSCRIPT element,
> or use a server-side script instead of a client-side script,
> or provide an alternative accessible page as per checkpoint 11.4."

The W3C doesn't say to use progressive enhancement in this list. Does
that mean that it isn't ok, or even better than noscript?

> > This is compatible with what I said, except that I still think that
> > using noscript is not worth it.
>
> Beg your pardon Andrew, you stated:
>
> "I'll make it easy. Don't use noscript." (full stop, no
> qualifiers)
>
> ...yet the W3C says to use NOSCRIPT - this is a direct contradiction.
> This is what I am commenting on.

In this case, the advice of the W3C is not as sound as what I wrote, and
I thought that you were agreeing with me on!

> > I'm not developing content _for_
> > user agents, I'm developing with the abilities of user agents in
> > mind.
>
> And that may very well be. However, advising to *not* use
> NOSCRIPT because JAWS does not support it is, to my mind,
> fundamentally wrong.

That is one fact that I take into when determining not to use noscript.
I might come to a different conclusion if there wasn't a better way.

> Don't use JavaScript at all then, because Lynx does not
> support it. If you support the notion that the first
> statement is valid, then obviously the second statement is valid too.

Sure, that is what I'm arguing. If you require the page to function
without scripts, make it work without scripts. But don't use noscript
to make it so. The whole idea of progressive enhancement is to _add_
the functionality in a script so that when scripting is turned off what
you are left with is what you might have otherwise put into a noscript
if you had coded the scripting functionality into the HTML to begin
with.

> However, using/not using NOSCRIPT is not "simple" and it *is*
> wrong to imply never to use NOSCRIPT, which is what your
> initial statement inferred.

I disagree. I'll recommend not using noscript every time.

> What I said is, in instances where the page author *MUST* use
> JavaScript for a Mission Critical function, that they should
> provide a fallback mechanism,

Of course

> and sometimes that involves
> NOSCRIPT: I would hate to have a newer list member presume

Here's where we are not in agreement. I'd like to see an example where
noscript isn't replaceable due to better scripting implementation.

> > I fully support
> > providing the content to users that have user agents that don't
> > support scripting, but there is a better way than using noscript.
>
> Defend this statement please. You know of another way other
> than NOSCRIPT for situations where NOSCRIPT is required?

See my note about progressive enhancement above.
Can you give an example where noscript is _Required_?

> Many of the existing suggestions in WCAG 1 are either dated
> or not optimal - Andrew you know as well as most how I feel
> about Accesskeys - and while I put forth my objections (every
> chance I get <grin>), I have never stated *not* to use them -
> only that *I* don't use them because they are fraught with
> potential problems and to make your choices carefully and to
> be fully informed. If this is what you are trying to say,
> then fair enough, but that is not what you originally wrote.

You do advocate not to use them. You advocated to the CLF committee and
seemed happy they changed the policy:
This potential problem was subsequently brought to the attention of the
Canadian Common Look and Feel Access Working Group (who had previously
suggested the use of Accesskeys M, 1 and 2), and after consideration the
Access Working Group reversed it's recommendation and now suggest not to
use Accesskeys on Government of Canada Web sites.

When any person makes a statement on this or any list, it is implied
that it is the opinion of that person. If you don't feel that adequate
support is provided, call that person on it. I'm happy to justify my
position, but I'm not going to change it because it contradicts a W3C
"for example".

AWK