Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

How to build accessible UI components

139 Aufrufe

Veröffentlicht am

This presentation was fro the AllyBtyes event on 21 May 2020. The presentations looks at a pattern for building or reviewing any new UI component – semantics, focusable, keyboard interaction, visible states, accessible name and relationships.

Veröffentlicht in: Bildung
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

How to build accessible UI components

  1. 1. Accessible How to build UI Components
  2. 2. For this presentation, I’m going to outline seven criteria that can be used to make accessible UI components.
  3. 3. Then, I’ll show you an example UI component built using three different methods.
  4. 4. Finally, I’ll use the seven criteria to determine the accessibility of each method.
  5. 5. Seven criteria that make a UI component accessible
  6. 6. 1. Semantics
  7. 7. All HTML elements have specific semantic meaning.
  8. 8. Where possible, HTML elements should be used for their intended purpose only.
  9. 9. Using HTML elements incorrectly can cause confusion for Assistive Technologies.
  10. 10. If an element is being used in a different way to its intended purpose, it should be assigned an explicit ARIA role.
  11. 11. // This div element is being used as a button, so it will need a role of "button", so that its purpose is understood by assistive technologies: <div role="button"></div>
  12. 12. 2. Accessible name
  13. 13. Many HTML elements have an accessible name already defined.
  14. 14. Accessible names are used by Assistive Technologies to identify the element.
  15. 15. Accessible names can come from different sources, including:
  16. 16. // By default, the accessible name for links is defined via the link content: <a href="a.html">Red fish</a>
  17. 17. // The accessible name for images is defined via the value of the alt attribute (if present): <img src="a.png" alt="Red fish">
  18. 18. // The accessible name for form controls can be defined via the label content, if these two elements are explicitly associated: <label for="fish">Red fish</label> <input id="fish" type="text">
  19. 19. For some UI components, there is no accessible name, or the existing name lacks clarity.
  20. 20. In these cases, specific ARIA attributes can be used to provide a new accessible name.
  21. 21. // If the button content lacks meaning, the accessible name can be defined via the aria-label value: <button aria-label="Close and go to Red fish">
 X
 </button>
  22. 22. 3. Focusable
  23. 23. Interactive UI components must be able to receive keyboard focus.
  24. 24. If the UI component is built using elements that don’t natively accept focus, some of these elements will need to have focus defined.
  25. 25. For simple components, this could mean adding tabindex="0" to the parent component.
  26. 26. For more complex components, this could mean adding focus to a range of child elements.
  27. 27. 4. Keyboard interaction
  28. 28. Interactive UI components must be fully accessible using keystrokes only.
  29. 29. These keystrokes should follow well- established keystroke patterns.
  30. 30. 5. Visible states
  31. 31. Interactive UI components have a range of possible states.
  32. 32. These states can include hover, focus, active and in some cases, checked.
  33. 33. Each of these states should be clearly visible.
  34. 34. Each of these states should have a unique style.
  35. 35. 6. Functional states
  36. 36. Interactive UI components may need to change states at times.
  37. 37. States can include checked, expanded, disabled, pressed and selected.
  38. 38. These states must be clearly communicated to assistive technologies.
  39. 39. For native HTML elements like radio and checkboxes, these states are baked-in.
  40. 40. However, when using non-native elements, ARIA has to be used to define these states.
  41. 41. // In this case, a DIV element has been given an aria-checked attribute to inform assistive technology users of its state: <div checked aria-checked="true" > </div>
  42. 42. 7. Existing UI conventions
  43. 43. UI components should be designed to work in well-established ways.
  44. 44. Reinventing the wheel can cause confusion for users.
  45. 45. This is especially important for certain types of cognitive-impaired and technically challenged users.
  46. 46. Non-native UI components should be tested rigorously with the intended audience.
  47. 47. One UI component, three methods
  48. 48. Let’s look at our UI component.
  49. 49. Red Green Blue Purple Yellow Choose your preferred colours Heading
  50. 50. Red Green Blue Purple Yellow Choose your preferred colours A set of options
  51. 51. Red Green Blue Purple Yellow Choose your preferred colours One or more options can be checked
  52. 52. Over the years, I’ve seen this problem tackled using a range of different methods.
  53. 53. We’ll look at three common methods.
  54. 54. Method 1.
 Using checkboxes
  55. 55. Red Green Blue Purple Yellow Choose your preferred colours Fieldset
  56. 56. Choose your preferred colours Red Green Blue Purple Yellow Legend - explicitly associates heading with options below
  57. 57. Red Green Blue Purple Yellow Choose your preferred colours Native checkboxes
  58. 58. Red Green Blue Purple Yellow Choose your preferred colours Labels
  59. 59. Red Green Blue Purple Yellow Choose your preferred colours Checkboxes and labels are
 explicitly associated via matching “for” and “id” values
  60. 60. 1. Semantics: 2. Accessible name: 3. Focusable: 4. Keyboard interaction: 5. Visible states: 6. Functional states: 7. Existing conventions: Baked in Baked in Baked in Baked in Baked in Baked in Well known/understood
  61. 61. This method is highly accessible.
  62. 62. Method 2.
 Using checkboxes styled to look like buttons
  63. 63. Choose your preferred colours Heading Red Green Blue Purple Yellow
  64. 64. Choose your preferred colours Red Green Blue Purple Yellow A set of options
  65. 65. Choose your preferred colours Red Green Blue Purple Yellow One or more options can be checked
  66. 66. Choose your preferred colours Red Green Blue Purple Yellow Fieldset
  67. 67. Choose your preferred colours Red Green Blue Purple Yellow Legend - explicitly associates heading with options below
  68. 68. Choose your preferred colours Red Green Blue Purple YellowHidden Checkboxes
  69. 69. Choose your preferred colours Red Green Blue Purple YellowLabels placed on top of the checkboxes
  70. 70. Choose your preferred colours Red Green Blue Purple Yellow LabelCheckboxes and labels are
 explicitly associated via matching “for” and “id” values
  71. 71. 1. Semantics: 2. Accessible name: 3. Focusable: 4. Keyboard interaction: 5. Visible states: 6. Functional states: 7. Existing conventions: Baked in Baked in Baked in Baked in Baked in Baked in May not be understood
  72. 72. This method does not use existing UI conventions.
  73. 73. It changes the appearance of checkboxes to make them appear like buttons.
  74. 74. The default nature of buttons is that they can be pressed to trigger some sort of action.
  75. 75. By default, buttons do not have a checked state.
  76. 76. For this reason, users may not understand when an option is checked.
  77. 77. They also may not understand that they can choose multiple options.
  78. 78. So, this method should be tested carefully with the intended audience before being used.
  79. 79. Method 3. 
 Using buttons
  80. 80. Choose your preferred colours Heading Red Green Blue Purple Yellow
  81. 81. Choose your preferred colours Red Green Blue Purple Yellow A set of options
  82. 82. Choose your preferred colours Red Green Blue Purple Yellow One or more options can be checked
  83. 83. No Fieldset Choose your preferred colours Red Green Blue Purple Yellow
  84. 84. Choose your preferred colours Red Green Blue Purple Yellow No Legend, so heading is not explicitly associated with options below
  85. 85. No Checkboxes Choose your preferred colours Red Green Blue Purple Yellow
  86. 86. Choose your preferred colours Red Green Blue Purple Yellow Buttons
  87. 87. 1. Semantics: 2. Accessible name: 3. Focusable: 4. Keyboard interaction: 5. Visible states: 6. Functional states: 7. Existing conventions: Will need to be defined Baked in Baked in Will need to be redefined Will need to be redefined Will need to be defined May be misunderstood
  88. 88. This method starts out using an entirely inappropriate element - the <button> element.
  89. 89. Extensive work would need to be done to make this component accessible.
  90. 90. // The button would need to be given a role of checkbox, to inform Assistive Technologies as to its purpose. <button role="checkbox" > Green </button>
  91. 91. // When checked, the button would need to be given an aria-checked attribute, to inform Assistive Technologies as to its current state. <button role="checkbox" checked aria-checked="true" > Green </button>
  92. 92. This method also has similar problems to the previous method. It does not use existing UI conventions.
  93. 93. So, this method would also need to be tested with the intended audience before being used.
  94. 94. Conclusion
  95. 95. The main lesson here is that we should always try to use native HTML elements for UI components.
  96. 96. Accessibility is baked into every aspect of these elements - from semantics to accessible name, keyboard functionality, states and more.
  97. 97. The further away from native HTML elements you move, the more work you have to put in to try and force them to operate in an accessible way.
  98. 98. Thank you

×