eBay

Form Validation

Errors after form submit

Introduction

Form validation notifies users of invalid and missing data after a user has attempted to submit the form.

To validate a field before the user attempts to submit the form, please view the input validation pattern. You may wish to combine both patterns, but for simplicity we will be assuming that only form validation is active.

After attempting to submit a form, the validation results can either be rendered immediately on the client, or rendered after a full page reload.

NOTE: Do not rely on built-in browser validation of HTML5 input types (email, tel, date, etc.). HTML5 validation is not widely supported and is not always accessible.


Working Examples

You can take a look at the form validation pattern in action on our examples site.


Terminology

Form Validation
The pattern as a *whole*, containing the top notice, error links, invalid inputs and inline notices.
Top notice
Region containing error message and error links.
Error link
Internal link that moves focus to invalid input.
Invalid Input
An invalid textbox, checkbox, radio or listbox
Inline error
Displayed next to an invalid input

Best Practices

Immediate client-side results must be rendered using a region notice directly above the form.

A full-page reload must render a page notice at the top of the page.

In both cases, the notice must contain a list of errors that link directly to their respective invalid inputs.

The errors must be visible to all users. Do not try and hide the errors from sighted users!


Interaction Design

This section provides interaction design for keyboard, screen reader and pointing devices.

Keyboard

The page notice or region notice must receive programmatic focus when rendered, but should not be in tab order.

Activating an error link must move focus to the invalid input.

Inline errors adjacent to invalid inputs must not be focusable (unless they are links).

Screen Reader

User must receive notification of all errors preventing progress.

An invalid input must notify user of the invalid state and the error description.

Page notice o=and region notice must be listed as custom landmark and labelled appropriately with aria-label.

Pointer

Awaiting content for this section.


Developer Guide

Our implementation follows the Progressive Enhancement strategy. We build in a layered fashion that allows everyone to access the basic content and functionality of a web page.

The three layers are:

  1. Content (HTML)
  2. Presentation (CSS)
  3. Behaviour (JS)

Content (HTML)

We should never depend solely on client-side JavaScript to validate an important form. Our baseline functionality must be to submit the form to the server for processing, which will display any results after a full page reload.

We will be assuming that the following form has been submitted by the user:

<form action="/processform">
    <span>
        <label for="age">Age</label>
        <input type="text" name="age" id="age" value="foo" />
    </span>
    <span>
        <label for="size">Shoe Size</label>
        <input type="text" name="size" id="size" value="bar" />
    </span>
</form>

Full Page Reload

We can use a page notice to display a prominent error message at the top of the page:

<section aria-label="Priority" class="page-notice page-notice--priority" id="page-notice" role="region">
    <h2>Error!</h2>
</section>

Using the region role and aria-label ensures that the page notice is listed as a custom "Priority" landmark in assistive technology.

This is one of the few occasions where it is appropriate to create a custom landmark on eBay.

It's not enough to just say "Error!" of course! The page notice must also contain descriptive error links to all invalid inputs.

<section aria-label="Priority" class="page-notice page-notice--priority" role="region">
    <h2>Error! Please correct the following fields:</h2>
    <ol>
        <li><a href="#age">Age - please enter a valid age (for example, 35)</a></li>
        <li><a href="#size">Shoe-size - please enter a valid shoe size (for example, 8.5)</a></li>
    </ol>
</section>

Note that Safari has an issue with setting focus on the input after clicking an internal link (it seems to set focus, but typing is not possible), and so some additional JavaScript is needed to set focus properly.

Invalid Inputs

Use aria-invalid="true" to mark inputs as invalid to assistive technology.

<span>
    <label for="age">Age</label>
    <input aria-describedby="age-description" aria-invalid="true" id="age" name="age" type="text" />
</span>

Inline Notices

In addition to the main notice, each invalid input must display an inline error notice:

<span>
    <label for="age">Age</label>
    <input aria-describedby="age-description" aria-invalid="true" id="age" name="age" type="text" />
    <span id="age-description">Please enter a correct age</span>
</span>

Presentation (CSS)

There is not much to say in terms of CSS, other than the page notice and all errors must be fully visible while the form remains in an invalid state.

Also, we can (and should) leverage ARIA states in our CSS, like so:

input[type=text][aria-invalid=true] {
    border: 1px solid red;
}

Here we have used the aria-invalid state to style our invalid fields with a red border. No need to create a class!

Behaviour (JS)

JavaScript enhances our baseline experience by doing everything mentioned above, but all without a full page reload.

We create the exact same notice as in our baseline experience, only now we render it immediately on the client, and directly above the form.

<section aria-label="Priority" class="region-notice region-notice--priority" role="region">
    <h2>Error! Please correct the following fields:</h2>
    <ol>
        <li><a href="#age">Age - please enter a valid age (for example, 35)</a></li>
        <li><a href="#size">Shoe-size - please enter a valid shoe size (for example, 8.5)</a></li>
    </ol>
</section>

With JavaScript available, we can also set focus directly on the page notice. This use of focus management is a crucial enhancement for screen reader users.


ARIA Reference

This section gives an overview of our use of ARIA in this pattern.

aria-required

Applied to the input element to denote a required field.

We can also use this attribute as a CSS hook.

aria-invalid

Applied to the input element to denote an invalid field.

We can also use this attribute as a CSS hook.

aria-describedby

Applied to the input element to denote the element containing the error description.


The Future

HTML5 also promises us built-in validation on the client for new input types (number, date, url, etc). However, at the time of writing, support across devices (and for accessibility) is not good enough for us to consider their use and they should be avoided until further notice.

results matching ""

    No results matching ""