Scripting
From Library
The Issue: While combining scripting with web pages offers the possibility of creating truly dynamic web pages, there are some pitfalls for individuals with disabilities, and those using alternative access devices.
Contents |
Standard 12.1
If web pages utilize scripting languages to display content or create interface elements, the information that is provided by the script will be identified with functional text that can be read by assistive technology devices.
Comments: There are two issues here. The first issue is the location where the script's code is processed — "client-side" scripting vs. "server-side" scripting. Simply put, client-side scripting (such as JavaScript) requires the code to be downloaded and processed on the user's device. If the user is accessing your site via an alternative device such as a PDA, a web-enabled cell phone, there is a possibility that their device is unable to perform processing at all. Consequently, they will not be able to access the information or functionality provided via the client-side script code. With server-side scripting (such as PHP, ASP, Java, etc.), the script code is processed on the server and the resulting HTML is sent to the user's browser. If what your script is doing is strictly presentational, then server-side scripting is a good alternative. If you're doing something like intense calculation, input validation, etc., then server-side options may become less attractive because of their impact on server performance.
Second, what 12.1 means is that if , for example, you're using a client-side scripting language such as JavaScript to make navigation elements appear, you need to provide an alternative means of accessing the navigation. This can be something as simple as reproducing your links as regular text links at some consistent location — e.g., the bottom of the page. This is not only an accommodation for people who are visually impaired. It also serves those using non-PC devices (e.g., PDAs, BlackBerry, web-enabled cell phones, Web TV) to access your site, and if script-based "rollovers" or "fly-outs" are involved, providing an alternative is also beneficial for people with mobility impairments.
Standard 12.2
Event handlers used in any script will be device independent. Device-independent event handlers will be used instead of event handlers that require a specific input device (e.g., mouse). If a generic event handler is not available, more than one device-specific event handler will be used.
Comments: Regardless of whatever scripting solution is used, you need to ensure that the page/functionality can be accessed with a keyboard. This is an accommodation for multiple groups of people with disabilities. A "generic event handler" is one that does not require a specific sequence to activate it. One example of a generic event handler is "onFocus." There are a number of different methods for advancing focus to a particular component, control or field.
This standard is related to Standard 13 — Forms, specifically 13.1, which requires forms to be accessible via keyboard, and 13.3, requiring that web developers use the tabindex attribute to create a logical tab order for form elements.
Standard 12.3
The use of onDBLClick event will not be allowed.
Comment: This standard reinforces 12.2, which says that event handlers must be device-independent. The "onDBLClick" event can only be triggered placing your mouse cursor over the affected control and double-clicking the left mouse button. Further, it is extremely difficult for some people with motion disorders to execute the double-click action, even if they are using an assistive-technology device that acts like a mouse.
Standard 12.4
A mechanism (e.g., a text notice - "The following link will open a new browser window.") will be in place to alert the user prior to the opening of an additional web browser, pop-up window or a redirect that disables a browser's back button.
Comment: When a new browser is spawned, a visually impaired user has no means of knowing that control has been passed to a new session/window and the the navigational context they expect (e.g., being able to use their browser's BACK button to return to a previous page) no longer exists. Warning a user before opening an additional browser window, and providing instructions in that new window for returning to their previous session eliminates the contextual problem.
Standard 12.5
All documents with client side scripting will provide equivalent content or functionality via a noscript element.
Comment: The intention here is the provision of alternatives to client-side scripting. This is becoming more important as misinformed "Internet Security" or "Identity Theft Prevention" advocates tell users with little technological expertise to turn off the scripting capabilities in their browsers to escape from the dangers of malicious code.
This is also an accessibility issue for a wide variety of users, not just people with disabilities, but people using alternative access devices as outlined above. There is a way to provide equivalent functionality via the noscript element in HTML. To see an example of how the noscript option is employed, take a look at the example DCAAccount or Tax Credit Worksheet. To see the page's functionality, turn off your browser's scripting capability and reload the page. You can see how the noscript element is employed by clicking on your browser's View menu and select "Page Source."
