E-mail List Archives
Thread: NOSCRIPT question
Number of posts in this thread: 25 (In chronological order)
From: Debbie Charles
Date: Tue, May 02 2006 6:30AM
Subject: NOSCRIPT question
No previous message | Next message →
I have looked at a lot of sites, books, etc. that recommend that NOSCRIPT
be included if Javascript is run on a page, but I haven't found one with a
'good' (for me) explanation or example of what should be included there.
With a form, for example, based on the answer to question one, the
javascript runs after the selection and you will see one of three questions
as your second question and so on. What would be needed in NOSCRIPT for
something like that?
I am 'assuming' that if your navigation is javascript based (operationally,
not aesthetically) that the URL's would be listed in the NOSCRIPT. What is
the javascript is just aesthetics? For example, on mouseover the button
changes color--is a NOSCRIPT tag needed for that?
thanks for any help or direction to resources (that explain it so a
4-year-old could understand it :))
Debbie
Debbie Charles
Educational Technology Services
436-B Brackett Hall
Clemson University
864.650.3995
From: Andrew Kirkpatrick
Date: Tue, May 02 2006 8:10AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
I'll make it easy. Don't use noscript. It looks like JAWS 7.1 will
finally support noscript when released, but no other version of JAWS
does.
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.
If you use noscript you can acomplish almost the same thing, but you
need to code the navigation and the list separately, and it won't work
with JAWS (yet).
AWK
>
From: John Foliot - WATS.ca
Date: Tue, May 02 2006 8:50AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
Andrew Kirkpatrick wrote:
> I'll make it easy. Don't use noscript.
I'll make it easier and contradict Andrew. Use NOSCRIPT, in accordance
with the W3C's recommendation:
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-scripts
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)
> 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? 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. *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.
> 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.
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.
>
> 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.
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
From: Andrew Kirkpatrick
Date: Tue, May 02 2006 10:50AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
> 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
From: John Foliot - WATS.ca
Date: Tue, May 02 2006 12:20PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
"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."
Andrew Kirkpatrick wrote:
>
> 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.
>
> 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.
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.
>
>> 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?
Wait, in the case of the navigation bit, the solution you proposed is
the best way forward - I don't debate that and in fact stated so.
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.
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, and sometimes that involves NOSCRIPT: I would hate to have a
newer list member presume that using NOSCRIPT is somehow not a valid
option because JAWS does not support it - and this is the point I am
advocating. NOSCRIPT is valid HTML, is referenced in WCAG 1 as a
"recommendation", and if/when it is required (and no, off the top of my
head I cannot conjure up an example), perfectly acceptable. To state
otherwise is, IMHO, wrong.
> 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?
>
> So you do agree with me! :)
>
In this particular example, your proposed solution is the best way
forward. I take exception with the blanket, un-qualified statement of
"do not use NOSCRIPT" that you started your original response with.
>
> 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.
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.
JF
From: Andrew Kirkpatrick
Date: Tue, May 02 2006 1:00PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
> "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
From: Steven Faulkner
Date: Tue, May 02 2006 4:50PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
I can give you an example of NOSCRIPT use that i recommended to a client
yesterday.
The clients page has a javascript based "glossary" function: when a user
activates a Javascript link on certain words, content is written to the
page with the definition of the word. because the content is written to
the page via javascript it is not available when Javascript is disabled
or not supported. In this case I recommended that a NOSCRIPT element be
included containing the word definitions, so that the information is
available regardless of javascript support.
with regards
Steven Faulkner
Web Accessibility Consultant
vision australia - information & library service
454 Glenferrie Road
Kooyong Victoria 3144
Phone: (613) 9864 9281
Fax: (613) 9864 9210
Email: = EMAIL ADDRESS REMOVED =
www.accessibleinfo.org.au | www.wat-c.org
Download the Web Accessibility Toolbar
[http://www.visionaustralia.org.au/ais/toolbar/]
Vision Australia was formed through the merger of the Royal Blind
Society
NSW, the Royal Victorian Institute for the Blind, Vision Australia
Foundation and the National Information & Library Service.
ABN: 67 108 391 831 ACN: 108 391 831
>
From: Christian Heilmann
Date: Tue, May 02 2006 5:50PM
Subject: Re: NOSCRIPT question
← Previous message | Next message →
> I can give you an example of NOSCRIPT use that i recommended to a client
> yesterday.
>
> The clients page has a javascript based "glossary" function: when a user
> activates a Javascript link on certain words, content is written to the
> page with the definition of the word. because the content is written to
> the page via javascript it is not available when Javascript is disabled
> or not supported. In this case I recommended that a NOSCRIPT element be
> included containing the word definitions, so that the information is
> available regardless of javascript support.
And how is that more logical than having the definitions at the end of
the page and using target links on the words? This would work without
JavaScript. With JavaScript you can initially hide all the
definitions, loop through all links and display them f.e. as a tooltip
when the user clicks or hovers over the links.
No need for NOSCRIPT, it is in 99.9% of the cases a sad excuse for bad
script planning.
--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/
From: Andrew Kirkpatrick
Date: Tue, May 02 2006 7:20PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
I should have read Christian's message first!
AWK
>
From: Steven Faulkner
Date: Tue, May 02 2006 7:30PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
Chris wrote
> And how is that more logical than having the definitions at the end of
> the page and using target links on the words?
I didn't claim that it was more or less logical than any other method,
and I agree that implementing a different method may be more logical.
The example I gave was to demonstrate a possible use of the NOSCRIPT
element.
After testing the functionality of their script with assistive
technology and keyboard I found that it was accessible via a number of
user agents and input devices with javascript enabled.
It is not my role to tell them that their "script planning" is "sad"
unless it impacts upon the accessibility of the content.
with regards
Steven Faulkner
Web Accessibility Consultant
vision australia - information & library service
454 Glenferrie Road
Kooyong Victoria 3144
Phone: (613) 9864 9281
Fax: (613) 9864 9210
Email: = EMAIL ADDRESS REMOVED =
www.accessibleinfo.org.au | www.wat-c.org
Download the Web Accessibility Toolbar
[http://www.visionaustralia.org.au/ais/toolbar/]
Vision Australia was formed through the merger of the Royal Blind
Society
NSW, the Royal Victorian Institute for the Blind, Vision Australia
Foundation and the National Information & Library Service.
ABN: 67 108 391 831 ACN: 108 391 831
>
From: Andrew Kirkpatrick
Date: Tue, May 02 2006 7:40PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
> The clients page has a javascript based "glossary" function:
> when a user activates a Javascript link on certain words,
> content is written to the page with the definition of the
> word. because the content is written to the page via
> javascript it is not available when Javascript is disabled or
> not supported. In this case I recommended that a NOSCRIPT
> element be included containing the word definitions, so that
> the information is available regardless of javascript support.
One way that makes sense is to put the words and definitions in the HTML
and then use a script to hide all the definitions and to show the one
you want at the correct time.
This way you get:
1) to modify the definition in one place if it needs to be changed (as
opposed to changing the definition in js and in noscript)
2) support for jaws users with scripting disabled
AWK
From: Steven Faulkner
Date: Tue, May 02 2006 7:50PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
BTW
If you or anybody has a working example of a "more logical" method,
please supply the URL so I can point our client to it.
with regards
Steven Faulkner
Web Accessibility Consultant
vision australia - information & library service
454 Glenferrie Road
Kooyong Victoria 3144
Phone: (613) 9864 9281
Fax: (613) 9864 9210
Email: = EMAIL ADDRESS REMOVED =
www.accessibleinfo.org.au | www.wat-c.org
Download the Web Accessibility Toolbar
[http://www.visionaustralia.org.au/ais/toolbar/]
Vision Australia was formed through the merger of the Royal Blind
Society
NSW, the Royal Victorian Institute for the Blind, Vision Australia
Foundation and the National Information & Library Service.
ABN: 67 108 391 831 ACN: 108 391 831
>
From: Patrick H. Lauke
Date: Tue, May 02 2006 8:00PM
Subject: Re: NOSCRIPT question
← Previous message | Next message →
Andrew Kirkpatrick wrote:
> I should have read Christian's message first!
Repetition reinforces retention :)
P
--
Patrick H. Lauke
___________
re
From: Joe Clark
Date: Wed, May 03 2006 12:30PM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
>From: "John Foliot - WATS.ca" < = EMAIL ADDRESS REMOVED = >
>
>Andrew Kirkpatrick wrote:
>> I'll make it easy. Don't use noscript.
>
>I'll make it easier and contradict Andrew. Use NOSCRIPT, in accordance
>with the W3C's recommendation:
>http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-scripts
WCAG 1 is outdated when it comes to scripting (not to mention
self-contradictory). It is our job as standardistas and
accessibilitistas to know how to interpret archaic guidelines in the
context of modern technology. Go ahead and use JavaScript correctly
(a concept still in evolution, but many basic facts are known) and
ignore <noscript> the way you ignore <noframes>.
--
Joe Clark | = EMAIL ADDRESS REMOVED =
Accessibility <http://joeclark.org/access/>;
Expect criticism if you top-post
From: Alastair Campbell
Date: Thu, May 04 2006 5:20AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
Joe Clark wrote:
> ignore <noscript> the way you ignore <noframes>.
As in not using frames at all?! ;)
I suspect that everyone here agrees that a site should work with or
without JavaScript [1].
The method of degradation/enhancement may vary, and may affect (a few)
user agents differently. However, if you start with a valid page that
works without JavaScript, and then use it for enhancement, it's much
more difficult to go wrong.
Personally, I can't think of an instance where <noscript> would be
needed, but perhaps I'm biased by having good back-end developers who
are used to making web applications that don't require JavaScript? [1]
Cheers,
-Alastair
Caveat:
[1] Certain applications do require JavaScript, WYSIWYG editors being
the usual example I come across. However, even these can fall back to
text areas without using <noscript>.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: John Foliot - WATS.ca
Date: Fri, May 05 2006 6:30AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
Joe Clark wrote:
>> From: "John Foliot - WATS.ca" < = EMAIL ADDRESS REMOVED = >
>>
>> Andrew Kirkpatrick wrote:
>>> I'll make it easy. Don't use noscript.
>>
>> I'll make it easier and contradict Andrew. Use NOSCRIPT, in
>> accordance with the W3C's recommendation:
>> http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-scripts
>
> WCAG 1 is outdated when it comes to scripting (not to mention
> self-contradictory). It is our job as standardistas and
> accessibilitistas to know how to interpret archaic guidelines in the
> context of modern technology. Go ahead and use JavaScript correctly
> (a concept still in evolution, but many basic facts are known) and
> ignore <noscript> the way you ignore <noframes>.
Well...
Despite recent protestations on this list that using NOSCRIPT is
archaic, and should not be required anymore, a recent article by James
Edwards, (aka brothercake), lends some weight to my assertion that using
NOSCRIPT is still not only valid, but perhaps even required.
In a recent article, "AJAX and Screenreaders: When Can it Work?"
(http://www.sitepoint.com/article/ajax-screenreaders-work), James
outlines a series of tests undertaken with specific scripts and specific
AT (screen readers).
James's conclusion?
"I'm forced to conclude that, unless a way can be found to
notify screen readers of updated content, AJAX techniques cannot be
considered accessible, and should not be used on a production site
without a truly equivalent non-script alternative being offered to users
up-front." (NOTE, James says non-script, and not NOSCRIPT, but using
<NOSCRIPT> is certainly a predictable and stable way of providing the
equivalent alternative...)
I think what is most important here is that James's statement is based
upon real testing (with published results) and not based on "opinion"
per-se, even when those opining are generally considered to be
authorative 99 times out of 100. (And this is not a dig at Joe, Andrew
or Chris, all "accessibilitistas" who have both contributed to the
general body of knowledge we have, and who I each respect individually)
All too often we base our decisions on hearsay and our personal
perspective, rather than quantative data. Perhaps it's because that
quantative data is often hard to come by, I don't know. But I salute
brothercake (and the others that contributed to his research) for both
tackling the topic and sharing the results. We need more of this type
of research and hard data/published results.
However, the reports of the death of NOSCRIPT are perhaps premature?
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
From: Sarah Horton
Date: Fri, May 05 2006 7:00AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
From: John Foliot - WATS.ca
Date: Fri, May 05 2006 7:20AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
Sarah Horton wrote:
> --- You wrote:
>> using <<NOSCRIPT> is certainly a predictable and stable way of
providing the
>> equivalent alternative...)
>
> Doesn't NOSCRIPT only come into play when a user has turned off
scripting? What
> about users who have scripting enabled but can't access content that
is
> generated using javascript? This seem to me to rule out NOSCRIPT as an
> equivalent alternative.
Explain - can you gives an example? I'm not saying <NOSCRIPT> is the
*only* way to solve a problem, only that it is still valid. The
brothercake article says a non-scripting alternative, of which
<NOSCRIPT> is but one of many.
"Blanket" solutions rarely solve problems... We must examine the
circumstances and then choose a viable solution, complete with testing.
My only point is that using the <NOSCRIPT> solution is still a viable
alternative - that it should not be dismissed out-of-hand simply because
other alternatives have emerged.
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
From: Sarah Horton
Date: Fri, May 05 2006 7:50AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
From: John Foliot - WATS.ca
Date: Fri, May 05 2006 8:20AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
Sarah Horton wrote:
> --- You wrote:
>
> can you gives an example?
>
> --- end of quote ---
>
>
> When I want to edit a to-do item in Basecamp, I can't select or even
see the
> edit option unless I use a mouse and hover over the to-do item.
This is not a problem with JavaScript, but rather poor development
technique: WCAG 1, Priority 2: 6.4 For scripts and applets, ensure that
event handlers are input device-independent.
I do not use Basecamp, nor have I examined their code directly, but
based on what you are writing here, the fix should be relatively trivial
for the basecamp developers (and I am surprised that this issue exists -
I was always under the impression that they were fairly attuned to
accessibility issues).
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
From: Andrew Kirkpatrick
Date: Fri, May 05 2006 10:00AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
> I think what is most important here is that James's statement
> is based upon real testing (with published results) and not
> based on "opinion"
My statement is also based on real testing. When I say that there are
better ways to provide a non-scripting alternative than to use noscript
and that one reason is that user agent support for progressive
enhancement is solid whereas user agent support, including in the most
commonly used screen reader, is not solid for noscript, that's my
opinion but it is based on facts.
> However, the reports of the death of NOSCRIPT are perhaps premature?
I didn't say it was dead, just that there are better ways that produce
more reliable accessibility that should be used instead. Show me an
example where it produces the best overall result and I'll use it.
AWK
From: Alastair Campbell
Date: Fri, May 05 2006 11:40AM
Subject: RE: NOSCRIPT question
← Previous message | Next message →
John Foliot wrote:
> This is not a problem with JavaScript [snip]
> ensure that event handlers are input device-independent.
I think this is the most pertinent aspect. The misunderstanding seems to
be that certain devices aren't using JavaScript, when they are (just not
well). E.g. JAWs is on top of IE (or Firefox), the browsers are capable,
it's just whether the screen reader uses it.
For the Basecamp type applications it seems to be keyboard access or
signifying page updates that are the main issues, rather than lack of
JavaScript. (Although I haven't read article linked below yet.)
> I am surprised that this issue exists -
> I was always under the impression that they were fairly attuned to
> accessibility issues).
This is bait for Monsieur Clark, surely ;)
http://joeclark.org/ice/iceweb2006-notes.html#Fried
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
t. +44 (0)117 929 7333 | = EMAIL ADDRESS REMOVED =
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Christian Heilmann
Date: Fri, May 05 2006 12:20PM
Subject: Re: NOSCRIPT question
← Previous message | Next message →
> In a recent article, "AJAX and Screenreaders: When Can it Work?"
> (http://www.sitepoint.com/article/ajax-screenreaders-work), James
> outlines a series of tests undertaken with specific scripts and specific
> AT (screen readers).
>
> James's conclusion?
> "I'm forced to conclude that, unless a way can be found to
> notify screen readers of updated content, AJAX techniques cannot be
> considered accessible, and should not be used on a production site
> without a truly equivalent non-script alternative being offered to users
> up-front." (NOTE, James says non-script, and not NOSCRIPT, but using
> <NOSCRIPT> is certainly a predictable and stable way of providing the
> equivalent alternative...)
I call b*******cks on that one. Sorry, a non script alternative is
something completely different than adding NOSCRIPT in the same
document. Especially with AJAX it is dead easy to only load the
content via AJAX and apply the event handlers to do so when and if
JavaScript is available. NOSCRIPT only tests if scripting is available
or not, not what is supported and the issue with AJAX apps is that
screen readers _do_ understand JavaScript but possibly don't notify
users about dynamic changes. This means that adding alternatives with
NOSCRIPT will not reach the intended audience - only those who have JS
turned off.
The matter of JavaScript, AJAX and screen readers IMHO cannot be
solved technically as we make ourselves as dependent on screen reader
types and versions as we did with browser sniffing in the times of
DHTML.
The only real way to make sure a screen reader user will not end up on
a page he cannot use is to offer the snazzy interface as an
alternative and not as a given and not use it as the basis for the app
and then hack it to become backwards compatible with NOSCRIPT and
other shenanigans.
NOSCRIPT means you mix JavaScript and HTML and that is just not a
clever move. If your application is designed to work only with
JavaScript then it is badly planned. I understand that it is very easy
to put together amazing applications with JS libraries or frameworks,
but if you want to be accessible you have to go the extra mile and
plan the app without it and add handlers and functionality if and when
the user CHOSE to do so. This is bad for marketing, but I really don't
see any other way around it.
--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/
From: Patrick H. Lauke
Date: Fri, May 05 2006 6:50PM
Subject: Re: NOSCRIPT question
← Previous message | Next message →
John Foliot - WATS.ca wrote:
> I do not use Basecamp, nor have I examined their code directly, but
> based on what you are writing here, the fix should be relatively trivial
> for the basecamp developers (and I am surprised that this issue exists -
> I was always under the impression that they were fairly attuned to
> accessibility issues).
Apparently 37 Signals isn't that hot on accessibility, as it's just
another additional feature which doesn't fulfill their "getting real"
hip agenda yet.
http://joeclark.org/ice/iceweb2006-test-results.html
http://joeclark.org/ice/iceweb2006-notes.html
P
--
Patrick H. Lauke
___________
re
From: Patrick H. Lauke
Date: Fri, May 05 2006 7:00PM
Subject: Re: NOSCRIPT question
← Previous message | No next message
Alastair Campbell wrote:
> This is bait for Monsieur Clark, surely ;)
> http://joeclark.org/ice/iceweb2006-notes.html#Fried
Gah, I need to stop reading my backlog of email list messages in
chronological order and replying to things, only to find that I'm just
repeating what somebody else has already posted later on...that's now
the second one just from this list. Just ignore me, I'll be on the same
page as everybody else soon enough ;)
P
--
Patrick H. Lauke
___________
re