Validation

Validation lets a user know that they need to amend the information they have entered. It should be flexible - allowing a person to enter information in the way they naturally would.

Example

Example

Example form

We’ll only use this to contact you about your will

HTML

                                    
<!-- Validation -->
<form id="validation-demo" class="coop-form" novalidate>

  <!-- Validation summary (empty) -->
  <div id="validation-demo-box" class="coop-c-message coop-c-message--error" tabindex="-1" role="alert" hidden></div>

  <h3>Example form</h3>

  <div class="coop-form__row">
    <label class="coop-form__label" for="validation-demo-name">Your full name</label>
    <p id="validation-demo-name-error" class="coop-form__error" hidden></p>
    <input id="validation-demo-name" class="coop-form__field coop-form__input" type="text" autocomplete="name" name="validation-demo-name">
  </div>

  <div class="coop-form__row">
    <label class="coop-form__label" for="validation-demo-email">Your email address</label>
    <p id="validation-demo-email-hint" class="coop-form__hint">We’ll only use this to contact you about your will</p>
    <p id="validation-demo-email-error" class="coop-form__error" hidden></p>
    <input id="validation-demo-email" class="coop-form__field coop-form__input" type="email" autocomplete="email" name="validation-demo-email" aria-describedby="validation-demo-email-hint">
  </div>

  <div class="coop-form__row">
    <button class="coop-btn coop-btn--primary" aria-live="assertive" aria-relevant="additions text" aria-atomic="true">
      <span class="coop-btn__text" role="status" hidden>Updating details…</span>
      <span class="coop-btn__text">Update details</span>
    </button>
  </div>
</form>

                                    

Design and content

Build services that are flexible enough to allow users to give data in a way that they would naturally. For example we should allow users to enter a postcode in upper or lower case, with or without a space.

Validation messages should only be triggered on mandatory fields. They must be factual and help the user move on.

Make sure validation messages in the error box at the top of the page start with a lower case letter. Do not use full stops.

Make sure inline validation messages are sentence case (the first letter is capitalised). Do not use full stops.

Be certain.

Say: That’s not an email address

Do not say: That does not look like an email address

If the input field is empty, use an imperative statement.

Say: Enter your full name

Do not say: Full name must be entered


If our systems require certain formats and the user needs to change what they’ve entered, tell them what the requirements are.

Avoid passive language.

Say: Enter the hours you work a week as a whole number, like 30

Do not say: Hours worked a week is not valid

Other examples

GOV.UK in some cases does not use the imperative form and this breaks the grammar rules following the lead-in line. We do not do that at Co-op, instead we restructure the messaging to be front-loaded with an imperative.

But the GOV.UK Design System has a long list of examples for how to handle different input requirements which you might want to refer to for inspiration.