WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: NOSCRIPT question

for

From: Andrew Kirkpatrick
Date: May 2, 2006 10:50AM


> This is particularly important if compliance to WCAG is
> either a goal or
> mandate: WCAG 6.3 (in part states) "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." (I
> didn't write this, I just report the facts)

This is compatible with what I said, except that I still think that
using noscript is not worth it.

> > It looks like JAWS 7.1 will
> > finally support noscript when released, but no other
> version of JAWS
> > does.
>
> So what? Since when do we develop content for user agents?

Ha ha. When did you build your first XHTML web page that used only CSS
for layout? In 2000 when XHTML came out? Maybe you did, but the fact
is that developers need to make informed judgements about what features
of technologies to use. I'm not developing content _for_ user agents,
I'm developing with the abilities of user agents in mind.

> I'm sorry, but I must totally disagree with Andrews advice
> here - it's wrong: if you are using a script, then *if/when*
> required (a mission critical
> function) use NOSCRIPT.

It's not wrong. There is a perfectly viable alternative that works the
same for most users and better for the rest. Why would you use noscript
given this?

> *Not* using it because JAWS does not
> support it is a very poor reason - there are other user
> agents out there that may not support scripting and would
> benefit 100% by the addition of the noscript element.

I'm not disagreeing with anything you say here. I think that you must
be arguing against something someone else said. 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.

> > For script events, you should use "progressive enhancement". This
> > means that the javascript functionality should be added to the
> > elements that need it as through a script.
> >
> > In the case of your navigation example, you might need a
> script that
> > is run when the page loads that modifies a set of nested
> lists so that
> > some elements are hidden and some have mouseover and focus (and
> > mouseout and blur) events to make the list have the desired visual
> > appearance and functionality. Take away the script by turning
> > javascript off and you still have the useful list.
>
> Yes, this is correct, and in principle I would also advise
> this form of development. In the development environment, we
> must always ask if we
> *really* need to use that bit of JavaScript, or is there a
> different solution that can be applied? In most instances
> I've encountered, there is usually another way of "skinning
> the cat" (as it were - I do not advocate violence against
> animals!) - be it a server-side solution, CSS trickery or
> simply a re-thinking of what it is that we are trying to
> really accomplish (the end goal) vs. gadgetry for gadget's sake.

So you do agree with me! :)

> In the example above, the graceful degradation (or
> progressive enhancement - this is but a matter of
> perspective) solution proposed is the right way of moving
> forward. But to issue a blanket statement to not use
> NOSCRIPT is wrong - if there is no other way around the
> issue, then implementing NOSCRIPT may in fact be the **only**
> way to go.

Can you provide a possible scenario where noscript _must_ be used? I
can't, and that's why, along with the extra effort and poor support by
JAWS that I'm willing to say that noscript is worth ignoring.

> > If you use noscript you can accomplish almost the same
> thing, but you
> > need to code the navigation and the list separately, and it
> won't work
> > with JAWS (yet).
>
> Which is unfortunate, but should not be the reason to not use
> W3C recommended development techniques.

I didn't suggest doing something outside of the W3C's recommendations, I
just think that one of their suggestions is not a good solution.

AWK