Form errors

Priority: 2

Introduction

As users attempt to complete forms, it is important they are notified promptly and clearly when they make errors, and are provided with assistance in fixing those errors.

For assistive technology users, completing forms can be especially arduous where one or more of the following are true.

The invalid state of a field is not communicated
The error message is not associated with the field
The presence of errors is not communicated on submission

The careful wording of error messages and descriptions is also important, as well as indicating which text is error text without relying entirely on color (see Color dependence).

WCAG criteria

3.3.1 Error Identification (level A)
3.3.3 Error Suggestion (level AA)

Scope of the issue

Marketing site

Home page (✖️ The “Get A Quote” form’s error is not associated to the form element and is not announced on form submission.)
About → Our energy (✖️ The “Get A Quote” form’s error is not associated to the form element and is not announced on form submission. Note that, because the field here uses required, a browser error message appears if the field is empty.)
About → Business (✖️ Presence of errors not announced on submission; individual errors not associated with their fields; Descriptions not part of field labels.)

Join site

Welcome page (✖️ The “Get My Quote” form’s error is not associated to the form element and is not announced on form submission.)
My information page (✖️ Individual errors not associated with their fields; form cannot be submitted until fields are corrected, so the presence of errors is not clear.)

Accounts dashboard

Login page (✖️ Individual errors not associated with their fields; generic “Wrong email or password” error not announced on attempted submission.)
Select an electricity meter reading (✖️ The page relies on browser validation, which is inconsistent with the bespoke implementation elsewhere.)
Tariff info (✖️ See image below — a message is provided to alert users of errors, but not as an accessible live region; the fields that have errors are not indicated at all, let alone accessibly with aria-invalid="true". Note that the “Okay” button is not necessary for any users. The error can simply disappear when the form successfully submits. Remove this button.)

Tariff page error message

Fixing the issue

Form error messages must be included consistently and accessibly across the sites.

Individual form errors

The following code example exemplifies a typical form field in its invalid/errored state, with notes to follow:


<label for="name">
  Your name:
  <div class="description">Including your forename and surname</span>
</label>
<input id="name" name="postcode" aria-describedby="name-error" aria-invalid="true">
<div id="name-error">
  <strong>Error:</strong> Please enter a valid post code.
</div>

If present, a description should be part of the label, so inside the label element (see About → Business where it is currently adjacent).
The aria-describedby attribute associates the input field to the error message element using the shared “name-error” cipher, in this case.
The aria-invalid property sets the state and tells assistive technology users who have focused the field that it is invalid. Note that you must explicitly write ="true". Just including aria-invalid (boolean) is not reliable.
The id value matches the aria-describedby value
To identify the error as an error, use spell it out (or use an icon, as described in Color dependence).

Announcing the presence of errors

You should let users attempt form submission and alert them to errors if they are present.

In the case of forms with multiple fields, a generic message should appear. This is the case on the About → Business page already. However, the message is not announced in screen readers because it does not belong to a live region.

If you are not familiar with live regions, they announce (in screen readers) content as it is added with JavaScript. The basic markup for an alert live region is as follows.


<div role="alert" aria-live="assertive">
  <!-- add anything here to have it announced in screen reader software -->
</div>

Here is a little demo, showing you how your form errors live region would work. If you are using a Macbook, simply press CMD + F5 to activate the Voiceover screen reader, then press “submit” to both reveal and announce the message.

“Get A Quote” / “Get My Quote”

These simple, one input forms do not need a separate announcement for invoked errors. Instead, the individual post code error message can be made a live region.


<label for="postcode">Your postcode:</label>
<input id="postcode" name="postcode" aria-describedby="postcode-error">
<div id="postcode-error" role="alert">
  <svg aria-label="Error:" focusable="false">
    <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="/assets/images/icons/forms.svg#error"></use>
  </svg>
  Please enter a valid post code.
</div>

Suppressing browser validation

Make sure your bespoke error notification system is consistent across the forms and sites, to reduce confusion. Where forms, such as the Select an electricity meter reading form (pictured) include automatic browser validation, suppress it by applying novalidate to the <form> element.

The Marketing site Home page quote form differs from the Join site Welcome page quote form in that browser validation is used for an empty field. Browser validation is not consistent between browsers, so each quote form should use the bespoke/JavaScript validation.

See Inconsistency for more.