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.

Accessible states in Design Systems


Published on

This ID24 2019 talk will look at a the importance of states (visited, focus, active, checked/selected, open and more) when building design systems. We will explore their relevance, how to maintain consistency and how to systemise when designing at scale.

Published in: Education
  • Login to see the comments

Accessible states in Design Systems

  1. 1. Accessible StatesIN DESIGN SYSTEMS
  2. 2. What are “states”?
  3. 3. The W3C defined states as: “dynamic properties that convey the characteristics of a user interface component”.
  4. 4. I don’t know about you, but I always find the W3C’s technical definitions challenging to understand.
  5. 5. How about we start with a simple example… like the visited state, which is applied to visited links.
  6. 6. The state of a component can change in response to user actions.
  7. 7. For example, users can change the state of some components to checked, hover, focus or active states.
  8. 8. And, state can change in response to script-based processes.
  9. 9. For example, a form control could be set with an invalid state via a script.
  10. 10. These different states don’t affect the nature of the component.
  11. 11. They represent additional data associated with the component.
  12. 12. Looking at the different states
  13. 13. We’re going to look at nine different states.
  14. 14. Along the way I’ll talk about some problems I’ve observed while conducting user testing sessions.
  15. 15. 1
  16. 16. This state relates to links only.
  17. 17. The unvisited state is the default state of links when they have not yet been visited.
  18. 18. Unvisited link Unvisited state on a link
  19. 19. Valerie: 85, retired, rarely uses computers at all and is therefore “technically challenged”.
  20. 20. Issue: Could not identify a link as it had “ambiguous” styling. Could not complete a process.
  21. 21. Solution: Make links look like links! (At least within the content area of pages or apps)
  22. 22. 2
  23. 23. This states also relates to links only.
  24. 24. The visited state is triggered when a link has been visited (and exists in the browser’s history).
  25. 25. Visited link Visited state on a link
  26. 26. Mark: 28, sustained a head injury from a motor bike accident, has short term memory issues.
  27. 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. 28. Solution: For links within content areas, make sure you define visited link states.
  29. 29. 3 Focus
  30. 30. The focus state is triggered when a component comes into focus.
  31. 31. This state can be triggered via user keyboard actions or some sort of automated script.
  32. 32. This state should be applied to any interactive element (e.g. links, buttons, triggers, tabs, inputs, selects, textareas).
  33. 33. Focus link Focus state on a link
  34. 34. Judy: 65, has Cerebral palsy, cannot use hands, uses a head-wand and “sticky keys”.
  35. 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. 36. Solution 1: Make sure all focusable items have a visible focus state - either the default focus style or a customised focus style.
  37. 37. Solution 2: Make sure the styling method for focus states is consistent across the site/application.
  38. 38. We’ll look into consistency in more detail when we get to “systematising states”.
  39. 39. 4 Hover
  40. 40. The hover state is triggered when a component is being hovered over by a user's mouse pointer.
  41. 41. This state can be applied to any “clickable” element (links, buttons, triggers).
  42. 42. Hover link Hover state on a link
  43. 43. Judy (again): Cerebral palsy.
  44. 44. Issue: Navigating to links takes a lot of effort. Sometimes she was not sure that she was navigating to an actual link.
  45. 45. Solution: A hover state provides confirmation that she is interacting with a link.
  46. 46. Mark (again): short term memory issues.
  47. 47. Issue: Trying to fill in a form. Found it hard to identify which elements were interactive.
  48. 48. Solution: I have found it beneficial for some types of users to add hover states to inputs, selects and textareas.
  49. 49. 5 Active
  50. 50. The active (or pressed) state is triggered when a component is currently being activated by the user.
  51. 51. Like the hover state, this state can be applied to any “clickable” element (links, buttons, triggers).
  52. 52. Active link Active state on a link
  53. 53. Judy (again): Cerebral palsy.
  54. 54. Issue: As mentioned before, navigation takes effort, and identifying links can be a problem.
  55. 55. Solution: As with the hover state, an active state provides an additional confirmation of success.
  56. 56. 6 Disabled
  57. 57. The disabled state means that the user cannot interact with the component.
  58. 58. Disabled input Disabled state on an input
  59. 59. Valerie (again): Technically challenged.
  60. 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. 61. Solution 1: Where possible, do not present disabled form components at all.
  62. 62. Solution 2: If disabled components must be presented, make sure that they are visually identifiable as “disabled”.
  63. 63. Solution 3: Make sure disabled components cannot receive focus.
  64. 64. 7 Invalid
  65. 65. The invalid state means that the form control contains content that fails to validate.
  66. 66. Error message Label text ! Invalid state on an input
  67. 67. Pavel: 39, Deuteranopia (Red-green colour blindness). Confuses mid- red colours with mid-green colours.
  68. 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. 69. Solution: Avoid using colour-alone to define invalid states.
  70. 70. 8 Checked (or selected)
  71. 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. 72. Checked radio Unchecked radio Checked state on a radio button
  73. 73. 9 Checked and focussed
  74. 74. It is possible to have two different states associated with a component at the same time - checked and focussed.
  75. 75. Let’s use an example of a radio group with two options.
  76. 76. Before users interact with the group, both radio buttons are in the static state.
  77. 77. Choice 1 Choice 2 Static state on radio button
  78. 78. A radio button can be in a focus state only.
  79. 79. Choice 1 Choice 2 Focus state on radio button
  80. 80. A radio can also be in a checked (or selected) state only.
  81. 81. Choice 1 Choice 2 Checked state on radio button
  82. 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. 83. Choice 1 Choice 2 Checked and focus state on radio button
  84. 84. This is also relevant for checkboxes and segmented controls.
  85. 85. One Two Segmented control
  86. 86. Valerie (again): technically challenged.
  87. 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. 88. Solution: Make sure the different states are clearly identifiable and have unique styles.
  89. 89. States and non-native widgets
  90. 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. 91. For example: date-pickers, in- page tabs, pagination, accordions etc.
  92. 92. If these non-native widgets include some sort of interaction, they must have relevant states defined.
  93. 93. For example, an open/shut accordion should have focus, hover, active and open states defined.
  94. 94. Item 1 Item 2 Item 3 Item 4 Static state on accordion
  95. 95. Item 1 Item 2 Item 3 Item 4 Hover state on accordion
  96. 96. Item 1 Item 2 Item 3 Item 4 Focus state on accordion
  97. 97. Item 1 Item 2 Item 3 Item 4 Active state on accordion
  98. 98. Item 1 Item 2 Item 3 Content inside accordion panel, visible when open. Open state on accordion
  99. 99. Systematising states
  100. 100. Have you ever noticed a website or application that has inconsistent hover and focus styles across different components?
  101. 101. This can lead to a jarring experience - especially for keyboard-only users who navigate via focus.
  102. 102. For design systems, it is important to systematise all component states.
  103. 103. This makes it easier to: - establish consistency - maintain existing components - add new components
  104. 104. But how do you go about systematising states?
  105. 105. I use a “states” table to track all component states:
  106. 106. Full state table
  107. 107. Don’t worry, we are going to break this down.
  108. 108. This table has a row for each possible state. The rows are:
  109. 109. Static Visited Hover Focus Active Disabled Invalid Selected Selected &Focus
  110. 110. Then, components can be grouped into categories in columns:
  111. 111. Links Buttons Form controls Selectable form controls Calendar dates Accordions Tabs Pagination etc
  112. 112. This allows you to compare all the components in their different states.
  113. 113. States may need to be styled slightly differently in each category, but there should be an overall consistency across all components.
  114. 114. Links
  115. 115. For links, there is a column for light and dark backgrounds.
  116. 116. Link columns: light and dark backgrounds
  117. 117. Static, visited, hover, focus and active states are defined.
  118. 118. Link states: static, visited, hover, focus, active
  119. 119. Disabled, invalid, selected and selected/focus states are not relevant.
  120. 120. Non-relevant states: disabled, invalid, selected, selected/focus
  121. 121. Buttons
  122. 122. For buttons, there is a column for each of the button levels (primary, secondary, link and icon).
  123. 123. Button columns: primary, secondary, link, icons
  124. 124. Static, hover, focus, active and disabled states are defined.
  125. 125. Button states: static, hover, focus, active, disabled Button states: static, hover, focus, active, disabled
  126. 126. Visited, invalid, selected and selected/focus states are not relevant.
  127. 127. Non-relevant states: visited, invalid, selected, selected/focus
  128. 128. Form controls
  129. 129. For form controls, there is a column for input/textarea and select.
  130. 130. Form control columns: input/ textarea, select
  131. 131. Static, hover, focus, disabled and invalid states are defined.
  132. 132. As mentioned earlier, I’ve included a hover state for form controls. But this is a personal choice.
  133. 133. Form control states: static, hover, focus, disabled, invalid
  134. 134. Visited, active, selected and selected/focus states are not relevant.
  135. 135. Non-relevant states: visited, active, selected, selected/focus
  136. 136. Selectable form controls
  137. 137. For selectable form controls, there is a column for radios, checkboxes and segmented controls.
  138. 138. Clickable form control columns: radio, checkbox, segmented control
  139. 139. Static, hover, focus, disabled, invalid, selected and selected & focus states are defined.
  140. 140. Clickable form control states: static, hover, focus, disabled, invalid, selected, selected/focus
  141. 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. 142. Non-relevant states: visited, active Non-relevant states: visited and possibly active ?
  143. 143. Accordion
  144. 144. For accordion, there is a column for the closed and open version of an accordion item.
  145. 145. Accordion columns: closed, open Accordion columns: closed, open
  146. 146. Static, hover, focus and active states are defined.
  147. 147. Accordion states: static, hover, focus, active
  148. 148. Visited, disabled, invalid, selected and selected/focus states are not relevant.
  149. 149. Non-relevant states: visited, active, disabled, invalid, selected, selected/focus
  150. 150. In-page tabs
  151. 151. For in-page tabs, there is a column for the closed and open version of tab items.
  152. 152. Tabs columns: open, closed Tabs columns: open, closed
  153. 153. Static, hover, focus and active states are defined for closed tabs.
  154. 154. Tab states: static, hover, focus, active
  155. 155. Visited, disabled, invalid, selected and selected/focus states are not relevant.
  156. 156. Non-relevant states: visited, disabled, invalid, selected, selected/ focus
  157. 157. Open tabs do not require a hover or active state as they are already “open and active”.
  158. 158. Non-relevant states for open: hover, active Non-relevant states for open: hover, active
  159. 159. Just an example
  160. 160. This chart shows one way that different states can be styled.
  161. 161. The table is available online: URL to come
  162. 162. Take aways
  163. 163. Take away 1: It’s important to be aware of all of the different states.
  164. 164. Take away 2: It’s important to design for all of these different states, especially for non-native widgets.
  165. 165. Why? Because when these states are poorly executed, it can have an impact on real users.
  166. 166. Take away 3: Systematising the states is important for websites and applications?
  167. 167. Why? It allows you to maintain a visual consistency across your websites and/or applications.
  168. 168. Russ Weakley Max Design Site: Twitter: Slideshare: Linkedin: