Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
#CHD18
RUSS WEAKLEY | DESIGN SYSTEM PRINCIPAL / IAG | @RUSSMAXDESIGN
Accessibility
in Design Systems
THE PAIN & THE GLORY
Five tips for creating more
accessible design systems.
Tip 1:
Accessibility should

be “baked in” at all
levels
What does “baked in” mean?
“Incorporate something as an
integral part of a product,
service, or system”
But what does this mean for
design systems?
Let’s look at high and low
levels.
Principles, guides and
practices
Inclusive design should be
included as part of the design
system principles.
Guidelines should be in place
to help designers and
developers achieve
accessibility.
And what about practices…
Personas should include
people with different types of
disabilities.
And user testing should
include people with different
disabilities.
After all, 1 in 5 Australians
have some form of disability.
Components
Every time a component is
added to the system, it should
have accessibility “baked in”.
Design components should
consider colour contrast and
text size accessibility.
Code components should be
built using semantic and
accessible markup.
Let's look at how to bake
accessibility into some code
components.
Example 1:
Labels and form controls
Full name
Label
Full name
Form control
1. Use the <label> element.
<label for="one">Full name</label>
<input id="one" type="text">
2. Use the for and id
attributes to explicitly
associate the two elements.
<label for="one">Full name</label>
<input id="one" type="text">
Even if the <label> wraps
around the form control!
<label for="one">
Full name
<input id="one" type="text">
</label>
This is important for assistive
technologies so that the label
is announced when the form
control comes into focus.
Example 2:
Inline error messages
Label
Phone number
Must be an 8 digit number
Phone number
Must be an 8 digit number
Form control
Phone number
Must be an 8 digit number
Dynamic error message
These error messages are
dynamically injected when a
user enters invalid data.
They need to be
programmatically associated
with their form controls.
So that they are announced to
assistive technologies when
the form control comes into
focus.
Method 1: 

Add the error message inside
the wrapped <label>
element.
<label for="one">
Phone number
<input id="one" type="text">
<span>Must be an 8 digit number</span>
</label>
Method 2:

Use the aria-describedby
attribute.
<label for="one">Phone number</label>
<input id="one" type="text" 

aria-describedby="d1">
<span id="d1">Must be an 8 digi...
Developers should also use
aria-invalid and aria-live.
These two attributes help
provide additional inform to
assistive technologies.
Here’s how it looks when
there is no error present.
<label for="one">Phone number</label>
<input id="one" type="text" 

aria-describedby="d1" aria-invalid="false">
<span id="...
And when an error has been
triggered.
<label for="one">Phone number</label>
<input id="one" type="text" 

aria-describedby="d1" aria-invalid="true">
<span id="d...
Avoid aria-live=assertive
and role=alert as these are
too shouty!
Example 3:
Radio button groups
Weekly
Monthly
Quarterly
Choose subscription type
Overall description
Weekly
Monthly
Quarterly
Choose subscription type
Form controls
Weekly
Monthly
Quarterly
Choose subscription typeLabels
1. Make sure there is an
overall description.
This is important for assistive
technology users, so that they
can understand the context
of each radio button choice.
2. Wrap the radio group and
overall description inside a
<fieldset>.
<fieldset>
<legend>Choose a subscription type</legend>
<input id="week" type="radio" name="sub">
<label for="week">Weekly<...
3. Use the <legend> for the
overall description.
And make sure it is the first
thing inside the <fieldset>.
<fieldset>
<legend>Choose a subscription type</legend>
<input id="week" type="radio" name="sub">
<label for="week">Weekly<...
The overall description is now
programmatically associated
with the radio buttons.
This means screen readers will
hear the following:
“Choose a subscription type.
Weekly”
Segmented controls
By the way, segmented
controls are just glorified
radio groups.
Are you ready?
Overall description
Yes No Maybe
Are you ready?
Yes No Maybe
Hidden form control
Are you ready?
Yes No Maybe
Label
So the same rules apply.
1. Make sure there is an
overall description.
2. Wrap all of it inside a
<fieldset>.
3. Place the overall description
inside a <legend>.
These simple solutions go a
long way to help “bake
accessibility into” form
components.
Tip 2:
Accessible components
do not automatically
mean accessible apps
This is a common mistake.
In reality, when a component
is dropped into a layout, the
context may change.
And regardless of the
components, other aspects of
the app many not be
accessible.
So, it's important to do
accessibility reviews during
different phases:
1. For individual components
2. For layouts or templates
3. For fully-functional apps
Tip 3:

Components should be
built so that they can’t
be broken
Component libraries should
never allow developers to copy
and paste code that can then
be edited.
These snippets are not
updatable or manageable.
Even worse, they can be
hacked and changed.
1. Code components should be
“referenceable”, not
“copyable”.
2. Code components should
only allow specific aspects of
the component to be
adjusted.
Let's take the Bootstrap modal
as an example.
<div role="dialog" aria-labelledby="myModal">
<h4 id="myModal">Modal title</h4>
</div>
Some developers copy this
code, and then accidentally
break the relationship.
<div role="dialog" aria-labelledby="myModal">
<h4>Modal title</h4>
</div>
When this happens, the
heading is not announced
when the modal is triggered.
Tip 4:
The purpose and usage
of each component
should be clearly
defined
Let’s look at buttons vs links.
It is common to have links
that look like buttons.
A button or a link?
There is nothing specifically
wrong with this approach.
However, buttons and links
have distinctly different
purposes.
Buttons should be used to
trigger some sort of action -
like submitting a form or
opening/closing a widget.
Links should be used when
sending users to a location.
If misused, they could cause
confusion for assistive
technology users.
A screen reader user who
hears a “link” announced will
assume they are about to be
taken to a new location.
And, if they hear a “button”
announced, they will assume
they are about to submit or
change something.
So, the system should clearly
define when buttons and
links should be used.
Tip 5:
Accessibility is the
responsibility of
everyone
Accessibility testing tools are
an important part of making
design systems accessible.
Colour contrast plugins can
help designers check colour
contrast as they design.
HTML and CSS validators can
help developers make sure
that markup is valid.
And tools like AXE, WAVE and
Tenon can be used to test the
accessibility of components,
layouts and apps.
However, accessibility testing
tools are pointless without
some basic knowledge.
Team members must also
understand accessibility - at
least within their discipline.
Here are some things that UX,
UI and front-end developers
should know about
accessibility.
UX Designers
UX designers should have a
basic understanding of HTML
markup.
They should have a solid
understanding of accessibility
within forms.
This includes an
understanding of when to use
<fieldset>, <legend> and
<label> elements.
And accessibility around
required fields, error
messages and form
instructions.
They should understand
heading hierarchy and usage.
They should be understand the
importance of focus order.
UI Designers
For UI designers, most of the
same concerns also apply.
UI designers should also
understand accessibility in
relation to colour contrast
and colour use.
They should understand
accessibility issues associated
with text resizing and text
spacing.
And they should be aware of
target size, and how this
affects different types of
users.
Front-end Developers
Front-end developers need an
understanding of semantic
HTML markup.
They should have a detailed
understanding of accessible
form and table markup.
They need to understand how
to make components
keyboard-only accessible.
And they should understand
that any “non-native” widgets
will need additional work to
make them accessible.
What does “non-native”
mean?
“Non-native” means that the
markup that does not have
any underlying meaning.
The widgets use <div> and
<span> elements, which have
no native semantics.
“Non-native” widgets includes
things like modals, button
dropdowns and accordions.
When using non-native
widgets, developers need to:
1. define an accessible name.
(Is it a modal, a tooltip, a popover?)
2. Define the current state if it
can change.
(Is it expanded, checked etc).
3. Define any relationships.
(Does it control another element, is it
owned by another element?)
Conclusion
Baking accessibility into
design systems is not easy.
However, it can be done - even
if it’s one small step at a time.
It’s a journey, not a
destination.
Russ Weakley
Max Design
Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
Lin...
Prochain SlideShare
Chargement dans…5
×

Accessibility in Design systems - the pain and glory

1 031 vues

Publié le

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.

Publié dans : Formation
  • Soyez le premier à commenter

Accessibility in Design systems - the pain and glory

  1. 1. #CHD18 RUSS WEAKLEY | DESIGN SYSTEM PRINCIPAL / IAG | @RUSSMAXDESIGN
  2. 2. Accessibility in Design Systems THE PAIN & THE GLORY
  3. 3. Five tips for creating more accessible design systems.
  4. 4. Tip 1: Accessibility should
 be “baked in” at all levels
  5. 5. What does “baked in” mean?
  6. 6. “Incorporate something as an integral part of a product, service, or system”
  7. 7. But what does this mean for design systems?
  8. 8. Let’s look at high and low levels.
  9. 9. Principles, guides and practices
  10. 10. Inclusive design should be included as part of the design system principles.
  11. 11. Guidelines should be in place to help designers and developers achieve accessibility.
  12. 12. And what about practices…
  13. 13. Personas should include people with different types of disabilities.
  14. 14. And user testing should include people with different disabilities.
  15. 15. After all, 1 in 5 Australians have some form of disability.
  16. 16. Components
  17. 17. Every time a component is added to the system, it should have accessibility “baked in”.
  18. 18. Design components should consider colour contrast and text size accessibility.
  19. 19. Code components should be built using semantic and accessible markup.
  20. 20. Let's look at how to bake accessibility into some code components.
  21. 21. Example 1: Labels and form controls
  22. 22. Full name Label
  23. 23. Full name Form control
  24. 24. 1. Use the <label> element.
  25. 25. <label for="one">Full name</label> <input id="one" type="text">
  26. 26. 2. Use the for and id attributes to explicitly associate the two elements.
  27. 27. <label for="one">Full name</label> <input id="one" type="text">
  28. 28. Even if the <label> wraps around the form control!
  29. 29. <label for="one"> Full name <input id="one" type="text"> </label>
  30. 30. This is important for assistive technologies so that the label is announced when the form control comes into focus.
  31. 31. Example 2: Inline error messages
  32. 32. Label Phone number Must be an 8 digit number
  33. 33. Phone number Must be an 8 digit number Form control
  34. 34. Phone number Must be an 8 digit number Dynamic error message
  35. 35. These error messages are dynamically injected when a user enters invalid data.
  36. 36. They need to be programmatically associated with their form controls.
  37. 37. So that they are announced to assistive technologies when the form control comes into focus.
  38. 38. Method 1: 
 Add the error message inside the wrapped <label> element.
  39. 39. <label for="one"> Phone number <input id="one" type="text"> <span>Must be an 8 digit number</span> </label>
  40. 40. Method 2:
 Use the aria-describedby attribute.
  41. 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. 42. Developers should also use aria-invalid and aria-live.
  43. 43. These two attributes help provide additional inform to assistive technologies.
  44. 44. Here’s how it looks when there is no error present.
  45. 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. 46. And when an error has been triggered.
  47. 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. 48. Avoid aria-live=assertive and role=alert as these are too shouty!
  49. 49. Example 3: Radio button groups
  50. 50. Weekly Monthly Quarterly Choose subscription type Overall description
  51. 51. Weekly Monthly Quarterly Choose subscription type Form controls
  52. 52. Weekly Monthly Quarterly Choose subscription typeLabels
  53. 53. 1. Make sure there is an overall description.
  54. 54. This is important for assistive technology users, so that they can understand the context of each radio button choice.
  55. 55. 2. Wrap the radio group and overall description inside a <fieldset>.
  56. 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. 57. 3. Use the <legend> for the overall description.
  58. 58. And make sure it is the first thing inside the <fieldset>.
  59. 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. 60. The overall description is now programmatically associated with the radio buttons.
  61. 61. This means screen readers will hear the following:
  62. 62. “Choose a subscription type. Weekly”
  63. 63. Segmented controls
  64. 64. By the way, segmented controls are just glorified radio groups.
  65. 65. Are you ready? Overall description Yes No Maybe
  66. 66. Are you ready? Yes No Maybe Hidden form control
  67. 67. Are you ready? Yes No Maybe Label
  68. 68. So the same rules apply.
  69. 69. 1. Make sure there is an overall description.
  70. 70. 2. Wrap all of it inside a <fieldset>.
  71. 71. 3. Place the overall description inside a <legend>.
  72. 72. These simple solutions go a long way to help “bake accessibility into” form components.
  73. 73. Tip 2: Accessible components do not automatically mean accessible apps
  74. 74. This is a common mistake.
  75. 75. In reality, when a component is dropped into a layout, the context may change.
  76. 76. And regardless of the components, other aspects of the app many not be accessible.
  77. 77. So, it's important to do accessibility reviews during different phases:
  78. 78. 1. For individual components
  79. 79. 2. For layouts or templates
  80. 80. 3. For fully-functional apps
  81. 81. Tip 3:
 Components should be built so that they can’t be broken
  82. 82. Component libraries should never allow developers to copy and paste code that can then be edited.
  83. 83. These snippets are not updatable or manageable.
  84. 84. Even worse, they can be hacked and changed.
  85. 85. 1. Code components should be “referenceable”, not “copyable”.
  86. 86. 2. Code components should only allow specific aspects of the component to be adjusted.
  87. 87. Let's take the Bootstrap modal as an example.
  88. 88. <div role="dialog" aria-labelledby="myModal"> <h4 id="myModal">Modal title</h4> </div>
  89. 89. Some developers copy this code, and then accidentally break the relationship.
  90. 90. <div role="dialog" aria-labelledby="myModal"> <h4>Modal title</h4> </div>
  91. 91. When this happens, the heading is not announced when the modal is triggered.
  92. 92. Tip 4: The purpose and usage of each component should be clearly defined
  93. 93. Let’s look at buttons vs links.
  94. 94. It is common to have links that look like buttons.
  95. 95. A button or a link?
  96. 96. There is nothing specifically wrong with this approach.
  97. 97. However, buttons and links have distinctly different purposes.
  98. 98. Buttons should be used to trigger some sort of action - like submitting a form or opening/closing a widget.
  99. 99. Links should be used when sending users to a location.
  100. 100. If misused, they could cause confusion for assistive technology users.
  101. 101. A screen reader user who hears a “link” announced will assume they are about to be taken to a new location.
  102. 102. And, if they hear a “button” announced, they will assume they are about to submit or change something.
  103. 103. So, the system should clearly define when buttons and links should be used.
  104. 104. Tip 5: Accessibility is the responsibility of everyone
  105. 105. Accessibility testing tools are an important part of making design systems accessible.
  106. 106. Colour contrast plugins can help designers check colour contrast as they design.
  107. 107. HTML and CSS validators can help developers make sure that markup is valid.
  108. 108. And tools like AXE, WAVE and Tenon can be used to test the accessibility of components, layouts and apps.
  109. 109. However, accessibility testing tools are pointless without some basic knowledge.
  110. 110. Team members must also understand accessibility - at least within their discipline.
  111. 111. Here are some things that UX, UI and front-end developers should know about accessibility.
  112. 112. UX Designers
  113. 113. UX designers should have a basic understanding of HTML markup.
  114. 114. They should have a solid understanding of accessibility within forms.
  115. 115. This includes an understanding of when to use <fieldset>, <legend> and <label> elements.
  116. 116. And accessibility around required fields, error messages and form instructions.
  117. 117. They should understand heading hierarchy and usage.
  118. 118. They should be understand the importance of focus order.
  119. 119. UI Designers
  120. 120. For UI designers, most of the same concerns also apply.
  121. 121. UI designers should also understand accessibility in relation to colour contrast and colour use.
  122. 122. They should understand accessibility issues associated with text resizing and text spacing.
  123. 123. And they should be aware of target size, and how this affects different types of users.
  124. 124. Front-end Developers
  125. 125. Front-end developers need an understanding of semantic HTML markup.
  126. 126. They should have a detailed understanding of accessible form and table markup.
  127. 127. They need to understand how to make components keyboard-only accessible.
  128. 128. And they should understand that any “non-native” widgets will need additional work to make them accessible.
  129. 129. What does “non-native” mean?
  130. 130. “Non-native” means that the markup that does not have any underlying meaning.
  131. 131. The widgets use <div> and <span> elements, which have no native semantics.
  132. 132. “Non-native” widgets includes things like modals, button dropdowns and accordions.
  133. 133. When using non-native widgets, developers need to:
  134. 134. 1. define an accessible name. (Is it a modal, a tooltip, a popover?)
  135. 135. 2. Define the current state if it can change. (Is it expanded, checked etc).
  136. 136. 3. Define any relationships. (Does it control another element, is it owned by another element?)
  137. 137. Conclusion
  138. 138. Baking accessibility into design systems is not easy.
  139. 139. However, it can be done - even if it’s one small step at a time.
  140. 140. It’s a journey, not a destination.
  141. 141. Russ Weakley Max Design Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley

×