This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.

Validating Input

in Forms Tutorial

Custom validation needs to notify users in an accessible way as described in the User Notifications part of this tutorial. Client-side validation alone does not ensure security; therefore data needs to be validated on the server-side as well.

Validating required input

Forms frequently include required input that needs to be clearly identified using labels. Also, the required attribute can be added to form controls, to programmatically indicate that they are required. Most current web browsers support this attribute and will communicate missing required input to the user, using standard web browser dialog mechanisms. These dialogs are expected to respect the settings and preferences of the user in the web browser (and operating system), such as default font-size, colors, and language.

In the example below, the required attribute is added to the input field. If your web browser supports HTML5, it will not allow you to submit the form without entering text into the input field. Instead, it will display a message that is generated by the web browser itself.

Note that the label also displays “(required)”, to inform users that don’t use assistive technology or use older web browsers that do not support the HTML5 required attribute.

Validating common input

HTML5 also provides input types for other data, including email, url, number, range, date, or time. Most current web browsers support these features and handle input validation. Also, HTML5 validation helps users inputting data by providing specific controls, such as date pickers and custom on-screen keyboards. HTML5 input types are displayed as simple text input fields in older web browsers that do not support these HTML5 features.

The example below shows these HTML5 input types in action. Depending on your web browser, the “Range” input field will be displayed as a slider control to help users provide input more easily. Similarly, the “Number” input field may be displayed with buttons to increase or decrease the number incrementally. Input errors, such as an incorrect email address, will be indicated using the web browser dialogs as in the previous example.

Validating patterned input

The HTML5 pattern attribute allows the use of regular expressions to specify custom formats for the input. This is useful for specific types of data patterns such as telephone numbers, postal codes, and serial numbers.

Car license plate numbers

In the example below, the pattern attribute of the input element specifies a particular format that matches car license plate (registration) numbers in Germany. The required pattern consists of one to three letters (for the city where the car is registered), followed by a space, two to four random letters, another space, then one to four random numbers.

Be forgiving of different input formats

Validation should aim to be as accommodating as possible of different forms of input for particular data types. For example, telephone numbers are written with different separators and digit groupings. Your form will be easier to use if it can interpret multiple notations. Also, it is helpful to be liberal with input. For example, postal codes aren’t confined to just numbers in some countries, so using an input of the type number can easily become a problem for many of your website users.

Client-side validation benefits

In general, client-side validation results in a better user experience and makes resolving validation errors more understandable. It can also reduce network and server load. However, not all web browsers support HTML5, or they may not support your custom validation scripts. Client-side validation can also be easily bypassed, or the data is changed before reaching the server. This means that validation needs to be carried out server-side as well.

Validation by the user

Where possible, users should be able to check their input and correct it if necessary. This is particularly important for actions that are permanent or otherwise critical, but also when data cannot be automatically checked. For example, providing users with the option to check the postal address that they provided can be useful before a purchase is completed.

Require user confirmation

Where possible, require user confirmation for irreversible actions, such as permanent deletion of data. Examples include:

Provide undo functionality

Where possible, provide mechanisms to undo reversible actions. Examples include:

Back to Top

This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.