Don’t reject a form entry too quickly

“Be flexible in accepting the data a user fills out in a field. If it’s not exactly in the format you want, change it for them in the code.

Note: this is best practice and not a WCAG requirement.

Date formats

Users may enter a different separation character than you expected and get the warning “Invalid date”. Though it’s actually not invalid; it’s just not in your expected format.

For example, January 1, 2026 can be entered as:

  • 01.01.2026
  • 01-01-2026
  • 01/01/2026

Why not help the user and transform the separation character in your software for them?

Be sure to make it clear in your field description or label whether the data is expected as “Month-Day” or as “Day-Month”, as these can be ambiguous.

Email addresses

Some people use a + in their email address, for example to make it easier to group emails.

They might use name+school@example.com for school-related emails and name+work@example.com for work emails. These are valid email addresses, so don’t reject them.

Email addresses with a plus sign are valid.

Postal codes

Postal codes can be written in many ways, for example in the Netherlands as: “1234 AA” (with a space), “1234AA” (without a space), or “1234aa” (lowercase).

US postal codes can either be five digits or five digits, a hyphen, and four digits, e.g. ‘12345-2345’ or ‘12345’. UK Postal codes vary in length between 5 and 7 characters in two parts, with both parts able to contain a mix of letters and numbers.

Extra spaces at the beginning or end can also be included when text is copied and pasted.

In code, these variations can easily be normalized to a single format. By accepting all valid ways and letting the software correct them, you prioritize the user instead of your software.