Accessible Form Hints and Errors

Accessibility
in pattern
libraries
Accessible form
Hints & Errors

All examples from this
presentation are available here:
http://bit.ly/hinterror

Let’s start with some basic
definitions.

What are inline error
messages?

Inline error messages are
messages that are presented in
close proximity to the relevant
form field.

They are used to inform users
that a form field has been filled
in incorrectly.

Age
Error: Must be a valid age value

These messages should inform
users of the following things:

1. That there is an error
associated with the relevant
field.

2. Information on how to
resolve the error so that the
form field can be filled in
correctly.

3. Ideally, the error message
should be relevant and
contextual rather than being
too generic.
Some of the examples in my slides are very generic 
due to space restrictions.

These messages should only
appear when a user has
incorrectly filled in a form
field.

They are often dynamically
injected onto the page directly
after the user leaves that form
field.

Or, in some cases, when the
user attempts to submit the
form.

What are inline hints or
instructions?

Inline hints or instructions are
additional pieces of
information associated with
individual form fields.

Ideally, these hints should be
placed in close proximity to
the relevant form control -
either above or below.

Password
Must be at least 8 characters

These hints are designed to help
users fill in the form field
correctly.

Why “programmatically
associated” matters

In order to make inline error
messages and hints accessible,
it is important to understand
the two screen reader modes.

“Read mode” allows users to
read and navigate the page. In
this mode, users cannot enter
data into a form.

“Forms mode” allows the user
to interact with form controls
(fill in form fields etc).

In “forms mode”, keyboard
access is restricted to page
elements that can accept focus.

When screen readers are in
“forms mode”, elements that
cannot receive focus are not
announced to the user.

For example, a paragraph with
an error message after a form
control:

<label for="email">Email<label>
<input id="email" type="text">
<p>Error message</p>

This paragraph will not be
announced by screen readers
while in “forms mode”, as it is
not programmatically
associated with the form
control.

For this reason, we need to
make sure that inline error
messages and hints
programatically associated
with form controls.

Methods for inline error
messages

Here are three different
methods that could be used to
programmatically associate
error messages with their form
controls.

Using this method, the <label>
element is wrapped around the
label content, the form control
and the inline error message.

<label for="error1">
<span>Age</span>
<input id="error1" type="text">
<span>Error: Must be...</span>
</label>

<span>Age</span>
</label>

<span>Age</span>
</label>

<span>Age</span>
</label>

<span>Age</span>
</label>

This method is very well
supported across all browser
and assistive technology
combinations.

OSX Voiceover Windows NVDA Windows JAWS
SafariChrome Opera FirefoxChrome Edge FirefoxChrome Edge
PASSPASS PASS PASSPASS PASS PASSPASS PASS

In some cases, it is not possible
to wrap the <label> element
around the form control or
error message.

The aria-describedby attribute
can be used to explicitly
associate the error message
with the form control.

<label for="error2">Phone number</label>
<input id="error2" type="text" 
aria-describedby="d1">
<span id="d1">Error: Must be...</span>

This method is well supported
across most browser and
assistive technology
combinations.

PASSPASS PASS PASSPASS PASS PASSPASS FAIL

The following technique uses
the aria-errormessage
attribute, which was
introduced as part of ARIA 1.1
in December 2017.

Using this method, the error
messages can be
programmatically associated
with the input using a matching
id and aria-errormessage
values.

<label for="error3">Mobile number</label>
<input id="error3" aria-errormessage="m1" 
type="text" aria-invalid="true">
<span id="m1" aria-live="assertive">Error</span>

According to the W3C
specification, authors must use
the aria-invalid attribute in
conjunction with the  
aria-errormessage attribute.

Initially, the object is in a valid
state, and the aria-invalid
attribute should be set to false.

<input id="error3" aria-errormessage="m1"
type="text" aria-invalid="false">
<span id="m1" aria-live="assertive"></span>

If the user enters an invalid
value, the aria-invalid
attribute must be dynamically
changed to true.

The specification also states
that authors can use live
regions for the error message
element - such as aria-live or
alert.

The error message could also be
set with role=alert.

<span id="m1" role="alert">Error</span>

Even though this method is a
WAI ARIA recommended
method, I have some concerns
with the use of assertive or
alert.

With an aria-live value of
assertive, or a role of alert
the error message should be
announced immediately.

If the error message is is
dynamically inserted as the
user leaves a form control, the
error message could be
announced over the top of the
next form control label.

For this reason, I’d prefer to set
the aria-live value to off.

This means that assistive
technologies will be aware of
the change within that region,
but the change will not be
immediately announced to
users.

The aria-errormessage
attribute currently has no
support across any browser
and assistive technology
combinations.

FAILFAIL FAIL FAILFAIL FAIL FAILFAIL FAIL

However, this is a W3C
recommended technique, and
could become a viable option
in the future.

Here are three different
methods that could be used to
explicitly associate hints and
form controls.

In this example, the hint has
been provided using the
placeholder attribute.

<label for="hint1">Email</label>
<input id="hint1" type="text" placeholder="Add
your email address">

This method is not
recommended for the following
reasons:

1. The hint disappears as soon
as users interact with the form
control.

This is especially problematic if
there is a complex hint
message that is important for
users to be aware of as they fill
in the form field.

2. By default, the placeholder
text is displayed in a very soft
colour that fails WCAG Colour
Contrast guidelines.

PASSPASS PASS PASSPASS FAIL FAILPASS FAIL

In this example, the hint has
been displayed below the form
control.

Like the error message example,
this method wraps the <label>
element around the label
content, the form control and
the inline hint.

<label for="hint2">
<span>Password</span>
<input id="hint2" type="text">
<span>Must be at least 8 characters</span>
</label>

<label for="hint2">
</label>

<label for="hint2">
</label>

<label for="hint2">
</label>

Like the earlier example, the
aria-describedby can be used
to explicitly associate the error
message with the form control.

<label for="hint3">Address</label>
<input id="hint3" type="text" 
<span id="d2">Use your full street address</span>

There are times when a longer
hint message is desired.

Some authors prefer to make
this information available as a
popup tooltip.

Active customers ?
The maximum number of
active customers in a

given month

There are two key questions
associated with popup tooltips
and form controls:

1. How do you make the popup
tooltip keyboard accessible?

2. Should this additional
information be
with the form control, or
separate?

1. Popup tooltip and
keyboard access

The quickest way to make the
tooltip keyboard accessible, is to
make it visible only while in
three states: focus, hover and
active.

The tooltip can be initially
hidden off-screen.

.tooltip {
position: absolute;
top: 0;
left: -5000px;
}

Then it can be made visible 
on-screen in these three
different states.

.tooltip:hover,
.tooltip:focus,
.tooltip:active {
top: -100px;
left: -10px;
}

A quick demo:
http://bit.ly/hinterror

2. Where to place the
tooltip?

Method 1: Tooltip associated
with the form control

If the hint information is
critical for users to
understand when filling in the
form field, then it needs to be
with the form control.

As we’ve seen before, the hint
information can be placed
inside the label, or associated
via the aria-describedby
attribute.

In this example, the tooltip
helps to explain what the term
“active customers” means.

<label for="hint4">
Active customers
<a href="#" role="button">
<span class="tooltip">
<span class="hidden">is defined as</span>
The maximum number...
</span>
</a>
</label>

<label for="hint4">
Active customers
</span>
</a>
</label>

<label for="hint4">
Active customers
</span>
</a>
</label>

<label for="hint4">
Active customers
</span>
</a>
</label>

<label for="hint4">
Active customers
</span>
</a>
</label>

<label for="hint4">
Active customers
</span>
</a>
</label>

Error 1 using a button:
“The label element may contain
at most one button, input,
meter, output, progress, select,
or textarea descendant.”

Error 2 using a button:
“Any button descendant of a
label element with a for
attribute must have an ID
value that matches that for
attribute.”

<label for="hint4">
Active customers
</span>
</a>
</label>

Method 2: Tooltip before the
form control

If the hint information is
informative, but not critical, it
could be presented to users as a
separate element, before the
relevant form control and
<label>.

This reduces the amount of
information that users are
presented with for the form
control.

In this example, the tooltip
helps to explain the number.

Choose a number ?
Must be a whole number
with no factions, no
decimals and no negatives.

<button>
<span class="hidden">For the following</span>
<span class="tooltip">Must be...</span>
</button>
<label for="hint6">
<span>Choose a number</span>
</label>

<button>
</button>
<label for="hint6">
</label>

<button>
</button>
<label for="hint6">
</label>

Make sure error messages and
hints are programmatically
associated with their form
controls.

The simplest and most stable
solution is to wrap the <label>
around the form control and
error or hint text.

If the <label> cannot wrap
around these items, the  
aria-decribedby solution is a
good alternative.

Always test any proposed
solutions with real users.

Russ Weakley
Max Design
Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
Linkedin: linkedin.com/in/russweakley

Accessible Form Hints and Errors

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Accessible Form Hints and Errors

Similar a Accessible Form Hints and Errors (20)

Más de Russ Weakley

Más de Russ Weakley (20)

Último

Último (20)

Accessible Form Hints and Errors