For individuals who rely on assistive technologies such as screen readers or refreshable braille displays scripting can cause unexpected navigational problems, rendering the page unusable and often leaving the user feeling disoriented. This section discusses some common scripting methods, critiques each on their accessibility, and presents possible solutions to make them accessible.
If the browser or assistive technology does not support scripting, the NOSCRIPT tag can provide a textual alternative, usually in the form of HTML. Using the NOSCRIPT tag largely depends on what the script is trying to accomplish. If new information is being generated by the script, then yes, use it. Otherwise, for simpler scripts (such as rollovers), using the NOSCRIPT tag may not be necessary.
One thing to keep in mind is that the NOSCRIPT section can almost be viewed as a separate web page; some think of this as a good solution - a graphic-intense, script-laden site, and a simple HTML site. While this still works, it has a maintainability problem. Changes in one section need to propagate to the other, leading potentially to twice as much work.
This is a little awkward for the developer, because scripts are supposed to add functionality to the site, and not cause problem after problem. The developer needs to be aware of which scripting methods can be used and which should be avoided. In general, if it is not possible to make the site accessible because of the scripting, the developer should rethink the design, or provide its textual equivalent in the NOSCRIPT section.
<SCRIPT language="JavaScript1.1">
<!--
// Script goes here ...
// -->
</SCRIPT>
<NOSCRIPT>
<HTML>
<P>A textual equivalent of the site goes here ...</P>
</HTML>
</NOSCRIPT>
There are two things to note about this example. The first is that the use of NOSCRIPT tags contains a textual equivalent. The second is the HTML comment inside the script. When some browsers, especially older browsers, find a tag they are unfamiliar with, they assume it is insignificant and skip it, but will still try to interpret the data inside the tags. Having the comment inside the script hides the script from browsers that do not support scripts, but still allows the script to run for browsers that support script.
Sometimes, there are certain actions that can only be accomplished through scripts. If this is the case, and you feel the script provides necessary functionality, consider making it a server-side script. This is a more controlled situation because, while you do not know the configuration of the end-user's browser, you do know the capabilities of the server. Server-side scripts are processed on the server, they send plain HTML to the client's browser, and therefore do not cause the same accessibility problems as do client side scripts. Server-side scripts, however, are not as dynamic as client side scripts. Server side scripts can put an additional burden on the server, but may be the only way to overcome the no-scripting problem.
The next page will discuss scripting events.