The document discusses user interface states and provides examples of how states can be systematically defined across different UI components. It defines what states are and provides examples like visited, focus, hover, active, disabled, invalid, checked/selected states. It emphasizes the importance of defining states for all interactive elements, including custom elements, to ensure usability. It also stresses the importance of maintaining consistent state styling across a design system through the use of a state table that defines how each state should appear for different common UI elements like links, buttons, forms, tabs etc. This helps establish visual consistency and maintainability.

1. Accessible
StatesIN DESIGN SYSTEMS

2. What are
“states”?

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

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

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

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

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

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

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

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

11. They represent additional data
associated with the component.

12. Looking at the
different states

13. We’re going to look at nine
different states.

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

15. 1
Unvisited

16. This state relates to links only.

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

18. Unvisited link
Unvisited state on a link

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

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

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

22. 2
Visited

23. This states also relates to links
only.

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

25. Visited link
Visited state on a link

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

27. 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.

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

29. 3
Focus

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

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

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

33. Focus link
Focus state on a link

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

35. 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.

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

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

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

39. 4
Hover

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

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

42. Hover link
Hover state on a link

43. Judy (again):
Cerebral palsy.

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

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

46. Mark (again):
short term memory issues.

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

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

49. 5
Active

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

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

52. Active link
Active state on a link

53. Judy (again):
Cerebral palsy.

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

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

56. 6
Disabled

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

58. Disabled input
Disabled state on an input

59. Valerie (again):
Technically challenged.

60. 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.

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

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

63. Solution 3:
Make sure disabled components
cannot receive focus.

64. 7
Invalid

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

66. Error message
Label text
!
Invalid state on an input

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

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

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

70. 8
Checked (or selected)

71. 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.

72. Checked radio
Unchecked radio
Checked state on a radio button

73. 9
Checked and focussed

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

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

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

77. Choice 1
Choice 2
Static state on radio button

78. A radio button can be in a focus
state only.

79. Choice 1
Choice 2
Focus state on radio button

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

81. Choice 1
Choice 2
Checked state on radio button

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

83. Choice 1
Choice 2
Checked and focus state on radio button

84. This is also relevant for
checkboxes and segmented
controls.

85. One Two
Segmented control

86. Valerie (again):
technically challenged.

87. 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.

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

89. States and non-native
widgets

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

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

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

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

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

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

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

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

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

99. Systematising
states

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

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

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

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

104. But how do you go about
systematising states?

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

106. Full state table

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

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

109. Static
Visited
Hover
Focus
Active
Disabled
Invalid
Selected
Selected &Focus

110. Then, components can be
grouped into categories in
columns:

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

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

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

114. Links

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

116. Link columns: light
and dark
backgrounds

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

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

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

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

121. Buttons

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

123. Button columns:
primary,
secondary, link,
icons

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

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

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

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

128. Form controls

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

130. Form control
columns: input/
textarea, select

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

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

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

134. Visited, active, selected and
selected/focus states are not
relevant.

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

136. Selectable form controls

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

138. Clickable form
control columns:
radio, checkbox,
segmented control

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

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

141. 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.

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

143. Accordion

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

145. Accordion columns:
closed, open
Accordion
columns: closed,
open

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

147. Accordion states:
static, hover,
focus, active

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

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

150. In-page tabs

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

152. Tabs columns:
open, closed
Tabs columns:
open, closed

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

154. Tab states: static,
hover, focus, active

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

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

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

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

159. Just an example

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

161. The table is available online:
URL to come

162. Take aways

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

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

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

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

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

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