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.

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>

12. 2. Accessible name

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.

27. 4. Keyboard interaction

28. Interactive UI components must be
fully accessible using keystrokes
only.

29. These keystrokes should follow well-
established keystroke patterns.

30. 5. Visible states

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.

35. 6. Functional states

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.

54. Method 1.
Using checkboxes

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