Slides from CodeHeart Design 2018: Building a design system is a painful enough, but how do you add accessibility into the mix? Is it an "up-at-dawn, pride-swallowing siege", or can it become part of the normal work flow. We'll look at accessibility for different roles - such as UX, UI and devs, as well as where accessibility should be injected into the process.

1. #CHD18
RUSS WEAKLEY | DESIGN SYSTEM PRINCIPAL / IAG | @RUSSMAXDESIGN

2. Accessibility
in Design Systems
THE PAIN & THE GLORY

3. Five tips for creating more
accessible design systems.

4. Tip 1:
Accessibility should
be “baked in” at all
levels

5. What does “baked in” mean?

6. “Incorporate something as an
integral part of a product,
service, or system”

7. But what does this mean for
design systems?

8. Let’s look at high and low
levels.

9. Principles, guides and
practices

10. Inclusive design should be
included as part of the design
system principles.

11. Guidelines should be in place
to help designers and
developers achieve
accessibility.

12. And what about practices…

13. Personas should include
people with different types of
disabilities.

14. And user testing should
include people with different
disabilities.

15. After all, 1 in 5 Australians
have some form of disability.

16. Components

17. Every time a component is
added to the system, it should
have accessibility “baked in”.

18. Design components should
consider colour contrast and
text size accessibility.

19. Code components should be
built using semantic and
accessible markup.

20. Let's look at how to bake
accessibility into some code
components.

21. Example 1:
Labels and form controls

22. Full name
Label

23. Full name
Form control

24. 1. Use the <label> element.

25. <label for="one">Full name</label>
<input id="one" type="text">

26. 2. Use the for and id
attributes to explicitly
associate the two elements.

27. <label for="one">Full name</label>
<input id="one" type="text">

28. Even if the <label> wraps
around the form control!

29. <label for="one">
Full name
<input id="one" type="text">
</label>

30. This is important for assistive
technologies so that the label
is announced when the form
control comes into focus.

31. Example 2:
Inline error messages

32. Label
Phone number
Must be an 8 digit number

33. Phone number
Must be an 8 digit number
Form control

34. Phone number
Must be an 8 digit number
Dynamic error message

35. These error messages are
dynamically injected when a
user enters invalid data.

36. They need to be
programmatically associated
with their form controls.

37. So that they are announced to
assistive technologies when
the form control comes into
focus.

38. Method 1:
Add the error message inside
the wrapped <label>
element.

39. <label for="one">
Phone number
<input id="one" type="text">
<span>Must be an 8 digit number</span>
</label>

40. Method 2:
Use the aria-describedby
attribute.

41. <label for="one">Phone number</label>
<input id="one" type="text"
aria-describedby="d1">
<span id="d1">Must be an 8 digit number</span>

42. Developers should also use
aria-invalid and aria-live.

43. These two attributes help
provide additional inform to
assistive technologies.

44. Here’s how it looks when
there is no error present.

45. <label for="one">Phone number</label>
<input id="one" type="text"
aria-describedby="d1" aria-invalid="false">
<span id="d1" aria-live="polite"></span>

46. And when an error has been
triggered.

47. <label for="one">Phone number</label>
<input id="one" type="text"
aria-describedby="d1" aria-invalid="true">
<span id="d1" aria-live="polite">Must be an 8
digit number</span>

48. Avoid aria-live=assertive
and role=alert as these are
too shouty!

49. Example 3:
Radio button groups

50. Weekly
Monthly
Quarterly
Choose subscription type
Overall description

51. Weekly
Monthly
Quarterly
Choose subscription type
Form controls

52. Weekly
Monthly
Quarterly
Choose subscription typeLabels

53. 1. Make sure there is an
overall description.

54. This is important for assistive
technology users, so that they
can understand the context
of each radio button choice.

55. 2. Wrap the radio group and
overall description inside a
<fieldset>.

56. <fieldset>
<legend>Choose a subscription type</legend>
<input id="week" type="radio" name="sub">
<label for="week">Weekly</label>
<input id="month" type="radio" name="sub">
<label for="month">Monthly</label>
<input id="quart" type="radio" name="sub">
<label for="quart">Quarterly</label>
</fieldset>

57. 3. Use the <legend> for the
overall description.

58. And make sure it is the first
thing inside the <fieldset>.

59. <fieldset>
<legend>Choose a subscription type</legend>
<input id="week" type="radio" name="sub">
<label for="week">Weekly</label>
<input id="month" type="radio" name="sub">
<label for="month">Monthly</label>
<input id="quart" type="radio" name="sub">
<label for="quart">Quarterly</label>
</fieldset>

60. The overall description is now
programmatically associated
with the radio buttons.

61. This means screen readers will
hear the following:

62. “Choose a subscription type.
Weekly”

63. Segmented controls

64. By the way, segmented
controls are just glorified
radio groups.

65. Are you ready?
Overall description
Yes No Maybe

66. Are you ready?
Yes No Maybe
Hidden form control

67. Are you ready?
Yes No Maybe
Label

68. So the same rules apply.

69. 1. Make sure there is an
overall description.

70. 2. Wrap all of it inside a
<fieldset>.

71. 3. Place the overall description
inside a <legend>.

72. These simple solutions go a
long way to help “bake
accessibility into” form
components.

73. Tip 2:
Accessible components
do not automatically
mean accessible apps

74. This is a common mistake.

75. In reality, when a component
is dropped into a layout, the
context may change.

76. And regardless of the
components, other aspects of
the app many not be
accessible.

77. So, it's important to do
accessibility reviews during
different phases:

78. 1. For individual components

79. 2. For layouts or templates

80. 3. For fully-functional apps

81. Tip 3:
Components should be
built so that they can’t
be broken

82. Component libraries should
never allow developers to copy
and paste code that can then
be edited.

83. These snippets are not
updatable or manageable.

84. Even worse, they can be
hacked and changed.

85. 1. Code components should be
“referenceable”, not
“copyable”.

86. 2. Code components should
only allow specific aspects of
the component to be
adjusted.

87. Let's take the Bootstrap modal
as an example.

88. <div role="dialog" aria-labelledby="myModal">
<h4 id="myModal">Modal title</h4>
</div>

89. Some developers copy this
code, and then accidentally
break the relationship.

90. <div role="dialog" aria-labelledby="myModal">
<h4>Modal title</h4>
</div>

91. When this happens, the
heading is not announced
when the modal is triggered.

92. Tip 4:
The purpose and usage
of each component
should be clearly
defined

93. Let’s look at buttons vs links.

94. It is common to have links
that look like buttons.

95. A button or a link?

96. There is nothing specifically
wrong with this approach.

97. However, buttons and links
have distinctly different
purposes.

98. Buttons should be used to
trigger some sort of action -
like submitting a form or
opening/closing a widget.

99. Links should be used when
sending users to a location.

100. If misused, they could cause
confusion for assistive
technology users.

101. A screen reader user who
hears a “link” announced will
assume they are about to be
taken to a new location.

102. And, if they hear a “button”
announced, they will assume
they are about to submit or
change something.

103. So, the system should clearly
define when buttons and
links should be used.

104. Tip 5:
Accessibility is the
responsibility of
everyone

105. Accessibility testing tools are
an important part of making
design systems accessible.

106. Colour contrast plugins can
help designers check colour
contrast as they design.

107. HTML and CSS validators can
help developers make sure
that markup is valid.

108. And tools like AXE, WAVE and
Tenon can be used to test the
accessibility of components,
layouts and apps.

109. However, accessibility testing
tools are pointless without
some basic knowledge.

110. Team members must also
understand accessibility - at
least within their discipline.

111. Here are some things that UX,
UI and front-end developers
should know about
accessibility.

112. UX Designers

113. UX designers should have a
basic understanding of HTML
markup.

114. They should have a solid
understanding of accessibility
within forms.

115. This includes an
understanding of when to use
<fieldset>, <legend> and
<label> elements.

116. And accessibility around
required fields, error
messages and form
instructions.

117. They should understand
heading hierarchy and usage.

118. They should be understand the
importance of focus order.

119. UI Designers

120. For UI designers, most of the
same concerns also apply.

121. UI designers should also
understand accessibility in
relation to colour contrast
and colour use.

122. They should understand
accessibility issues associated
with text resizing and text
spacing.

123. And they should be aware of
target size, and how this
affects different types of
users.

124. Front-end Developers

125. Front-end developers need an
understanding of semantic
HTML markup.

126. They should have a detailed
understanding of accessible
form and table markup.

127. They need to understand how
to make components
keyboard-only accessible.

128. And they should understand
that any “non-native” widgets
will need additional work to
make them accessible.

129. What does “non-native”
mean?

130. “Non-native” means that the
markup that does not have
any underlying meaning.

131. The widgets use <div> and
<span> elements, which have
no native semantics.

132. “Non-native” widgets includes
things like modals, button
dropdowns and accordions.

133. When using non-native
widgets, developers need to:

134. 1. define an accessible name.
(Is it a modal, a tooltip, a popover?)

135. 2. Define the current state if it
can change.
(Is it expanded, checked etc).

136. 3. Define any relationships.
(Does it control another element, is it
owned by another element?)

137. Conclusion

138. Baking accessibility into
design systems is not easy.

139. However, it can be done - even
if it’s one small step at a time.

140. It’s a journey, not a
destination.

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