Web Access Centre

JavaScript and forms - Web Access Centre

Summary: JavaScript can be used in forms as long as an accessible alternative is presented.

• Rationale
• Techniques
• Testing tips
• Further information
• W3C WAI compliance
• Other pages about accessible scripts and forms

---

Rationale

Forms are a crucial part of a website allowing people to place orders, send valuable data, comments and information via the web. They are also used to provide search boxes and perform login validation among a range of other interactive tasks.

Some forms rely on client-side scripting to perform calculations and display the result, to change parts of the form in response to user selection in other parts of the form, to check the validity of the information the user has entered, and even to submit information to the server. All of these actions can cause problems for some users of access technology or people who do not have a script enabled browser.

Using JavaScript or similar scripts for form functionality has the advantage of being both faster and more flexible, and there is no reason why they should not be used. However, you must also provide server-side equivalent functionality or accessible alternatives to support people whose software cannot properly well with scripts.

Techniques

• Allow natural focus, rather than using script to automatically position the cursor in particular form fields.

For instance it is becoming common to find that scripting has been used to place the focus in the first element in a form when the user arrives on the page. This can disrupt the synchronisation between where the physical cursor is and where a screen reader's focus is, making it difficult or impossible for the screen reader user to fill in the form.

Another use of JavaScript to control the movement of the focus is where the cursor automatically moves from one form element to another when the required number of characters have been entered in a text input box. This can make it impossible for a keyboard user to use SHIFT-TAB to go back through preceding form elements to correct an error.

• Use server-side submission, even if JavaScript is used to carry out most of the form validation, it shouldn't be used to actually submit the form content. This would make it completely impossible for anyone to send their data unless their browser supported JavaScript.

If client-side scripting is used to validate the information entered in a form, provide fall back server-side validation in case client-side scripting is not supported.

• Static alternatives are essential if scripting is used to amend a form dynamically as the user fills in certain fields. Provide a link to the static version for those who have problems reading and filling in dynamically changing forms.

For instance a static alternative will be needed if the ONCHANGE event is used to make dynamic changes to form content. ONCHANGE occurs when a form control loses the input focus and its value has been changed. This attribute applies to the elements: INPUT, SELECT, and TEXTAREA.

The problems this can cause are that a user cannot access the available options if they can only use a keyboard. As soon as they use the down arrow or start to type to find out what the available options are, the ONCHANGE event occurs, leaving them wondering what went wrong.

In addition, screen reader users may be disoriented by automatic redirects, especially if the refreshed form positions the cursor in the next field to be completed. This may be visually obvious but the screen reader's focus is not controlled by the script and may have started reading again from the top of the page and the users may not understand why.

The following example code would produce an inaccessible dropdown list of options:

The script might be:

<script type="text/javascript" language="Javascript">

function DynamicChange() {

var list = document.form1.select1;

var listValue = list.options[list.selectedIndex].value;

window.location.href = listValue;

}

</script>

The form itself might look like this:

<form name="form1">

<label>Choose currency:

<select

name="select1"

onChange=" DynamicChange ()">

<option value="ffranc.html">French francs</option>

<option value="gbp.html">UK pounds</option>

<option value="usd.html">US dollars</option>

</select>

</label>

</form>

Note that this code triggers the selection as soon as it has been "chosen". However, keyboard users need to use the arrow keys to find out what the options are. By doing so, they would trigger the ONCHANGE event, selecting the second option, without ever finding out what the third option might be.

One solution would be to provide a button that triggers the link to the selected option, rather than make it happen as soon as the selection changes.

The script might be:

<script type="text/javascript" language="Javascript">

function useGoTo() {

var list = document.form2.select2;

var listValue = list.options[list.selectedIndex].value; window.location.href = listValue;

}

</script>

<noscript>

<a href="altform.html">Alternative form for users who do not have JavaScript enabled</a>

</noscript>

The form itself might look like this:

<form name="form2">

<label>Choose currency:

<select

name="select2"

<option value="ffranc.html">French franc</option>

<option value="gbp.html">UK pounds</option>

<option value="usd.html">US dollars</option>

</select>

</label>

<input type="BUTTON"

name="Button1"

value="Go"

onclick="useGoTo()">

</form>

The only difference between these two code samples functionally, is that the second, more accessible code produces a button, allowing users to trigger the link after they have made their selection. However, please note that a link to a server-side version of the form has been given within the NOSCRIPT element.

• Provide warnings if pages will time-out. If possible, provide a control to allow users to override the time limit if they need to. When the time-out function refreshes the page, make sure that a login facility and links to other areas of the site are made available.

For more guidance on this, please refer to the section called Time-outs, page refreshes and auto-redirects , a link to it is provided at the bottom of the page.

• Placement text and initial values can be provided in form fields as prompts. If they are, ensure deletion of placeholder text and values as soon as the cursor focus moves to the field. It is important not to rely on placeholder text to convey the purpose of the field on it’s own, a text label must also be provided.
• Keyboard controls can help users navigate around a form. Provide ACCESSKEY controls together with ONKEYPRESS and ONCLICK event handlers.

For details on how to do this, please follow the, " hidden navigation link provided under Further Information.

Testing tips

Server-side rather than client-side scripting must be relied on. Ensure the form can still be used when scripts and style sheets are turned off. Changes to the page must be server-side with a Revised Version of the page sent back to the user's browser, OR an alternative, static version must be provided.

• Automatic testing tools - Automated tools can flag up pages with forms on, other methods must then be applied to ensure that the forms are accessible.
• Accessibility toolbar – IE Options - Toggle JavaScript (switches support for JavaScript off and on) AND Doc Info - Identify Applets / Scripts [new window].
• Browser - View - Source. Edit - Find - "script". AND Tools - Internet Options - Security - Custom level Scripting then check "Disable active scripting"
• Text browser - If links do not open or other functions are either not working or invisible, then JavaScript is used without accessible alternatives, as Lynx has no support for JavaScript. Check an alternative is present in the page.

Further information

• Hidden navigation – find out how to provide helpful additional keyboard navigation in your forms.

W3C WAI compliance

• 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. Priority 2
• 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. Priority 1

For more information on techniques visit the Web Accessibility Initiative techniques page.

Other pages about accessible scripts and forms

• Accessible JavaScript
• Dynamic menus
• Forms
• JavaScript in forms
• Time outs, page refreshes and redirects

Back to Design & Build

For Web access centre updates email webaccess@rnib.org.uk

Content author: webaccess@rnib.org.uk

Last updated: 06/03/2008 15:41