Please enable javascript to view this page in its intended format.

Queen's University

Web Standards and Accessibility Guide

JavaScript and other client-side scripting

Standard: All Queen's University web pages that employ client-side scripting must be done with JavaScript (ECMAScript). VBScript must not be used.

For greatest cross-browser and cross-platform compatibility, JavaScript must be used for any client-side scripting . The use of proprietary scripting languages like VBScript should not be used as they are only supported in specific browsers/user agents.

Standard: All Queen's University web pages must be fully functional without the use of JavaScript.

The use of JavaScript does not itself cause accessibility problems. However, the indiscriminate use of JavaScript to provide mission critical functionality can be the cause of accessibility and usability problems.

JavaScript is typically used in several key areas:

  • Form validation: where JavaScript is used to determine if required fields are empty or meet certain criteria
  • Dynamic menus: where JavaScript is used to create "fly-out" or "dropdown" menus.
  • Pop-up windows: where JavaScript is used to open web documents in new windows.
  • "Browser sniffing": where JavaScript is used to detect browser versions

There are no hard and fast rules on when or when not to use JavaScript. The criteria must always be, "What will happen if the JavaScript does not work?" If key functionality is lost, or information is missed or missing, then JavaScript cannot be used. If, however, there is a fall-back solution which ensures equivalent (though not necessarily identical) functionality, then developers are free to use client side scripting such as JavaScript.

Regarding the example above for form validation, very often developers will use JavaScript to ensure that all form fields have been completed, a script that will return an error if a form field is left blank. In this case, if JavaScript has been disabled by the end user or is not supported by the user's browser, the means to verify the form's "completeness" has been lost. What are the ramifications of this? If one of the form fields is crucial for further progress (i.e., you must have the user's email address to send them the transcript they have requested, but they did not provide it), and the JavaScript which is supposed to check for this information does not work, what are the consequences? The entire process fails. The following Standards address these possible scenarios and mandate appropriate fallback scenarios or techniques.

Recommendation: All Queen's University web pages that use forms should use server-side validation and be able to be submitted without using JavaScript. The forms can be further enhanced by JavaScript-based form validation but must not rely on it.

JavaScript can easily be disabled and/or circumvented - either deliberately by an IT department concerned with security, or inadvertently when a script doesn't completely load or is broken. Often forms will require certain conditions to be met before the form can be submitted, meaning that if JavaScript is "off" the form cannot be submitted at all.

For this reason, a server-side scripting language should be deployed for this type functionality. Whether it is ASP, PHP, JSP, ColdFusion or CGI , the scripting language is secondary to the functionality. Developers are free to use the scripting language they are most comfortable with.

Standard: All Queen's University web pages that use dynamic fly-out or dropdown menus must not rely on JavaScript to create or navigate to the top level menu items.

Using JavaScript to create the menus on a page - including the top-level navigation items - means that a user without JavaScript support will be unable to navigate the web page. Care must be taken to ensure that default navigation is available for all users.

Think of JavaScript as an enhancement for the page. Once your initial HTML is fully functional, JavaScript can is used to enhance the experience for someone that has JavaScript capability.

In a navigation menu, for example, if you use JavaScript to create dynamic menus (often called fly-out or dropdown menus, depending on their implementation), you should only use JavaScript to create the dynamic part of the menu and not the main menu items itself. The main menu items should be created in basic HTML and point to a page that contains all of the same links that appear in the submenu.

There are many CSS techniques that can be used to provide alternatives to JavaScript-based functionality, each of which is dependent on context. Having a base of semantically structured, meaningful HTML helps significantly with this requirement.


Standard: All Queen's University web pages should not spawn pop-up windows. Though the practice is discouraged, full new windows (including menus, toolbars etc) may be opened for linking to external sites if the link indicates that the page will open in a new window.

Pop-up windows should not be used on Queen's University web pages. They can cause difficulties with novice users for a variety of reasons, and can disorient people that are using screen reading or screen magnification software. In many cases they can also be resource intensive.

Most new browsers and browser add-ons like the Google toolbar, for example, include the ability to block popup windows. To ensure that the content is available to all users, either include the content in a page of its own, or display the content in the original page itself.

Most user agents allow the user to specify if links will open in a new window. It is recommended that the user be in control of how links open in their user agent -- this is the preferred method for dealing with external, off-site links. If new windows are opened, they must be opened with full menus, toolbars, address bars, and status bars available. It must be clearly indicated that the link will open in a new window.

Example: "TheW3C web site provides the definitive HTML specifications: (Note: this will open in a new browser window)"


Standard: Queen's University web pages must not employ "browser sniffing." Web pages that utilize scripting must utilize DOM-compatible capability-testing instead of testing for specific browsers.

In the earlier days of the Internet, different web browsers were, to varying degrees, dependent on proprietary code. Web pages, then, were viewed with varying degrees of success depending on the differences between the browser that the site was scripted for and the browser that was being used to view it.

To counter this, JavaScript was often used on a site to detect what kind of browser a website visitor was using to view that site, and multiple versions of the same web page were maintained, each created to meet the needs of a particular browser.

Browsers have now developed to a point where using JavaScript to test for specific browsers and delivering different content depending on the browser detected is no longer required and is contrary to principles of universal design.

The user-agent string - the "invisible" bit of information that is sent to the web server and the information that the JavaScript is "sniffing" for - of a browser can be easily manipulated to override any intended scripting effects. For example, the Opera browser can be configured to "pretend" that it is Internet Explorer, even though it clearly is not. Given that we can no longer rely on the accuracy of the user agent string, and given that new browsers would use a new user agent string, it is impractical to use these techniques. Developers would have to continually perform compatibility testing with the release of new browsers to ensure their scripts are functional.

The modern equivalent of browser sniffing is the more robust DOM (Document Object Model) capability sniffing. These techniques will ensure that new browsers require less modification of scripts and less testing.

Moving forward, legacy documents should be reviewed with these scripting issues in mind.



Kingston, Ontario, Canada. K7L 3N6. 613.533.2000