Avoid Default Field Validation

HTML5 gives us form field validation for free. The problem is that the default messages browsers provide are not always useful and typically do not work with assistive technology.

I made an example on CodePen that uses an email field (type="email"), is required (required), and uses a pattern to restrict the email address to the domain foo.com (pattern=".+@foo.com").

<form action="#" method="get">
  <p>
    <label for="email">Email</label><br>
    <input type="email" id="email" required pattern=".+@foo.com">
  </p>
  <p>
    <input type="submit">
  </p>
</form>

See the Pen Untitled by Adrian Roselli (@aardrian) on CodePen.

I then fired up three Windows screen readers across four browsers and recorded the output. Note how in each case the browser announces the field as invalid as soon as it gets focus. It also does not identify what the pattern is for the field, nor when the field has become valid (meaning we got the format right).

Using required on its own will not identify to all users in plain text that a field is required. You will still need to indicate it in the text label otherwise you could fail 3.3.1 Error Identification (A).

If you use a pattern, you cannot rely on the browser to show the user what the pattern is. If you do not explain it as part of the accessible name, you can fail 3.3.2 Labels or Instructions (A) and 3.3.3 Error Suggestion (AA).

The default browser error indicator, when one is shown, tends to be a red outline. With a default contrast ratio of 4.0:1 on a white background, it would not fail 1.4.11 Non-text Contrast (AA) as noted in John’s comment below, but that is still not very good. Relying only on the outline would also fail 4.1.2 Name, Role, Value (A).

I am making some broad statements here. But by the time you amend the default error handling, replace the text, create better styles, and ensure states are conveyed to assistive technology, you might as well skip the built-in and write your own.

Don’t take my dismissive tone to mean that writing your own is easy. It takes some rigor, as this post on required and aria-required demonstrates. But it is part of the job.

Update: 4 May 2022

Three years on and this post is still accurate. The disappearing error messages in Chromium are one ongoing challenge, and browsers still do not respect zoom.

For the zoom issue, Cezary Tomczyk filed an issue against Chromium and I filed an issue against Firefox and WebKit (with videos):

• 1322462: The form control error message doesn’t zoom while zooming in on the page (CMD +/- on MacOS)
• 1767863: Default field validation messages do not zoom with page
• 240077: AX: Default field validation messages do not zoom with page

I also filed an issue against Chromium for the message timeout:

• 1322670: Default field validation messages self-dismiss when they should persist

Update: 5 May 2022

To tweak the above a bit, Chromium browsers on Windows will scale the default error message, but not while it is displaying. The message has to be redrawn to honor the page zoom. Since they self-dismiss, I guess this forces you to regenerate the error to see it at the preferred size?

Update: 10 August 2023

Progressively Enhanced Form Validation, Part 1: HTML and CSS at the Cloud Four blog goes beyond what I talk about here and looks at CSS pseudo classes for form elements and their actual support.