How to build accessible UI components
0 likes472 views
The document outlines seven criteria for building accessible UI components, emphasizing the importance of using HTML elements according to their intended purpose, providing accessible names, ensuring keyboard focus, and communicating states to assistive technologies. It evaluates three methods of creating a UI component, highlighting the advantages and disadvantages of using native checkboxes versus styled checkboxes and buttons. The conclusion stresses the value of native HTML elements for inherent accessibility features.
How to build accessible UI components
- 1. Accessible How to build UI Components
- 2. For this presentation, I’m going to outline seven criteria that can be used to make accessible UI components.
- 3. Then, I’ll show you an example UI component built using three different methods.
- 4. Finally, I’ll use the seven criteria to determine the accessibility of each method.
- 5. Seven criteria that make a UI component accessible
- 6. 1. Semantics
- 7. All HTML elements have specific semantic meaning.
- 8. Where possible, HTML elements should be used for their intended purpose only.
- 9. Using HTML elements incorrectly can cause confusion for Assistive Technologies.
- 10. If an element is being used in a different way to its intended purpose, it should be assigned an explicit ARIA role.
- 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>
- 13. Many HTML elements have an accessible name already defined.
- 14. Accessible names are used by Assistive Technologies to identify the element.
- 15. Accessible names can come from different sources, including:
- 16. // By default, the accessible name for links is defined via the link content: <a href="a.html">Red fish</a>
- 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. // 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. For some UI components, there is no accessible name, or the existing name lacks clarity.
- 20. In these cases, specific ARIA attributes can be used to provide a new accessible name.
- 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. 3. Focusable
- 23. Interactive UI components must be able to receive keyboard focus.
- 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. For simple components, this could mean adding tabindex="0" to the parent component.
- 26. For more complex components, this could mean adding focus to a range of child elements.
- 28. Interactive UI components must be fully accessible using keystrokes only.
- 29. These keystrokes should follow well- established keystroke patterns.
- 31. Interactive UI components have a range of possible states.
- 32. These states can include hover, focus, active and in some cases, checked.
- 33. Each of these states should be clearly visible.
- 34. Each of these states should have a unique style.
- 36. Interactive UI components may need to change states at times.
- 37. States can include checked, expanded, disabled, pressed and selected.
- 38. These states must be clearly communicated to assistive technologies.
- 39. For native HTML elements like radio and checkboxes, these states are baked-in.
- 40. However, when using non-native elements, ARIA has to be used to define these states.
- 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. 7. Existing UI conventions
- 43. UI components should be designed to work in well-established ways.
- 44. Reinventing the wheel can cause confusion for users.
- 45. This is especially important for certain types of cognitive-impaired and technically challenged users.
- 46. Non-native UI components should be tested rigorously with the intended audience.
- 47. One UI component, three methods
- 48. Let’s look at our UI component.
- 49. Red Green Blue Purple Yellow Choose your preferred colours Heading
- 50. Red Green Blue Purple Yellow Choose your preferred colours A set of options
- 51. Red Green Blue Purple Yellow Choose your preferred colours One or more options can be checked
- 52. Over the years, I’ve seen this problem tackled using a range of different methods.
- 53. We’ll look at three common methods.
- 55. Red Green Blue Purple Yellow Choose your preferred colours Fieldset
- 56. Choose your preferred colours Red Green Blue Purple Yellow Legend - explicitly associates heading with options below
- 57. Red Green Blue Purple Yellow Choose your preferred colours Native checkboxes
- 58. Red Green Blue Purple Yellow Choose your preferred colours Labels
- 59. Red Green Blue Purple Yellow Choose your preferred colours Checkboxes and labels are explicitly associated via matching “for” and “id” values
- 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. This method is highly accessible.
- 62. Method 2. Using checkboxes styled to look like buttons
- 63. Choose your preferred colours Heading Red Green Blue Purple Yellow
- 64. Choose your preferred colours Red Green Blue Purple Yellow A set of options
- 65. Choose your preferred colours Red Green Blue Purple Yellow One or more options can be checked
- 66. Choose your preferred colours Red Green Blue Purple Yellow Fieldset
- 67. Choose your preferred colours Red Green Blue Purple Yellow Legend - explicitly associates heading with options below
- 68. Choose your preferred colours Red Green Blue Purple YellowHidden Checkboxes
- 69. Choose your preferred colours Red Green Blue Purple YellowLabels placed on top of the checkboxes
- 70. Choose your preferred colours Red Green Blue Purple Yellow LabelCheckboxes and labels are explicitly associated via matching “for” and “id” values
- 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. This method does not use existing UI conventions.
- 73. It changes the appearance of checkboxes to make them appear like buttons.
- 74. The default nature of buttons is that they can be pressed to trigger some sort of action.
- 75. By default, buttons do not have a checked state.
- 76. For this reason, users may not understand when an option is checked.
- 77. They also may not understand that they can choose multiple options.
- 78. So, this method should be tested carefully with the intended audience before being used.
- 79. Method 3. Using buttons
- 80. Choose your preferred colours Heading Red Green Blue Purple Yellow
- 81. Choose your preferred colours Red Green Blue Purple Yellow A set of options
- 82. Choose your preferred colours Red Green Blue Purple Yellow One or more options can be checked
- 83. No Fieldset Choose your preferred colours Red Green Blue Purple Yellow
- 84. Choose your preferred colours Red Green Blue Purple Yellow No Legend, so heading is not explicitly associated with options below
- 85. No Checkboxes Choose your preferred colours Red Green Blue Purple Yellow
- 86. Choose your preferred colours Red Green Blue Purple Yellow Buttons
- 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. This method starts out using an entirely inappropriate element - the <button> element.
- 89. Extensive work would need to be done to make this component accessible.
- 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. // 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. This method also has similar problems to the previous method. It does not use existing UI conventions.
- 93. So, this method would also need to be tested with the intended audience before being used.
- 94. Conclusion
- 95. The main lesson here is that we should always try to use native HTML elements for UI components.
- 96. Accessibility is baked into every aspect of these elements - from semantics to accessible name, keyboard functionality, states and more.
- 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. Thank you