- Runs as a page is loaded and in response to events
- OnClick works for both mouse and keyboard users, but OnMouseOver only works for mouse users
This function called increment adds 1 to the value of the input element named quantity1 in the form named firstform.
This function can be assigned to the event onMouseOver on an image or link or other element like this:
<span onMouseOver="increment()">This triggers increment</span>
Now every time the mouse passes over the text "this triggers increment" the specified input element (quantity1) will be incremented.
- To be accessible your page must "be usable" with scripting turned off
- Two priority 1 checkpoints from WAI guidelines:
- Ensure pages are usable when scripts, applets and other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on alternative accessible pages
- Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
The of the W3C took the position in the that to be accessible your page must "be usable" when scripting is turned off. If your scripts are essential in creating content on your page, then probably your page won't be usable with scripts turned off.
Here are the two priority 1 checkpoints from the WAI guidelines that deal with scripts.
Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]
The Section 508 Standard
- Functional text should be added to pages using scripting languages to display content, or create interface elements.
When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
An example (one which was a motivation for the way Â§1194.22 (l) was worded in the final rewrite of the Standards) where this is not done is a shopping site where there are pairs of arrows pointing up and down to increase or decrease the desired quantity of each item in a shopping cart.
Those up and down green arrows are, in fact, part of a small image map and the area elements of the map are coded like this:
By the way, the functions b(x) and qtydn3(x) are similar to the sample increment( ) function that we saw as an example previously; b is increment and qtydn3 is decrement.
If a web page uses scripts to fill contents of a form with basic default values, then most likely that aspect of the page will be accessible to contemporary assistive technology, specifically screen readers.
- Web Accessibility Initiative Guidelines
- Direct and simple
- Section 508 Standard
- Neither direct nor simple
- Check the usability of a page by turning off scripting
Tools / Internet Options / Security / Internet
- Select Custom Level
- Go to the scripting section and select the radio button to Disable Active Scripting
Tools / Options / Content
Accessibility Problems With Events
- All basic functions must be available using only the keyboard
- Select menus should not use onChange - use a submit button
The Section 508 Accessibility Standards include provisions relating generally to Information Technology; in addition to the web, the accessibility of Software, Telecommunications, Video and Multimedia, Self-Contained Units, and Desktop and Portable computers are all covered. A key provision in the Software Standards requires that all the basic functions be available from the keyboard.
When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
An example of such a keyboard issue is a select menu presenting list of pages like, Headlines News, Sports, Financial, Theater, etc. The select element is coded with an onChange event handler that gets executed when the selected value of the menu changes. The event handler opens the desired page. The reason it is becoming more common is that using the mouse is more efficient than having to make the selection and then click on a Go button.
The problem is that under some circumstances, if you cursor up or down in the menu after it gets focus, the onChange event handler is triggered and you are on the way to the new site before you even viewed the options. The used to contain such an example. The select menu at the top left triggers the onChange event.
<select ... OnChange="location=this.options[this.selectedIndex].value;">
A mouse user just opens the pull-down menu, then clicks on, say, CNN Europe. This causes the CNN Europe page to open.
However, when a keyboard user Tabs to the select menu with the "CNN Sites" entry and starts to move down the menu with the arrow keys, immediately the browser opens the next site ("CNN" in the screenshot above) because, keyboard movement in the menu is seen as a change (triggering the OnChange event) and the action is immediately taken. With this (accepted) keyboard interaction, the user would never be able to get past the first item - which, by the way is the page where all of this is taking place.
There is a keyboard alternative that I fear even today is not well known amongst keyboard users. After landing on the select menu, if the keyboard user opens the select menu with Alt+Down Arrow before moving down with the arrow keys, then the menu behaves correctly.
The way to completely avoid this problem is to include a submit button next to the select menu and use that to submit the request. (Remember to use alternative text if you use an image button.)
Unfortunately, web developers are not likely to know which events do not work with the keyboard because they use onChange events and only test with the mouse.
Note that it is not that onChange itself is bad or not accessible. For example, if the function assigned to the onChange event modifies a value in some other input control, then moving through the select menu with the arrow keys would make several changes, and presumably all of them would be OK. There is a problem when the onChange event handler loads a page.
At the , if you want to look up a word in the dictionary, a select menu displays a list of up to six dictionary entries for the desired word.
This is achieved with the size attribute set to a value greater than one (in this case size="5"). With an onChange submission mechanism, the browser immediately submits the request when you use an arrow key with focus on the menu. This example is not accessible from the keyboard.
If you use select menus with size greater than one, then couple the select menu with a submit button; don't use the onChange event on the menu. The bottom line here is that you need to make sure your pages can be used by a person who is not using a mouse.
The issues of keyboard access on the web are huge in the new world of Web 2.0 and Ajax. Those problems make the select menu problem appear like a nit; and it is in comparison. At least there is a simple and clear choice to fix the select menu problem (Use a submit button) - not so for Web 2.0 (more below).
- Direct Content
- Changes in Attributes
- Verification in Forms
- Hidden Content
At the beginning of the course we discussed the idea that web guidelines or standards served as a definition of "accessibility." The idea is that those guidelines tell you specifically what you must do and what you must not do on your page to ensure that your web site is accessible, i.e., usable by people with disabilities, especially those using assistive technologies. Those specific standards soften the requirement that you understand how folks with disabilities use your site or how their assistive technology works.
- Scripts can write visible content directly to the document (document.write)
- Meets Section 508 standard
Scripts can write visible content directly to the document, for example, with document.write. This is done when the page is loading.
A simple example of this is writing the message indicating the last date the page was modified so that when changes are made, the message updates itself - automatically.
Here's the code for this example.
If this script was placed at the bottom of the page, then the script would write a "last updated" message there.
<noscript>Last updated: 10/19/2007</noscript>
Of course, in doing that you would have rendered useless the whole purpose of the script in the first place because you would have to remember to update that noscript code any time the page was changed! That statement is at the heart of the idea of providing an accessible alternative to inaccessible content; such alternatives are rarely updated when the "normal" content is updated.
Rarely is the noscript content useful.
Changes in Attributes
- Event handlers can change images or attributes of content (ex. highlighting text)
Event handlers can change images or attributes of content, like highlighting or text color.
Here is an example.
When you move the mouse over the the table cell above, the onMouseOver event handler causes the background of the table cell to change from a white background to a yellow background. It changes back to white when the mouse moves out of the table cell.
Verification in Forms
- Event handlers are often used to verify correct information in forms
- Does not interfere with assistive technology
Script event handlers are often used to verify that information is entered correctly in forms. They can also enter or modify data as in the example at the beginning of this lesson. Tasks like this make things happen more quickly. You can tell when sites don't do this; you submit a form and the server returns an error page. In the worst case, you return to the page that has the form you are working on with the Back button and all your entries are gone. You fix error one, and after a wait, a second error page is sent. And so on. When the checking is handled at the client, it is quicker and more convenient.
Here is example code that will check to see if a user has entered a valid zip code:
CheckZip can be assigned to the onSubmit attribute in the form element. The alert will inform the user of the error and, by returning false, the form will not be submitted. The function also clears the input field where the zip code is being entered.
I worked some with Gez Lemon at JuicyStudio on an article that takes the next step for form validation and dealing with errors in an accessible way. Here is his summary:
This article investigates a method of providing client-side form validation through the DOM, and ensures that it works as expected with screen readers. Modern screen readers work relatively well with scripting, but it's the extra steps required to inform screen reader users that the content has changed that needs addressing.
- Scripts often write content to internal frames, or write in a manner that the content is not visible or is hidden
- Accessibility depends on the events used to trigger the exposing of hidden content
- Ensure you can access the function with a keyboard
- Ensure the content is available to assistive technology
Often scripts write content to internal frames or they write in a manner that the content is not visible or is hidden. Depending on user interaction, hidden content is made visible and, perhaps, other visible content is made invisible. Typical applications are the so-called "fly-over menus" and "plus-to-expand" navigation areas. It is with this hidden content that the issues of scripting and accessibility get really complicated.
The accessibility issues with this kind of scripting depend on the events used to trigger the exposing of hidden content. If the event is onMouseOver, which is typical of menus, then generally that content is not accessible.
An example is the . Note in the screenshot, the pull-down menu resulting from the mouse being over the "Publications" menu item. (This is a screenshot of the NSF page in 2001. Today a similar idea is implemented in Flash.)
The information in the pull-down menu (What's New, Most Popular, etc.) is not available to screen readers or keyboard users. When you tab into the NSF site, you get the main navigation menu links, About NSF, Funding, Publications, etc., not the sub menu links. This is not a problem for this site. If you follow the "Publications" link, which, itself is perfectly accessible, then the resulting page has those fly-over submenu links prominently available in a normal navigation position as can be seen with the following screenshot.
It is clear in this case that the fly-over menus offer a relatively minor convenience for sighted (mouse) users and a relatively minor inconvenience for those who are not using a mouse. Lacking access to those submenus does not make the site inaccessible. In fact, if the submenu links were in the tab order it would be bad. A menu system is only useful for keyboard users if you are
If content is exposed with the onMouseOver event for a link, then for your site to meet the Section 508 requirement for scripts, that content must be available elsewhere, preferable prominently displayed on the page that is opened by that link.
Notice how the links "Home," "Training Products," and "Training Offers" have opened up below "MSDN Training." Also the "plus" in a square graphic has changed to "minus" in the square. In addition, the screenshot shows that the tab "News" has been selected and the bottom center of the page now has new content corresponding to "News," instead of "Features."
If you have content like this, activated with the onClick event, then you must be sure that you can move with the Tab key to the links that do the expansion - and that the expansion works with the Enter key. Unplug your mouse! These keyboard tests are successful with the MSDN site shown above.
On the MSDN site both conditions seem to be met; also all the hidden content is exposed when scripting is turned off.
The screenshot above shows MSDN with scripting turned off. Notice that all the "plus-to-expand" items are expanded (even though the "plus" is still there) and the blue bar of tabs is gone, replaced by only one "tab" - the Features tab. The other sections of content like "News" and "Columns" are farther down the page.
Perhaps, like MSDN, the data on your page is available when scripting is turned off. It is still much better to test your site with assistive technology with scripting turned on. Use a screen reader and/or a talking browser to verify that the links to unhide content can be activated and that the content is available to the blind user.