Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Accessibility in Design systems - the pain and glory

1,053 views

Published on

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.

Published in: Education
  • Be the first to comment

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

×