Accessible states in Design Systems

Accessible
StatesIN DESIGN SYSTEMS

The W3C defined states as:
“dynamic properties that convey
the characteristics of a user
interface component”.

I don’t know about you, but I
always find the W3C’s technical
definitions challenging to
understand.

How about we start with a
simple example… like the visited
state, which is applied to visited
links.

The state of a component can
change in response to user
actions.

For example, users can change
the state of some components to
checked, hover, focus or active
states.

And, state can change in
response to script-based
processes.

For example, a form control
could be set with an invalid state
via a script.

These different states don’t
affect the nature of the
component.

They represent additional data
associated with the component.

Looking at the
different states

We’re going to look at nine
different states.

Along the way I’ll talk about
some problems I’ve observed
while conducting user testing
sessions.

This state relates to links only.

The unvisited state is the
default state of links when they
have not yet been visited.

Unvisited link
Unvisited state on a link

Valerie:
85, retired, rarely uses
computers at all and is therefore
“technically challenged”.

Issue:
Could not identify a link as it
had “ambiguous” styling. Could
not complete a process.

Solution:
Make links look like links! (At
least within the content area of
pages or apps)

This states also relates to links
only.

The visited state is triggered
when a link has been visited
(and exists in the browser’s
history).

Visited link
Visited state on a link

Mark:
28, sustained a head injury from
a motor bike accident, has short
term memory issues.

Issue:
Trying to follow a multi-step
process from a single page
source. Kept losing place in
process due to lack of visited link
states.

Solution:
For links within content areas,
make sure you define visited
link states.

The focus state is triggered
when a component comes into
focus.

This state can be triggered via
user keyboard actions or some
sort of automated script.

This state should be applied to
any interactive element (e.g.
links, buttons, triggers, tabs,
inputs, selects, textareas).

Focus link
Focus state on a link

Judy:
65, has Cerebral palsy, cannot
use hands, uses a head-wand
and “sticky keys”.

Issue:
Trying to navigate a content-rich
news website. Lost track of
where focus was on the page due
to lack of focus states on some
components.

Solution 1:
Make sure all focusable items
have a visible focus state - either
the default focus style or a
customised focus style.

Solution 2:
Make sure the styling method
for focus states is consistent
across the site/application.

We’ll look into consistency in
more detail when we get to
“systematising states”.

The hover state is triggered
when a component is being
hovered over by a user's mouse
pointer.

This state can be applied to any
“clickable” element (links,
buttons, triggers).

Hover link
Hover state on a link

Issue:
Navigating to links takes a lot of
effort. Sometimes she was not
sure that she was navigating to
an actual link.

Solution:
A hover state provides
confirmation that she is
interacting with a link.

Mark (again):
short term memory issues.

Issue:
Trying to fill in a form. Found it
hard to identify which elements
were interactive.

Solution:
I have found it beneficial for
some types of users to add hover
states to inputs, selects and
textareas.

The active (or pressed) state is
triggered when a component is
currently being activated by the
user.

Like the hover state, this state
can be applied to any
“clickable” element (links,
buttons, triggers).

Active link
Active state on a link

Issue:
As mentioned before, navigation
takes effort, and identifying
links can be a problem.

Solution:
As with the hover state, an active
state provides an additional
confirmation of success.

The disabled state means that
the user cannot interact with the
component.

Disabled input
Disabled state on an input

Valerie (again):
Technically challenged.

Issue:
Trying to fill in a form. Kept
trying to interact with a disabled
component that had a focus
state. This led to frustration and
confusion.

Solution 1:
Where possible, do not present
disabled form components at all.

Solution 2:
If disabled components must be
presented, make sure that they
are visually identifiable as
“disabled”.

Solution 3:
Make sure disabled components
cannot receive focus.

The invalid state means that the
form control contains content
that fails to validate.

Error message
Label text
!
Invalid state on an input

Pavel:
39, Deuteranopia (Red-green
colour blindness). Confuses mid-
red colours with mid-green
colours.

Issue:
Filling in a form. Colour-alone
used to define invalid form field.
Was not able to identify the field
with the issue.

Solution:
Avoid using colour-alone to
define invalid states.

The checked (or selected) state
means that the component has
been checked or toggled to an
“on” state, either via the user, or
by default.

Checked radio
Unchecked radio
Checked state on a radio button

It is possible to have two
different states associated
with a component at the same
time - checked and focussed.

Let’s use an example of a radio
group with two options.

Before users interact with the
group, both radio buttons are in
the static state.

Choice 1
Choice 2
Static state on radio button

A radio button can be in a focus
state only.

Choice 1
Choice 2
Focus state on radio button

A radio can also be in a checked
(or selected) state only.

Choice 1
Choice 2
Checked state on radio button

However, if a radio button is in
focus and the user presses the
SPACEBAR, this radio button will
now be checked and in focus.

Choice 1
Choice 2
Checked and focus state on radio button

This is also relevant for
checkboxes and segmented
controls.

Valerie (again):
technically challenged.

Issue:
Unable to distinguish between
focus and checked state on a
segmented control. Assumed the
form control had been selected
when it was only in focus.

Solution:
Make sure the different states
are clearly identifiable and have
unique styles.

There are a range of interactive
UI components that are built
using non-native HTML - e.g.
using DIV and SPAN elements
only.

For example: date-pickers, in-
page tabs, pagination,
accordions etc.

If these non-native widgets
include some sort of interaction,
they must have relevant states
defined.

For example, an open/shut
accordion should have focus,
hover, active and open states
defined.

Item 1
Item 2
Item 3
Item 4
Static state on accordion

Item 1
Item 2
Item 3
Item 4
Hover state on accordion

Item 1
Item 2
Item 3
Item 4
Focus state on accordion

Item 1
Item 2
Item 3
Item 4
Active state on accordion

Item 1
Item 2
Item 3
Content inside accordion
panel, visible when open.
Open state on accordion

Have you ever noticed a website
or application that has
inconsistent hover and focus
styles across different
components?

This can lead to a jarring
experience - especially for
keyboard-only users who
navigate via focus.

For design systems, it is
important to systematise all
component states.

This makes it easier to:
- establish consistency
- maintain existing
components
- add new components

But how do you go about
systematising states?

I use a “states” table to track all
component states:

Don’t worry, we are going to
break this down.

This table has a row for each
possible state. The rows are:

Static
Visited
Hover
Focus
Active
Disabled
Invalid
Selected
Selected &Focus

Then, components can be
grouped into categories in
columns:

Links
Buttons
Form controls
Selectable form controls
Calendar dates
Accordions
Tabs
Pagination
etc

This allows you to compare all
the components in their
different states.

States may need to be styled
slightly differently in each
category, but there should be an
overall consistency across all
components.

For links, there is a column for
light and dark backgrounds.

Link columns: light
and dark
backgrounds

Static, visited, hover, focus and
active states are defined.

Link states: static,
visited, hover,
focus, active

Disabled, invalid, selected and
selected/focus states are not
relevant.

Non-relevant
states: disabled,
invalid, selected,
selected/focus

For buttons, there is a column
for each of the button levels
(primary, secondary, link and
icon).

Button columns:
primary,
secondary, link,
icons

Static, hover, focus, active and
disabled states are defined.

Button states:
static, hover, focus, active, disabled
Button states:
static, hover,
focus, active,
disabled

Visited, invalid, selected and
relevant.

Non-relevant
states: visited,
invalid, selected,
selected/focus

For form controls, there is a
column for input/textarea and
select.

Form control
columns: input/
textarea, select

Static, hover, focus, disabled
and invalid states are defined.

As mentioned earlier, I’ve
included a hover state for form
controls. But this is a personal
choice.

Form control
states: static,
hover, focus,
disabled, invalid

Visited, active, selected and
relevant.

Non-relevant
states: visited,
active, selected,
selected/focus

For selectable form controls,
there is a column for radios,
checkboxes and segmented
controls.

Clickable form
control columns:
radio, checkbox,
segmented control

Static, hover, focus, disabled,
invalid, selected and selected &
focus states are defined.

Clickable form
control states:
static, hover,
focus, disabled,
invalid, selected,
selected/focus

The visited states are not
relevant. In some systems I have
included an active state for
segmented controls, but it is up
to the team.

Non-relevant states:
visited, active
Non-relevant
states: visited and
possibly active
?

For accordion, there is a column
for the closed and open version
of an accordion item.

Accordion columns:
closed, open
Accordion
columns: closed,
open

Static, hover, focus and active
states are defined.

Accordion states:
static, hover,
focus, active

Visited, disabled, invalid,
selected and selected/focus
states are not relevant.

Non-relevant
states: visited,
active, disabled,
invalid, selected,
selected/focus

For in-page tabs, there is a
column for the closed and open
version of tab items.

Tabs columns:
open, closed
Tabs columns:
open, closed

Static, hover, focus and active
states are defined for closed
tabs.

Tab states: static,
hover, focus, active

Non-relevant
states: visited,
disabled, invalid,
selected, selected/
focus

Open tabs do not require a hover
or active state as they are
already “open and active”.

Non-relevant states for open:
hover, active
Non-relevant
states for open:
hover, active

This chart shows one way that
different states can be styled.

The table is available online:
URL to come

Take away 1:
It’s important to be aware of all
of the different states.

Take away 2:
It’s important to design for all of
these different states, especially
for non-native widgets.

Why?
Because when these states are
poorly executed, it can have an
impact on real users.

Take away 3:
Systematising the states is
important for websites and
applications?

Why?
It allows you to maintain a
visual consistency across your
websites and/or applications.

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

Accessible states in Design Systems

More Related Content

Similar to Accessible states in Design Systems (20)

More from Russ Weakley (20)

Recently uploaded (20)

Accessible states in Design Systems